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à.

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”. ;)

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.

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.

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

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.

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.

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..

@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)!

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.

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…

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

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.

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

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!

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

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.

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.

@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.

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

Max Mustermann

@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?

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.

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.

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.

@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.

@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.

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 Blablubb, oder ob ich schreibe Blablubb. 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:

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 ist allemal besser als ein . Da ist selbst ein nacktes besser.

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

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:

• blablubb


• blablubb

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

Aber ein:

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

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?

@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 noch lange keine Überschrift macht.

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

@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

Überschrift