Webentwickler, die sich heute das neue HTML5-Logo auf die Webseite kleben, haben vielleicht damals auch die Buttons „optimiert für Internet Explorer 6“ draufgepappt. Zweckdienlicher sind da dann schon gleich hohe Input-Felder, eine Statistik über mobile Browser, CSS-Resets und eine PNG-Übersicht. Themen, denen sich Jens und David ebenso in dieser Sendung widmen, wie runden Ecken mit Schatten und der Diskrepanz zwischen Print- und Webdesign.

Diese Folge jetzt anhören

Die Themen dieser Sendung

  • HTML5 hat jetzt auch ein Logo. Und das W3C verwirrt die Webstandards-Gemeinde damit, dass CSS3 damit in Zusammenhang gebracht wird. Zum Glück wurde eine Klarstellung mittlerweile nachgereicht.
  • Linkempfehlung: Gleich hohe Input-Felder
  • Peter-Paul Koch veröffentlicht eine Statistik über Verteilung mobiler Browser.
  • Eric Meyer überarbeitet seinen Reset. Endlich.
    • Es gibt ja auch viele Menschen, die eine Sinnhaftigkeit eines Resets bestreiten. Dazu gibt es viele Artikel und unterschiedliche Reset-Ansätze.
  • Schöne Übersicht über PNG und deren Eigenschaften und Einbindungen in Browsern.
  • Erfahrung mit aktuellen Projekten
    • Es gibt leider noch immer Grafiker, die in Layouts Schriften non-antialiased anwenden.
    • Jens hat Stunden für Recherche und Umsetzung gebraucht bei Containern mit runden Ecken und Schatten. Alles nur, weil die Optik auch im IE so sein soll. Mit CSS3 wäre es eine Sache von Minuten gewesen.
    • Wir müssen offenbar nicht nur die Entwickler fortbilden, sondern auch Grafiker und Kunden. Tomas Caspers, Nils Pooker und Jens Grochtdreis wollen in diese Richtung tätig werden
  • Was Print-Designer für die Umsetzung eines Webdesigns liefern müssen
    Daraus könnte man mit den Webkrauts eine Checkliste auf Basis dieses Artikels machen, mit Erläuterungen. Eine Checkliste, die man erweitern und mit Beispielen unterfüttern kann. Am besten in den Kommentaren Ergänzungen vornehmen. Dazu ist auch der Artikel Web≠Print empfehlenswert.

TechnikLOAD – Der Videopodcast von Technikwürze

TechnikLOAD 21 – Geek-Stuff, HTML5, 3D, LOLcats, Nerdcore und Gewinnspiel!.

Keine Folge mehr verpassen und TechnikLOAD unterstützen: Einfach und kostenlos abonnieren auf YouTubeiTunes oder Vimeo. Danke!

Alle Folgen im Überblick auf t3n.de

Diese Folge jetzt anhören

Tags: , , ,

Dieser Beitrag wurde am Sonntag, 23. Januar 2011 um 12:49 Uhr in der Kategorie Podcast veröffentlicht.
Du kannst einen Kommentar hinterlassen, oder einen Trackback von deiner Seite aus senden.

Kommentare

  • Avatarbild von Tim Kraut Tim Kraut
    am 23. Januar 2011, 14:26 Uhr

    Ich setze für gewöhnlich für das body-Element font-size mit einem Schlüsselwort (z.B. small) und danach dann alle Überschriften, Absätze, … mit em. Dann bezieht sich das em auf die font-size von body, ich habe keinerlei Multiplikationen drin und muss auch nur eine “Reset-Zeile” verwenden.

    Das machts auch sehr einfach, wenn man eine Funktion anbieten will, die die Schrift per JavaScript vergrößert – einfach font-size von ändern et voilà.

  • Avatarbild von Daniel Rauber Daniel Rauber
    am 23. Januar 2011, 15:15 Uhr

    Super Sendung und interessante Links!
    Hat mich gefreut auch mal wieder eine nicht Total Sendung zu hören.
    Die Erfahrung mit den nicht nicht umsetzbaren Schriften aus Photoshop Dateien habe ich auch schon gemacht… nervig!
    Ich finde es allerdings ganz gut, dass man Blockelemente in HTML5 in ein machen darf, allerdings deklariere ich dann auch immer den Anchor als Blockelement.

  • Avatarbild von Löppi Löppi
    am 23. Januar 2011, 18:50 Uhr

    Ich bin mit dem bisherigen CSS-Reset eigentlich sehr zufrieden und verwende ihn in abgewandelter Form. Den neuen werde ich wohl er zu HTML5-Zeiten verwenden. Bis dahin dauert es aber noch ein wenig, da müssen erst noch ein paar Browserversionen “aussterben”. ;)

  • Avatarbild von nik nik
    am 24. Januar 2011, 03:22 Uhr

    „Wir müssen offenbar nicht nur die Entwickler fortbilden, sondern auch Grafiker und Kunden.“

    Hmm müssen wir das? Erstmal klingt es gut, aber bei näherer Betrachtung: WIR sind die Experten, der Kunde bezahlt Geld dafür, sich NICHT mit diesem ganzen Gedöhns beschäftigen zu müssen. Immer wenn ich auf Veranstaltungen bspw. von der IHK bin, die sich an KMU u.ä. richten, merke ich, dass Leute selbst von Grundlagen absolut überfordert sind. Transparenz ok, aber IMHO erzieht man damit allenfalls Besserwisser mit gefährlichem Halbwissen. Schon heute ist doch jeder Chef schon SEO-Experte wenn er mal einen Artikel gelesen hat oder „Programmierer“, wenn er mal mit Office ein Dokument als HTML exportiert hat. Bei einer solchen Fortbildung – bei welchem Urschleim soll man da anfangen?!

  • Avatarbild von nik nik
    am 24. Januar 2011, 03:27 Uhr

    PS: Bin mit dem reset.css auch zufrieden. Ich glaube Ihr mißversteht auch den Sinn ein wenig. Ziel ist es, einen einheitlichen Browserstand zu erreichen. Wenn Ihr das anderweitig mit Grundeinstellungen Eures Individual-CSS erreicht, hindert Euch ja niemand daran, das Reset zusammenzukürzen. In seiner originären Form richtet es sich aber an alle globalen Anforderungen. Also macht es auch Sinn, alles zu reduzieren. Bspw. die Auszeichnung „Liste“ sagt semantisch auch gar nichts über eine Darstellungsform aus: Zeilenweise mit Bömmeln davor…

    um Blockelemente empfinde ich persönlich als Segen. Notfalls deklariert man das Element eben so um, dass es weder Block- noch Inline-Element ist. Eigentlich auch sehr sinnvoll, weil es selbst ja gar nicht Inhaltsauszeichnung, sondern nur „Behaviour“-Element ist.
  • Avatarbild von Schepp Schepp
    am 24. Januar 2011, 09:29 Uhr

    Ich würde sogar soweit gehen zu sagen: Das reset.css soll mehr als ein einheitlicher Browserstand, oder gar ein Normalisieren bewirken. Der Name ist Programm: Es wird im Prinzip alles an Formatierung rausgeschmissen. Da ist es durchaus konsequent gewesen, auch die Fokus-Outline herauszunehmen. Das Problem: Eigentlich suchen wir alle eher eine brauchbare Kickstart-Lösung, die sinnvolle, normalisierte Presets vorschlägt – wir bedienen uns aber am falschen Ding. Eigentlich ist das was das YAML-Framework liefert richtiger für diesen Zweck.

    Dass neue HTML5-Sektionen defaultmäßig geinlined sind hat nichts mit der Soezifikation zu tun, sondern ganz schlicht den Grund, dass sie fast all unseren Browsern nach wie vor unbekannt sind. Und eben die springen bei ihnen unbekannten Elementen automatisch auf eine Inline-Darstellung, weil man dadurch am Wenigsten kaputt macht. Mit dem breitflächigen Aufkommen der HTML5-Parser wird sich das sicherlich ändern (IE9, FF4…)

    David, Du beschwertest Dich außerdem darüber, dass jede neue Technik im Web direkt irgendeinen kranken Namen bekommt. Die Namen sind oft in der Tat an den Haaren herbeigezogen, stimmt. Aber ich denke, sowas ist notwendig, wenn sich Deine Technik im Netz verbreiten soll und wenn Du im Gespräch mit anderen Entwicklern schnell und ohne Missverständnisse auf eine Technik verweisen möchtest. Es ist immer besser flott sagen zu können “Big Whoop-Ass Badaboum Box Shadow” als irgendwie “Das Ding, wo man im IE6 zwei DIVs ineinanderwrappern, aufs Inneren position:relative und aufs Äußere den Blur-Filter setzen muss” fusselimmund. :D

  • Avatarbild von macx macx
    am 24. Januar 2011, 09:41 Uhr

    Ich habe nichts gegen Namen für ein Produkt, sondern gegen Namen, die mehr was von Star Wars haben als von Webdesign. Und bisher wurden diese Namen eben aus deinen genannten Grund im Web misbraucht. Und das nervt tierisch. Augenscheinlich scheint es kaum jemanden zu geben, der dem Ding einen guten Namen geben, der beschreibt, was drin steckt und nicht zu abgehoben ist. Gerade dann ist ein solcher Artikel wie der von Christoph wirklich mal sehr angenehm zu lesen. Er ist halt für Menschen geschrieben und nicht für SEO und Buzzword. Und er wird ja trotzdem gewürdigt.

    Meine Zwei Cent zum reset.css: Da ich in meinen Projekten immer jedes Element gestalte, welches ich auch einsetze, benötige ich weder ein Browserstylesheet, noch ein oben drauf gesetztes reset.css. Von daher ist ein (solcher) Reset bei mir sinnlos, da eine Definition, die ich eh überschreiben werde.

  • Avatarbild von Schepp Schepp
    am 24. Januar 2011, 09:46 Uhr

    Da stimme ich Dir in beiden Punkten 100% zu. Übrigens scheint sich Christoph unbewusst einer ziemlich cheffigen Sache zu bedienen: dem Shadow DOM

  • Avatarbild von Malte Blättermann Malte Blättermann
    am 25. Januar 2011, 01:54 Uhr

    Hallo,
    insgesamt eine schöne Folge, allerdings finde ich insgesamt, dass euere Sendungen in letzter Zeit immer weniger Struktur aufweisen.

    Was sonst eine strukturierte Sendung mit viel Fachwissen war mutiert immer mehr zur Talkrunde.

    Dabei stehen eure persönlichen Meinungen in letzter Zeit zu sehr im Vordergrund. Klar, eure Meinungen sind auch wichtig, aber nur als Fazit und nicht als Headliner.

    Und immer dieses Genörgel im Grundton. Macht es doch einfach besser als Eric Schmidt. Ich finde seinen Reset-Css sehr gelungen und die Tatsache das einige Webentwickler “zu dämlich” zum Lesen sind bzw. Ihre Fehler scheinbar auch nicht beim Testen bemerken, darf nicht in Kritik an Eric münden.

    Schließlich war es kein Bug, sondern immer wohl dokumentiert.

    Was das Überschreiben von Styles angeht, was soll daran falsch sein? Dafür gibt es schließlich diese Möglichkeit. Performance-Technisch wird es wohl kaum ins Gewicht fallen.

    Ich empfehle euch, die eigene Qualität mehr im Auge zu behalten, als ständig über die Qualität und Unfähigkeit anderer zu urteilen.

    Es wirkt teilweise etwas überheblich.

    Auch der Part Print/Webdesign ist etwas neben der Spur und letzendlich Hetze… Freut euch doch, dass ihr 1-2 Stunden mehr berechnen könnt, wenn ihr solche PSDs bekommt.

    Letztendlich kann man mittlerweile JEDE *.psd in HTML umsetzen.. KnowHow vorausgesetzt. Dann benutze ich auch keine mal transparente PNGs. Alles halb so wild.

    Ich seid doch nicht die Erdachse…

    Beste Grüße
    Malte

  • Avatarbild von macx macx
    am 25. Januar 2011, 15:33 Uhr

    Malte, du hast Recht. Der inhaltliche Fokus dieser Sendung lag nicht in der journalistisch neutralen Berichterstattung. Das war allerdings auch nicht geplant.

    Bezüglich der Umsetzung von Photoshopdokumenten erlaube ich mir aber mal, dir zu widersprechen. Während meiner Zeit in der einen oder anderen Werbeagentur hatte ich sehr oft PSDs, die immer überarbeitet werden mussten, bevor ich daraus eine saubere Webseite machen konnte. Und wenn du das jede Woche drei Mal machst, dann ist das nicht „halb so wild“, sondern nervig. Da fehlt es einfach an der Schulung der Mitarbeiter, die die zusammenstellen. Denn schlussendlich freut sich auch der Kunde, wenn die Werbeagentur drei Stunden weniger aufschreibt, weil sie interne Abläufe zu optimieren weiß.

  • Avatarbild von Michael van Laar Michael van Laar
    am 25. Januar 2011, 16:19 Uhr

    Ach ja, das leidige Thema CSS3-Features und Internet-Explorer. Allerdings muss ich sagen, seit ich http://css3pie.com einsetze, spare ich viel Zeit. Es geht noch nicht alles, aber zumindest vieles. Und ja, es wird natürlich eine htc-Datei nachgeladen, die auch noch zusätzlich Zeit fürs Rendern der Effekte benötigt. Aber besser ein IE-Nutzer wartet ein paar Sekunden länger, als dass ich stundenlang an unflexiblen Pseudolösungen herumbastle.

  • Avatarbild von Fn Fn
    am 25. Januar 2011, 17:42 Uhr

    Im Gegensatz zu Malte mag ich es mit weniger Struktur und mit mehr subjektivem Geplauder lieber, als journalistisch vorgelesene Technews.

  • Avatarbild von iTomski iTomski
    am 25. Januar 2011, 22:01 Uhr

    Na ja… sich weit und breit über Sinnhaftigkeit von Dingen die man nicht ändern kann finde ich bisschen mühselig. Bei solchen Diskusionen wind mir lediglich klar, dass ich mit meinen Ansichten nicht alleine bin. Aber ob eine Sndung, die zu 50% aus solchen Diskusionen besteht so reizvoll ist… muss jeder selber entscheiden.

    Bisschen mehr nützliche Informationen in der Sendung hätte ich mir schon gewünscht. Da waren andere Sendungen deutlich nahrhafter.

    Und ich werde das gefühl nicht los, das Jens bisschen mit Antialiasing durcheinander gekommen ist. Er spricht von der Unart der Grafiker Texte “ohne Antialiasing” abzuliefern. Doch genau das gegenteil ist der Fall. Die meisten Grafiker aktivieren die Kantenglättung und simulieren damit unrealistische webbedingungen… oder habe ich da was falsch verstanden.

    Gerade der Tipp für Grafiker bei Antialiasing einen Hacken zu setzen ist nicht ganz richtig.

    Jetzt will ich aber mein Mund halten… bin ja mit der Würze sehr zufrieden… ihr macht einen guten Job.

  • Avatarbild von Malte Blättermann Malte Blättermann
    am 27. Januar 2011, 12:20 Uhr

    @macx, Du hast ja im Grunde genommen vollkommen Recht, was die Situation mit Photoshop angeht.

    Ich wollte das ganze nur mal von einer anderen Seite beleuchten… :)

    Ansonsten macht weiter so wie bisher. Es ist ja auch ne Menge Arbeit so eine Sendung. Danke dafür!

    Ansonsten darf es von meiner Seite wie schon oben geschrieben inhaltlich ruhig etwas “tiefer” gehen.

    Ihr macht die Sendung doch für Webdesigner und nicht für solche, die es mal werden wollen… ?!

    Gruß Malte

  • Avatarbild von nik nk
    am 28. Januar 2011, 03:11 Uhr

    Die Checkliste ist ne tolle Idee, die zum Abkupfern anregt :)

    Spontan fällt mir noch ein, dass Agenturen oft nur für flache Hierarchien die Menüs entwerfen. Wie werden tiefere Naviagtionen gestaltet, wie sieht die grafische Gestaltung passiver und aktiver Punkte in diesen Ebenen aus, wodurch heben sich Ober und Unterpunkte optisch ab, wann sind Inhalte „aufgeklappt“/ausgeblendet etc., sind die Menüs für echte Anwendungsfälle überhaupt breit genug bzw. wie sieht die Gestaltung mehrzeiliger Menüpunkte aus..

  • Avatarbild von Jochen Kubik Jochen Kubik
    am 28. Januar 2011, 09:22 Uhr

    Hi Leute,
    die Seite mit den gleich hohen Inputfeldern ist ja wirklich sehr informativ, doch leider steigt mein Browser auf dem Androiden komplett aus als die Seite geladen war. Auf dem PC angeguckt: kein Wunder der Validator gab 52 Fehler aus ;-) Vielleicht gebt ihr dem Autor mal einen kleinen Hinweis, dass er jetzt vom Webstandardpodcast verlinkt ist, und die Seite wenigstens eine validen doctype haben sollte.

    Grüße aus Ludwigsburg
    Jochen Kubik

  • Avatarbild von Martin Gartner Martin Gartner
    am 31. Januar 2011, 21:41 Uhr

    @macx:

    Meine Zwei Cent zum reset.css: Da ich in meinen Projekten immer jedes Element gestalte, welches ich auch einsetze, benötige ich weder ein Browserstylesheet, noch ein oben drauf gesetztes reset.css. Von daher ist ein (solcher) Reset bei mir sinnlos, da eine Definition, die ich eh überschreiben werde.

    Damit erzeugst du aber im Grunde auch ein Reset (nur eben für jedes Projekt neu)!

  • Avatarbild von macx macx
    am 2. Februar 2011, 14:25 Uhr

    Ob es nun reset nennst, oder Definition von Gestaltungsmerkmalen: Das Ergebnis bleibt bei mir gleich: Ich überschreibe den Wert des Browsers nicht zwei Mal, sondern nur ein Mal.

  • Avatarbild von Bert Kößler Bert Kößler
    am 4. Februar 2011, 09:28 Uhr

    Ich verwende eigene Reset Styles, die sozusagen das Best Of aller Lösungen sind, die mir bisher untergekommen sind. Es ist dabei vor allem stark reduziert, weil zu viel einfach nicht gesund ist.

    Ich stimme mit euch allerdings nicht überein, dass es Quatsch ist, Listen zurückzusetzen. Einfach deshalb, weil weit mehr als die Hälfte aller verwendeten Listen einer Website nicht wie klassische Listen aussehen. Da sind vor allem Menüs, Untermenüs, kleine Neben-Menüs, Fußzeilen und aller möglicher anderer Kram – alles Listen, aber ohne Listenpunkte oder Nummerierung. Wenn ich das jedes mal auf’s Neue deaktiviere, kommt so viel mehr Code zusammen, als wenn ich es einmal abschalte und dann für die eine Liste, die wirklich so aussehen soll, wieder aktiviere.

    Ansonsten lustige Sendung, bin gespannt auf die Checkliste.

  • Avatarbild von Moritz Gießmann Moritz Gießmann
    am 14. Februar 2011, 08:30 Uhr

    Gute Sendung. Gute Links. Allerdings finde ich Jens’ Aussage bezüglich der Link-Elemente um Block-Elemente in HTML5 schwer nachvollziehbar. Ja, es weicht die gültigen Regeln bezüglich Block- und Inline-Elementen auf, aber der Weg, per JavaScript ein Klick-Event auf das Element zu legen ist schon aus Zugänglichkeitsgründen nicht praktikabel.

  • Avatarbild von Micha Micha
    am 15. Februar 2011, 14:59 Uhr

    Moinsen Jungs,

    was mich spontan diesmal angeregt hat war der Kommentar mit den XML Dateien von den Jungs von zeit.de… Gibts dazu noch ein wenig mehr Input? Hintergrund ist, das ich derzeit bissl was für zuhause Bastel und sowohl ein Webinterface für meinen normalen PC, mein iPhone oder das Windows Mobile Handy von meinem Mitbewohner bauen möchte – evtl. sollen später auch mal noch native Apps darauf zugreifen…

    Da gefiel mir der Ansatz mit den XML Dateien spontan verdammt gut… Das Backend spuckt einfach immer XML aus und die für das Gerät entsprechende Oberfläche stellt es dann richtig dar…

    Bisher wäre der Ansatz wohl eher stinknormale Templates gewesen – was aber teilweise dann doch wieder Probleme macht – je nach Endgerät will das ganze ja mehr oder weniger ausführlich dargestellt werden oder sowieso unter ganz anderen Unterpunkten zu finden sein…

    Also, gibts da nen spannenden Link – oder stell ichs mir eh anders vor, wie es gemeint war? :D

    Grüße,
    der Micha…

  • Avatarbild von rockpianist rockpianist
    am 5. März 2011, 15:11 Uhr

    Ich nutze Yaml und möchte hierfür noch mal eine Lanze brechen. Hier sind sämtliche Resets und Voreinstellungen schon vorhanden.
    rp

  • Avatarbild von flocke flocke
    am 7. März 2011, 19:34 Uhr

    Liebes Technikwüze-Team. Eigentlich bin ich gar nicht pingelig, aber ich würde mich sehr freuen, wenn ihr statt “das macht Sinn” – “das ergibt Sinn”, oder “das ist sinnvoll” zu verwenden. Es schmerzt bei diesem Cast besonders..

    Sinn kann nichts machen, der Sinn ergibt sich ;-)

    Gruß, Flocke

  • Avatarbild von macx macx
    am 8. März 2011, 08:30 Uhr

    @Micha
    Wende dich doch mal an nicobruenjes (Twitter), der ist Frontendentwickler bei ZEIT.

    @flocke
    Schwieriges Thema. Ob ich da im Gespräch dran denken werde? Ich habe da so meine Zweifel. Ich versuche da aber mal dran zu denken.

  • Avatarbild von flocke flocke
    am 8. März 2011, 08:43 Uhr

    Macx: du musst dir einfach innerlich gleich danach “das ergibt Sinn” sagen und nach ein paar mal geht’s dann wie von Zauberhand.
    Ansonsten hat mir euer Cast wieder sehr gefallen. Das hatte ich vergessen zu erwähnen ;-)

    Gruß, Flocke.

  • Avatarbild von Alex Alex
    am 21. März 2011, 19:15 Uhr

    Gibt es dann mal wieder eine neue Sendung?
    Ich leide langsam an Entzug :-)

  • Avatarbild von dan dan
    am 25. März 2011, 16:26 Uhr

    sehr unterhaltsam, kurzweilig und informativ – was will man mehr! weiter so!

  • Avatarbild von Manuel Kaufmann Manuel Kaufmann
    am 4. April 2011, 18:32 Uhr

    Hallo,

    also ich bin ja ein großer Fan von Technikwürze und schaue auch sehr gern Technikload. Aber ich finde es sehr schade, das in letzter Zeit so selten ein Podcast von euch kommt. Ich weiß, ihr habt sicherlich viel zu tun. Aber anbetracht der großen Spendenaktion für Technikwürze letztes Jahr, finde ich es schon irgendwie seltsam das jetzt, wo ihr euch von den vielen Geld neues Equipment besorgt habt, fast gar nichts mehr kommt.

    Ich hoffe wirklich, ihr werdet wieder etwas regelmäßiger!!

    Nichts für ungut.
    MK

  • Avatarbild von macx macx
    am 4. April 2011, 19:40 Uhr

    Wir haben mit dem neuem Equipment ja jede Menge Folgen produziert und es auch ausschließlich für die Produktion von Technikwürze verwendet. Es ist ja noch da und wartet ebenso wie du auf neue Aufzeichnungen.
    Konkret kann ich dir keinen Termin für eine neue Folge nennen. Doch sei dir sicher, dass ich der erste bin, der bei einem tollen Thema und Gesprächsgast „hier“ schreit. Im Moment fehlt mir schlicht und einfach die Zeit, mich um ein Thema und die Vorbereitung zu kümmern. Ich sollte sie mir aber nehmen, da hast du sicher Recht.
    Dass es weiter geht, ist klar. Wann, werde ich sicher in Twitter ausplaudern.
    Danke dir in jeden Fall für deinen Kommentar! Das hilft!

  • Avatarbild von Viktor Dite Viktor Dite
    am 5. April 2011, 10:39 Uhr

    Ich finde irgendwie das Buch nicht, dass ihr angesprochen habt (texten)

  • Avatarbild von Viktor Dite Viktor
    am 6. April 2011, 10:31 Uhr

    Ich glaube ich hab mich im Podcast vertan ;) war wohl der davor….

  • Avatarbild von Markus Markus
    am 26. April 2011, 13:56 Uhr

    Deine Zuhörer warten immer noch auf Nachschub.
    Und nein “Technikload” ist kein Ersatz. :-)

    Gruß Markus

  • Avatarbild von macx macx
    am 26. April 2011, 14:35 Uhr

    Hab ich nie behauptet. Ich habe wieder angefangen, Themen zusammenzustellen. Es sollte sehr bald konkrete Termine geben. Wichtig ist mir auch, dass es nach einer neuen Folge nicht gleich wieder viele Wochen Wartezeit gibt.

  • Avatarbild von Torsten Torsten
    am 10. Mai 2011, 12:19 Uhr

    Besonders interessant finde ich den Part “Containern mit runden Ecken und Schatten”. Das CSS3 greift damit ein leidiges Thema auf. Wie schon gesagt wurde, die Zeiteinsparungen sind bei dem Webdesign emens.

  • Avatarbild von Siegfried Siegfried
    am 17. Mai 2011, 08:27 Uhr

    Ich finde die Idee, möglichst wenig Klassennamen zu verwenden, und stattdessen lieber auf z.B. Kindselektoren zu setzen, absurd. Und zwar einfach deshalb, weil Beides wenig miteinander zu tun hat.

    Das große Problem ist, dass Klassennamen anscheinend nur dazu verwendet werden, ein Handle für das Styling zu schaffen. Klassennamen können als Handle verwendet werden, aber das ist nicht ihr eigentlicher Zweck. Das ist eher ein Seiteneffekt. Sinn von Klassennamen ist es, dem Element bzw. dessen Inhalt eine Bedeutung zu geben (Semantik) oder die dem Element inhärente Bedeutung zu verfeinern. Das heisst, dass Klassennamen im ersten Schritt überhaupt Nichts mit Aussehen (Präsentation, Style) zu tun haben, sondern mit Semantik. Die Frage, ob ein Element einen Klassennamen erhält oder nicht, hat also gar Nichts damit zu tun, ob und wie ich dieses Element stylen will. Folgerichtig kann es viele Elemente mit Klassennamen geben, denen überhaupt kein eigener Style zugewiesen wird. Andersherum kann man selbstverständlich Elemente stylen über z.B. Kindselektoren, bei denen es aus Sicht der Semantik keinen Sinn macht, denen einen Klassennamen zu verpassen.

    Die Idee, möglichst wenig Klassennamen zu verwenden, weil man die Elemente auch über Kindselektoren stylen kann, ist also von vornherein der falsche Ansatz. Ein Element sollte einen Klassennamen nicht erhalten, um es in irgend einer Weise zu stylen, sondern um die Bedeutung des Inhalts dieses Elements zu spezifizieren. Die Frage nach der Präsentation dürfte bei der Wahl von Klassennamen gar keine Rolle spielen.

  • Avatarbild von macx macx
    am 17. Mai 2011, 13:53 Uhr

    Wenn du deine Element mit Klassen oder IDs „strukturierst“, heißt das noch lange nicht, dass diese dann automatisch semantisch sind. Denn in Wahrheit ändert sich dadurch erst einmal gar nichts.
    Wie sollte denn auch ein Element der mit ID „sonnenblume“ mir semantisch etwas sagen?

    Das, was du als Attributwert da reinschreibst, sagt weder dem Browser, noch dem User, noch Google, was da drin steckt. Dafür sind die HTML5-Elemente nav, section, article usw zuständig. Es hilft nur dir persönlich, dich in deinem Code zurechtzufinden – mehr nicht.

  • Avatarbild von Christoph Zillgens Christoph Zillgens
    am 17. Mai 2011, 14:29 Uhr

    @Siegfried

    Klassennamen können als Selektor eingesetzt werden und das ist auch nach HTML-Spezifikation unter anderem genau ihr Zweck. Insofern spricht absolut nichts dagegen, Klassennamen aus Styling-Gründen zu verwenden, siehe HTML-Spec

    Der Inhalts wird in erster Linie durch HTML-Elemente augezeichnet, kann aber noch durch Klassennamen, z.B. mittels Microformats angereichert werden.

    Die Kindselektoren machen also absolut Sinn, um an stellen, wo Klassennamen nur zum Styling verwendet werden (was eben meistens der Fall ist), Markup und Zeit zu sparen.

    Dass die Klassennamen nicht nach visuellen Gesichtspunkten benannt werden sollten (also statt class=”“fett-rot” besser class=“wichtig”), ist zwar richtig, hat aber damit wenig zu tun.

  • Avatarbild von Siegfried Siegfried
    am 17. Mai 2011, 15:00 Uhr

    Genau das ist der Punkt! Ein Klassenname class=“sonnenblume” ist nur dann sinnvoll, wenn der Inhalt tatsächlich eine Sonnenblume ist. Denn genau das ist der Sinn und Zweck von Klassennamen.

    Und an Klassennamen, die ihrem Inhalt Semantik hinzufügen, gibt es z.B. bei dem Microformaten oder bei Dublin Core genug.

    Das trifft zumindest so auf Klassennamen zu. Ob und inwieweit das auf IDs zutrifft, bin ich mir nicht sicher. Neben Semantik kann eine ID auch einfach ein Navigationsziel sein. Insofern ist das mit IDs vermutlich etwas anders.

    Aber zurück zu Klassennamen. Ein Max Mustermann sagt eben sehr wohl Etwas über den Inhalt dieses span’s aus. Und genau das ist der Sinn von Klassennamen. Dabei spielt es absolut keine Rolle, ob dieser span irgendwie gestylt wird, oder nicht. Entscheident ist einzig, dass der Inhalt dieses spans ein vCard fn (ein voller Name nach vCard Standard) ist. Nix sonst.

  • Avatarbild von Siegfried Siegfried
    am 17. Mai 2011, 15:02 Uhr

    Grrr, das Blog verschluckt tags. Also noch mal das Beispiel:

    <span class=“vCard fn”>Max Mustermann<span>

  • Avatarbild von Siegfried Siegfried
    am 17. Mai 2011, 15:09 Uhr

    @Christoph: Dass Klassennamen nicht nach visuellen Gesichtspunkten gewählt werden sollten, spricht sehr dagegen, Klassennamen aus Stylinggründen einzusetzen.

    Wenn ein Element einen Klassennamen aus semantischen Gründen bekommt, ist es vollkommen in Ordnung, diesen auch als Style-Selektor zu verwenden. Wenn ein Element keinen solchen Klassennamen hat, weil es z.B. semantisch keinen Sinn macht, ist es nicht in Ordnung, einen künstlich nur als Styling-Selektor hinzuzufügen, dann ist es besser, dieses Element über andere Mittel zu selektieren.

    Auf der anderen Seite macht es sehr wohl Sinn, Elementen Klassennamen zuzuweisen, die im Stylesheet überhaupt keine Rolle spielen. Ob viel oder wenig Klassennamen hat also gar Nichts mit Styling zu tun, sondern nur mit der Entscheidung über die Semantik.

  • Avatarbild von Tim Kraut Tim Kraut
    am 17. Mai 2011, 17:22 Uhr

    @Siegfried:
    Was nützt dir deine zusätzliche semantische Information über das class-Attribut, wenn die keiner ausliest? Kein Screen-Reader, keine Suchmaschine und kein Benutzer liest die Klassennamen aus.
    Meiner Meinung nach sind class-Attribute, genauso wie id-Attribute (mit dem Zusatz, dass man diese als Anker verwenden kann) nur für den Zugriff von außen auf den (X)HTML-Code wichtig. Sei es über CSS, JavaScript oder etwas anderes.

    Andernfalls könnte man das mit der “Semantik” ja sehr, sehr weit treiben, was dann zur Folge hätte, dass man mehr class-Attribute als Element-Inhalt hat. Und das nur, um dann am Ende das “perfekte” Semantik-Erlebnis zu haben?

  • Avatarbild von Siegfried Siegfried
    am 17. Mai 2011, 18:36 Uhr

    @Tim: Es gibt z.B. Firefox-Erweiterungen, die Sowas auslesen. So kann man z.B. fertige vCard-Adressen direkt aus einer Webseite extrahieren. Das geht deshalb, weil diese Extension eben anhand der Klassennamen weiss, welche Inhalte welche Bedeutung haben. Also, welches Element den Vornamen, welches den Nachnamen, welches die PLZ enthält, u.s.w.

    Dass Suchmaschinen das noch kaum machen, liegt daran, dass kaum Jemand semantische Klassennamen nach standardisierten Vocabularies verwendet.

    Desweiteren wäre es möglich, relevante Informationen via XSL aus solch einer Webseite zu extrahieren. Naja, jedenfalls aus XHTML Seiten.

    Die Verwendung solcher Klassennamen aus standardisierten Vocabularies würde es erlauben, Spider zu schreiben, die eine semantische Suche durchführen. Stichwort dazu: “Web of Data”.

    Allgemein: Die Verwendung solcher Klassennamen würde eine Seite auch maschinenlesbar machen. Maschinenlesbar heisst, dass die Daten aus dem Web durch Maschinen für Menschen besser aufbereitet werden können.

  • Avatarbild von macx macx
    am 17. Mai 2011, 18:45 Uhr

    Reden wir mal nicht vom „Was wäre wenn“-Prinzip. Klassennamen zeichnen ein Element nicht semantisch aus! Du kannst das Element natürlich im Nachhinein durch die Verwendung von Microformats oder anderen Dingen semantisch auszeichnen, doch davon war in deinem ersten Kommentar nicht die Rede. Doch auch wenn du es nachträglich auszeichnest, so macht nicht alleine der Klassenname ein Element semantisch, sondern immer erst dein Tool, welches du einsetzt, um das auszulesen. Das ist ein sehr großer Unterschied.

  • Avatarbild von Tim Kraut Tim Kraut
    am 17. Mai 2011, 18:46 Uhr

    @Siegfried:
    Okay, meinetwegen. Würde funktionieren, gebe ich gerne zu. Aber wer nutzt sowas? Klar, das eine bedingt das andere… Keine Nutzer ohne Angebot und kein Angebot ohne Nutzer.

    Damit sowas wirklich eine sinnvolle semantische Information (im Sinne von allgemeingültig wie z.B. bei den neuen HTML 5-Elementen, die David erwähnt hat) darstellt, muss die Akzeptanz und Verbreitung allerdings stark zunehmen. Bis dahin finde ichs schwierig, das als eine Art semantisches Attribut abzustempeln.

  • Avatarbild von Siegfried Siegfried
    am 17. Mai 2011, 18:52 Uhr

    Vielleicht etwas ausführlicher hier: http://www.readwriteweb.com/archives/web_of_data_machine_accessible_information.php

    Ansonsten einfach mal nach “Web of Data” googeln.

  • Avatarbild von Siegfried Siegfried
    am 18. Mai 2011, 08:42 Uhr

    @macx: Was sind microformats Anderes als Klassennamen?

    Auf der einen Seite hast Du recht. Wenn ich class=“Sonnenblume” verwende, aber der Inhalt ist ein Gänseblümchen, dann fügt der Klassenname gar Nichts zur Semantik hinzu. Aber wenn ich class=“Gänseblümchen” schreibe, wenn darin tatsächlich ein Gänseblümchen ist, dann hat das extrem viel mit Semantik zu tun. Genau darum geht es.

    @Tim: Das bekannte Henne-Ei Problem ist natürlich richtig. Aber das wird nicht besser, wenn man sich dem verweigert. Und ob ich class=“Gänseblümchen” oder class=“Sonnenblume” schreibe, macht für das Styling keinen Unterschied, sehr wohl aber für die Semantik. Daher kann es nicht schaden, Sowas heute schon zu machen. Je konsequenter, um so zukunftssicherer.

    Was die Verwendung der (neuen) html-Tags angeht: Natürlich ist die semantisch korrekte Verwendung der Tags erste Priorität. Die Verwendung von semantisch geeigneten Klassennamen ist erst der zweite Schritt. Aber das heisst ja nicht, dass dieser zweite Schritt überflüssig wäre.

    Sieh es einfach mal als konsequent zu Ende gedacht an: Inhalt und dessen Bedeutung (Semantik) kommt ins html, das Aussehen (Präsentation) ins css, und das Verhalten (behaviour) ins (java)script. Klassennamen, die nur dem Styling dienen, sind ein Aspekt der Präsentation. Sie haben im html eigentlich Nichts zu suchen. Man nennt das auch presentational markup. Das ist nicht anders als die Verwendung von überflüssigen oder falschen html-Tags nur zum Zweck des Stylings.

    Gut, in der Praxis kommt man da gelegentlich nicht dran vorbei. Manchmal muss man zu solchen schmutzigen Tricks greifen. Aber deswegen werden diese schmutzigen Tricks noch lange nicht sauber. Und Notlösungen zum Prinzip zu erklären hilft auch nicht weiter.

    Ich will mal aus dem Gedächtnis ein Beispiel geben, das ich mal so ähnlich gefunden habe. Die genauen Klassennamen und Tags weiss ich nicht mehr, aber im Prinzip war das so Etwas wie:

    <span class=“linksgruengross”>Max Mustermann</span>

    Das wurde dann um microformats ergänzt, weil es ja so modern ist. Raus kam dann:

    <span class=“linksgruengross”><span class=“vcard fn”>Max Mustermann</span></span>

    Eine Klasse für das Styling und eine Klasse für die Semantik. Der Author war wohl felsenfest davon überzeugt, dass er den Klassennamen für das Styling genau so brauchte. Mir rollen sich dabei die Fußnägel auf. Und das nur, weil der Name in diesem Container anders gestylt werden sollte als ein Name im z.B. Hauptcontainer. Richtig wäre gewesen, hier nur mit vcard fn auszuzeichnen, denn nur das gibt an, um was es sich beim Inhalt handelt, und das Styling über den umgebenden Container und einen Kindselektor zu erledigen. Ein Klassenname, der nur dem Styling dient, hat hier Nichts zu suchen.

  • Avatarbild von Matthias Mees Matthias Mees
    am 18. Mai 2011, 09:54 Uhr

    Es ist doch eigentlich ganz einfach: Der Abschnitt zum class-Attribut in der Spezifikation besagt (frei übersetzt): „Autoren werden ermutigt, Werte zu verwenden, welche die eher Art des Inhaltes als seine gewünschte Präsentation beschreiben“.

    Sprich (was niemand hier bestreitet): Es macht Sinn, semantische Klassennamen zu verwenden, ist aber keine sklavische Bedingung. Dass Klassen ausdrücklich zur Gestaltung verwendet werden dürfen, beschreibt der von Christoph verlinkte Abschnitt der Spezifikation bereits.

  • Avatarbild von Christoph Zillgens Christoph Zillgens
    am 18. Mai 2011, 10:44 Uhr

    Laut Spezifikation spricht nichts dagegen, Klassennamen zwecks Styling einzusetzen, also spricht nichts dagegen, Klassennamen zwecks Styling einzusetzen, denn es spricht nichts dagegen.

    Gegen die Verwendung von class=“linksgruengross” spricht einzig und allein die Tatsache, dass der Klassenname bei Änderung der Gestaltung in z.B. kleinere Links in roter Farbe missverständlich wird und damit schlechte Praxis ist, die Semantik des Dokuments wird aber nicht verändert.

    Umgekehrt kann ich auch nicht darauf schließen, dass die Klasse nur deshalb überflüssig ist, weil sie einen falschen Namen hat. Besser wäre also z.B. ein Klassen-Name wie “fav_links”, der keinen Präsentationsbezug hat, dadurch aber immer noch keine semantische Bedeutung für das Dokument erlangt.

  • Avatarbild von Siegfried Siegfried
    am 18. Mai 2011, 10:50 Uhr

    @Matthias: Damit kann ich weitgehend leben. Allerdings sehe ich die Prioritäten etwas anders. Also zuerst mal Klassennamen für die Semantik. Die kann man zu 99% auch für das Styling als Selektoren recyceln. Was dann noch übrig bleibt und eben tatsächlich nicht anders geht, bekommt eben auch mal einen Klassennamen nur für das Styling. Aber auf diese Notlösung versuche ich eben, so weit wie möglich, zu verzichten.

    Der Witz ist doch, dass semantisch korrekte Klassennamen für das Styling genau so gut verwendet werden können wie von mir aus reine random-Klassennamen. Für das Styling macht es keinen Unterschied. Für die Semantik (Maschinenlesbarkeit) hingegen sehr.

  • Avatarbild von Siegfried Siegfried
    am 18. Mai 2011, 11:11 Uhr

    @Christoph: fav_links ist zumindest teilweise noch ein Klassenname, der nur der Präsentation dient. “fav” hat immerhin Bedeutung, wenn auch nicht ganz einfach zu verstehen. “link” hat nur Stylingcharakter und stimmt schon dann nicht mehr, wenn es eben plötzlich nicht links, sondern rechts dargestellt werden soll.

    Oder meintest Du den Plural von “link”? Das wäre dann in der Tat Semantik. Dann wäre der Klassenname absolut richtig.

    Falls “links” = Ortsbezeichnung:
    Angenommen, mit “fav” soll Irgendetwas gekennzeichnet werden, das irgendeine Art von Favorit ist. Dann bekommt das Dingens eben den Klassennamen “fav”. Ob der nun links, rechts, oben, unten, gar nicht oder sonstwo dargestellt (präsentiert) wird, spielt doch für den Klassennamen keine Rolle. Ein “fav” bleibt auch dann ein “fav”, wenn es ganz woanders oder bunt oder schwarz-weiss oder was weiss ich wie dargestellt wird. Egal, wie ich es darstelle, der Klassenname stimmt eben immer.

    Oder falls “links” = Plural von “link”:
    Egal, wo, wie oder ob ich das Dings darstelle, es bleibt immer “fav_links”. Denn das bezeichnet nicht das, wie es aussieht, sondern das, was es ist. Also absolut semantischer Klassenname.

  • Avatarbild von Tim Kraut Tim Kraut
    am 18. Mai 2011, 11:32 Uhr

    @Siegfried:
    Irgendwie reden wir hier alle ein wenig aneinander vorbei.
    Ich glaube, Christoph meinte mit fav_links den Plural von “link”, da class-Attribute ja mehrfach innerhalb eines Dokuments verwendet werden dürfen, würde es Sinn machen, dem ganzen einen Namen mit Mehrzahl zu geben.
    Ich glaube, jeder hier stimmt damit überein, dass man die class-Namen nicht nach dem Aussehen, sondern nach der Funktion/Semantik benennen sollte.

    Was mich allerdings ein stört (und scheinbar auch andere) ist, dass du sagst, dass man class-Namen nicht als Mittel zum Stylen von etwas, sondern nur als reine semantische Information nutzen sollte.
    id und class sind so eine Art API für das CSS, um auf das HTML zugreifen zu können. In manchen Situationen geht es einfach nicht anders (Beispiel Syntax-Highlighting in Codebeispielen). Und genau dafür wird es auch üblicherweise genutzt. Wenn dadurch noch ein Stück mehr Semantik erzeugt wird: Super, netter Nebeneffekt.
    Sofern es nicht um standardisierte Bezeichnungen wie bei den Microformats z.B. geht, bringt es keinen Mehrwert zwangshaft eine semantische Information in das class-Attribut zu stecken, ohne das Ziel zu haben, das Element später in irgendeiner Form zu stylen.

  • Avatarbild von Christoph Zillgens Christoph Zillgens
    am 18. Mai 2011, 11:47 Uhr

    Tim bringt es auf den Punkt, danke :)

  • Avatarbild von Siegfried Siegfried
    am 18. Mai 2011, 11:57 Uhr

    Vieleicht missverstehen wir uns hier tatsächlich.

    Also, ich meine, dass die Entscheidung, ob resp. welcher Klassenname verwendet werden soll, nicht vom Styling sondern nur von der Semantik abhängen sollte. Dass die so gewählten vorhandenen (oder eben auch nicht vorhandenen) Klassen dann auch zum Styling verwendet werden, ist nur logisch. Aber das ist eine andere Baustelle.

    Die Idee, auf Klassennamen zu verzichten, weil man die Elemente ja auch über z.B. Kindselektoren stylen kann, impliziert jedoch die Idee, dass die Klassennamen nur für das Styling da sind. Also, die Entscheidung, ob und welcher Klassenname verwendet wird, eine Frage des Stylings ist. Und eben dieses halte ich für falsch. Auf einen Klassennamen zu verzichten, weil man das Element auch anders stylen kann, ist genauso falsch, wie einen Klassennamen nur deshalb einzusetzen, weil man das Element anders nicht stylen kann. Die Frage nach Klassenname ja oder nein, und welcher Klassenname hat also Nix mit dem Styling zu tun. Das sind einfach zwei unterschiedliche Dinge, die getrennt bleiben sollten.

    Vielleicht noch mal ein Beispiel: Es macht einen Riesenunterschied, ob ich schreibe <span class=“gruen”>Blablubb</span>, oder ob ich schreibe <span class=“name”>Blablubb</span>. Natürlich kann und soll ich im css dann diesen Selektor verwenden, um das Dings dann grün anzumalen. Aber selbst im css macht es einen Unterschied, ob ich schreibe:

    span.gruen { color: green; }

    oder ob ich schreibe:
    span.name { color: green; }

    Das erste Statement sagt doch nur aus, dass ich Grünzeug gerne grün hätte. Na toll. Na und? Das Zweite hingegen sagt aus, dass ich Namen gerne in Grün hätte. Selbst hier macht es einen Unterschied.

    Ach, und noch was als Nachtrag: Ein class=“name” fügt natürlich nicht dem Dokument eine Bedeutung hinzu, sondern nur dem Inhalt des Elements, dessen Attribut diese Klasse ist. Wenn man dem Dokument als Ganzem über diesen Mechanismus eine Bedeutung verleihen wollte, müsste man dem html-Element einen solchen Klassennamen verpassen. Das könnte eine interessante Idee sein, aber das wird, glaube ich, bislang von Niemandem so gemacht.

    Aber das könnte man so machen. Man könnte beispielsweise schreiben:

    <html class=“specification”>

    Wenn es sich um eine html-Seite handelt, bei der es nur oder im Wesentlichen um eine Spezifikation geht. Aber auch hier hat die Wahl des Klassennamens, oder ob ich überhaupt einen Klassennamen verwende, Nichts mit irgendeinem Styling zu tun. Was nicht heisst, dass man es nicht verwenden könnte, wenn gewünscht. Aber ein <html class=“specification”> ist allemal besser als ein <html class=“lilablassblau”>. Da ist selbst ein nacktes <html> besser.

    Ich weiss nicht, wie ich das sonst noch ausdrücken soll.

  • Avatarbild von Siegfried Siegfried
    am 18. Mai 2011, 12:27 Uhr

    @Tim: Du schreibst:

    Wenn dadurch noch ein Stück mehr Semantik erzeugt wird: Super, netter Nebeneffekt.

    Genau das sehe ich genau umgekehrt. Klassennamen sind für die Semantik da. Wenn dadurch noch ein Stück mehr Stylingmöglichkeit erzeugt wird: Super, netter Nebeneffekt.

  • Avatarbild von Siegfried Siegfried
    am 18. Mai 2011, 12:42 Uhr

    Noch einer @Tim:

    Du Schreibst:

    da class-Attribute ja mehrfach innerhalb eines Dokuments verwendet werden dürfen, würde es Sinn machen, dem ganzen einen Namen mit Mehrzahl zu geben

    Auch das ist nicht richtig. Die Entscheidung, ob class oder id Attribut hängt in der Tat davon ab, ob ich auf der Seite mehrere davon habe, oder nicht. Aber die Frage nach Einzahl (“fav_link”) oder Plural (“fav_links”) hängt davon ab, ob der Container, dessen Klasse diese hier ist, einen oder mehrere Links enthält.

    Also, wenn Du die Links in eine Liste schreibst, dann würde das so aussehen:

    <ul class=“fav_links”>
    <li><a …>blablubb</a></li>
    <li><a …>blablubb</a></li>
    </ul>

    Hier wäre der Plural richtig. Im Zweifelsfall selbst dann, wenn diese Liste nur ein Listenelement enthält.

    Aber ein:

    <a class=“fav_link” href=”…>blablubb</a>

    Muss Einzahl sein. Hier sagt class=“fav_link” aus, dass es sich hier um einen von (wahrscheinlich) mehreren fav_links handelt. Das class=“fav_links” oben sagt aus, dass der Container (ul) mehrere Dinge des Typs fav_link enthält (oder enthalten kann).

    Man könnte also beide Klassen gleichzeitig verwenden. Allerdings wäre das doppelt gemoppelt. Würde ich eher vermeiden.

  • Avatarbild von Tim Kraut Tim Kraut
    am 18. Mai 2011, 12:43 Uhr

    @Siegfried:
    Ja, genau das dürfte hier der Streitpunkt sein.

    Ich verwende class-Attribute nur für das Styling, gebe dem Ganzen natürlich semantische Namen (also nichts, was mit dem Aussehen, der Position oder ähnlichem zu tun hat), aber das wars dann auch schon. Microformats etc. mal außen vor gelassen.

    Ich fürchte allerdings, dass wir so auf keinen gemeinsamen Nenner kommen werden.

  • Avatarbild von Siegfried Siegfried
    am 18. Mai 2011, 12:54 Uhr

    Naja, immerhin haben wir mal den Kernpunkt unserer Differenz gefunden und benannt :)

  • Avatarbild von Tim Kraut Tim Kraut
    am 18. Mai 2011, 13:08 Uhr

    @Siegfried:
    Bist du in allem so radikal? :-D
    Du verwendest auf deiner verlinkten Webseite immerhin Dublin Core und XHTML 1.1. Beides doch eher selten…

    Wieso sagst du, dass es nicht richtig ist, class-Attribute mit Plural-Namen zu befüllen? Mir ist keine Spezifikation bekannt, nach der das FALSCH ist.

    Ich könnte ja auch an mehreren Stellen irgendwelche besonderen Links (oder sonst was) haben. Jeder davon bekommt dann sein mehrzahliges class-Attribut und gut ist.

    Letztendlich hängt das aber einzig und allein vom persönlichen Geschmack und seinen eigenen (wahrscheinlich nicht einmal notierten) Konventionen.
    Was ist daran also falsch oder richtig?

  • Avatarbild von macx macx
    am 18. Mai 2011, 13:15 Uhr

    Siegfried, Klassennamen haben – da wiederhole ich mich – technisch nichts mit Semantik zu tun. Denn wo ist denn der Unterschied zwischen „favouriten“, „favoriten“, „Favs“, „faworitten“? Den kennst nur du als Autor. Selbst, wenn du alles richtig schreibst, heißt das noch lange nicht, dass das Element auch tatsächlich das beinhaltet, was du da deklarieren möchtest. Der eine schreibt es so, der andere ganz anders. Es gibt keine Standards, keinen gemeinsamen Nenner. Deshalb interpretiert Klassen weder Google noch der User.

    Es gibt Definitionen wie Microformats, die aber Tools notwenig machen, um aus Klassennamen eine Interpretation abzuleiten. Aber statt vcard hätten die Microformats-Macher das Ding auch sonnenblume nennen können. Ich hoffe du verstehst, worauf ich hinaus möchte.

    Schlussendlich möchte auch darauf hinweisen, dass für HTML5 neue Elemente definiert wurden, um Inhalte semantischer zu machen. Du möchtest doch nicht indirekt behaupten, dass HTML5 komplett überflüssig ist, weil es ja „semantische Klassennamen“ gibt, oder?

  • Avatarbild von Christoph Zillgens Christoph Zillgens
    am 18. Mai 2011, 14:19 Uhr

    Wie David es sagt, die Semantik in den Klassennamen ist nur für dich selbst und nicht allgemein gültig.

    Die Semantik des Inhalts eines Dokuments wird mit HTML-Elementen erreicht und nicht mit Klassen. Sonst wäre ja <h1>Überschrift</h1> gleichbedeutend wie <span class="h1">Überschrift</span>, was mitnichten der Fall ist!

    Wenn du Klassen nur da einsetzen möchtest, wo es an deiner Stelle den Inhalt (für dich) näher beschreibt, kannst du das gerne so machen, hilft aber keinem anderen. Dein Dokument wird durch das Hinzufügen einer Klasse, egal wo, semantisch nicht aufgewertet (außer für dich). Microformats sind ein Sonderfall, weil sie nicht zum HTML-Standard gehören.

    Du kannst es drehen und wenden, wie du möchtest, es ist legitimer Zweck der Klassen, als Hook fürs Styling zu dienen. Insofern ist deine Eingangsthese, es sei absurd, Kindselektoren zur Reduktion von Klassen einzusetzen, schlicht und einfach falsch.

  • Avatarbild von Siegfried Siegfried
    am 18. Mai 2011, 14:45 Uhr

    @Tim: Frei nach Radio Eriwan: Im Prinzip ja (radikal) :)

    Ich verwende übrigens nicht nur xhtml1.1, sondern auch html4.01 strict, und verwende http automatic content negotiation, um zwischen Beiden zu wählen. Und ich verwende für die meisten Seiten ebenfalls automatic content negotiation, um zwischen deutsch und englisch zu wählen. Und ich verwende alternate stylesheets, um es ein wenig bunter zu treiben. Aber das ist derzeit eher Spielerei. Meine HP ist Sowas wie meine Spielwiese. Die Seiten sind übrigens schon uralt, älter als 7 Jahre, in dieser Form. Ich werde demnächst auf html5 umstellen und dann noch mal besser und sauberer strukturieren.

    Wg. Singular vs. Plural: Wenn man so ansetzt, dass der Klassenname die Bedeutung des Inhalts angibt, dann macht es einen Unterschied, ob ein Container mehrere Dinge vom Typ XY enthalten kann, oder nur ein solches Ding. Wenn man die Bedeutung des Inhalts so spezifiziert, sollte man das auch sorgfältig tun. Da kann Singular oder Plural durchaus einen Unterschied machen.

    Wenn man die Klassennamen natürlich nicht zur näheren Spezifikation der Semantik heranzieht, kann man auch class=“sknjkgvntkö” schreiben, und dann ist Singular oder Plural sowieso egal.

    Das ist also keine Frage der Spezifikation, sondern einfach eine Konsequenz der Semantik.

    @Tim: Aus dem Grund sollte man für die Klassennamen standardisierte bekannte Vokabularien einsetzen. Zum Beispiel microformats. Aber auch Andere wären denkbar. Microformats erlaubt auch, eigene Vokabularien zu verwenden, wenn diese definiert werden (XMDP, http://microformats.org/wiki/rel-license-de#XMDP-Profil ). Nur sollte man das dann auch tun (das definieren, meine ich).

    @Christoph: Wie schon oben geschrieben, der erste Schritt für semantisches Markup ist die Korrekte Verwendung der richtigen html-Elemente. Und wenn diese Elemente ausreichen, um die Semantik ihres Inhalts ausreichend zu spezifizieren, ist es auch gut damit. Dann braucht es keinerlei Klassennamen mehr. Klassennamen braucht man dann, wenn man die eingebaute Semantik des Elements präzisieren möchte.

    Angenommen, eine Seite hätte zwei h1-Überschriften. Dann könnte man z.B. eine davon mit class=“dc:subject” auszeichnen, um festzulegen, dass diese Überschrift das Thema der Seite enthält. Streng genommen legt man damit allerdings nur fest, dass eben diese Überschrift das Thema der Seite enthält. Die Überschrift ist bis html4 nicht direkt mit irgendwelchen Paragraphen korreliert. Das ist sein html5 mit article und section anders und besser.

    Und nochmal zum Schluss (hier geht es um den von Tim richtig erkannten Unterschied in der Sichtweise): Ob ich bei solch einer Überschrift ein class=“dc:subject” verwende oder nicht, hat Nichts damit zu tun, ob ich diese Überschrift stylen will oder nicht. Wenn ich diese Überschrift stylen will, kann ich natürlich diesen Klassennamen verwenden. Wenn ich diese Überschrift aber gar nicht stylen will, so bleibt das dennoch die Überschrift, die das Thema enthält, und wird daher mit class=“dc:subject” passend ausgezeichnet.

    Richtig ist auf jeden Fall, dass ein <span class=“h1”> noch lange keine Überschrift macht.

    So, und jetzt muss ich los. Habe noch Vorlesung. Ggf. bis morgen.

  • Avatarbild von Matthias Mees Matthias Mees
    am 18. Mai 2011, 15:37 Uhr

    Keiner der Diskutanten bestreitet oder bezweifelt die Nützlichkeit semantischer Klassennamen. Sie sind aber lediglich eine Empfehlung (der Spezifikation) oder eine „best practice“, keine notwendige Bedingung.

    Sollten sie eine notwendige Bedingung sein, müssten sie innerhalb der Spezifikation definiert sein, was die Möglichkeiten nicht nur recht massiv einschränken würde, sondern schlicht und einfach (innerhalb der HTML-Spezifikation) nicht der Fall ist. Nicht standardisierte Semantik ist subjektiv und damit nur bedingt nützlich.

  • Avatarbild von Siegfried Siegfried
    am 19. Mai 2011, 08:44 Uhr

    @Matthias: Technisch gesehen ebsteht zunächst mal keine Notwendigkeit. Jedenfalls auf den ersten Blick. Semantik ist also “keine notwendige Bedingung”. Da gebe ich Dir Recht.

    Gehen wir mal einen Schritt weiter. HTML Tags sind für den Leser einer seite ebenfalls völlig wurscht, denn die bekommt er gar nicht zu sehen. Wer interessiert sich für die Tags? Nun, der Browser. Der Browser als Werkzeug interpretiert die Tags. Und er interpretiert die Klassennamen und die Stylesheets. Aber: Der Browser muss den Seiteninhalt darstellen, nicht verstehen. Deshalb ist dem Browser jedwede Semantik einer Webseite schnurzpiepegal. Es ist nicht seine Aufgabe, den Inhalt zu verstehen. Wenn man also nur vom Browser ausgeht als einzigem Wekzeug, das diese Seiten jemals zu sehen bekommt, dann ist Semantik sowieso für die Füße. Dann wäre es allerdings konsequenterweise auch egal, ob ich <h1>Überschrift</h1> oder <span class=“h1”>Überschrift<&span> schreibe. Dem Browser ist das echt egal.

    Anders sieht es aus, wenn andere Werkzeuge ins Spiel kommen, die nach Möglichkeit den Inhalt verstehen sollen. Wir Menschen haben jede Menge implizites Wissen. Der Computer hat Null implizites Wissen. Alles, was der Computer weiss, hat man ihm explizit so gesagt. Darum geht es bei Semantik. Wenn es also darum geht, den Text maschinell zu verstehen, dann ist semantik Markup das Einzige, was zählt.

    Suchmaschinen sind die ältesten und ausgereiftesten Maschinen, die Webseiten durchwühlen. Allerdings sind Suchmaschinen nicht die einzig denkbaren. Suchmaschinen verstehen den Inhalt einer Seite nicht. Deshalb ist es sehr schwierig, zu einer Suchanfrage passende Antworten in Form von Seiten zu finden. Und das wird für Suchmaschinen immer schwerer (siehe http://wadhwa.com/2011/01/29/the-future-of-search-who-will-win-the-spam-wars/) Semantic Markup könnte hier helfen.

    Natürlich ist semantic markup keine Voraussetzung, um schön aussehende Seiten zu erstellen. Aber es ist Voraussetzung dafür, dass irgendwann Maschinen die Seiten tatsächlich verstehen.

  • Avatarbild von macx macx
    am 19. Mai 2011, 13:25 Uhr

    Und genau das sollte man erreichen durch semantisch passende HTML-Elemente und nicht durch den Missbrauch von Klassennamen, den man durch ein Dritt-Tool (Browserplugin etc.) Semantik einprügeln möchte. Denn genau so wie du ein Wort sicher anders definieren würdest wie dein Nachbar von nebenan, benötigt es fest definierte Standards. Ohne diese wird es ein heilloses Durcheinander. Webseiten gewinnen an Profil durch HTML5 und WAI-ARIA, nicht durch Klassennamen – auch wenn du es noch so gut meinst bei der Definition.

Und was hast du zum Thema zu sagen?

Fülle bitte alle mit *-gekennzeichneten Felder aus.


Du darfst Textile verwenden, um deinen Beitrag auszuzeichen.