nicht angemeldet
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Tim Tepaße
Hallo werte Selfgemeinde!
Ich beschäftige mich seit einiger Zeit mit den Neuerungen von HTML5 und deren Konzept.
Vermutlich bin ich nicht intelligent genug, um die Dinge alle richtig und vollständig zu verstehen, denn so manches erschließt sich mir auch nach dem 20. Mal lesen nicht ...!
Deshalb hier mal in loser Reihenfolge einige Punkte, die ich nicht (so ganz) verstehe, und auch meine Meinung zu einigen Dingen. Wohl gemerkt - einige Aussagen sind bewußt etwas provokant gehalten. Ich hoffe ggf. auf eine rege Diskussion, die die Dinge vlt. etwas erhellt.
Outline algorithm:
Mal abgesehen davon, dass dieser derzeit noch von keinem HTML verarbeitenden Programm unterstützt wird, scheint mir hier in erster Linie das Problem im möglichen Styling per CSS zu liegen.
Folgender Beispielcode:
Der Martin
<body>
<h1>My fantastic site</h1>
<section>
<h1>About me</h1>
<p>I am a man who lives a fascinating life. Oh the stories I could tell you...</p>
<section>
<h1>What I do for a living 1</h1>
<p>I sell enterprise-managed ant farms.</p>
<h2>What I do for a living 2</h2>
<p>I sell enterprise-managed ant farms.</p>
</section>
</section>
<section>
<h1>Contact</h1>
<p>Shout my name and I will come to you.</p>
</section>
</body>
erzeugt folgende Outline:
1. My fantastic site
1. About me
1. What I do for a living 1
1. What I do for a living 2
2. Contact
Das Problem dabei ist, dass neuere Browser "What I do for a living 1" per default als <h3> Element behandeln, wohingegen "What I do for a living 2" aber völlig regulär als <h2> behandelt wird, obwohl es ja laut unserer Outline eindeutig ein <h4> Element sein müsste.
Damit es entsprechend funktioniert, ohne die Outline zu verändern, muss ich anstelle des <h2> Elements ein <h1> verwenden und dieses aber wiederum in ein weiteres <section> Element verpacken:
<body>
<h1>My fantastic site</h1>
<section>
<h1>About me</h1>
<p>I am a man who lives a fascinating life. Oh the stories I could tell you...</p>
<section>
<h1>What I do for a living 1</h1>
<p>I sell enterprise-managed ant farms.</p>
<section>
<h1>What I do for a living 2</h1>
<p>I sell enterprise-managed ant farms.</p>
</section>
</section>
</section>
<section>
<h1>Contact</h1>
<p>Shout my name and I will come to you.</p>
</section>
</body>
Das heißt für mich, dass wenn ich Überschriften gemäß ihrer eigentlichen Gewichtung optisch entsprechend dargestellt haben möchte (was ja nicht ganz unwesentlich ist), dann muss ich auf das Konzept der ausschließlichen Verwendung von <h1> Elementen zurückgreifen. Zusätzlich wird mein Quellcode dadurch noch aufgebläht, weil ich jedesmal noch ein weiteres 'sectioning' Element drumherum benötige. Von der Einbindung von Code aus "fremden" Quellen (bspw. als Zitat) mal ganz zu schweigen ...! Oder es bleibt alles beim alten, indem ich selber für die Wahl des korrekten <hx> Elements zuständig bin (womit ja dann nichts gewonnen wäre).
Ebenso unverständlich ist mir, warum man, will man eine fehlende Überschrift in der Outline vermeiden, der Body Sektion zwingend eine Überschrift verpassen muss, und warum man dafür nicht das <title> Element aus dem <head> verwendet hat!?
Oft liest man im Zusammenhang mit HTML5 und der damit verbundenen Einführung neuer Elemente, dies diene der besseren semantischen Gliederung eines Dokuments. Schön und gut, aber halten wir mal fest, dass User/ Besucher einer Seite nicht den Quellcode präsentiert bekommen, sondern das durch einen UA interpretierte Ergebnis dessen. Hier handelt es sich also schon mal nicht um eine Neuerung, Bereicherung oder Verbesserung für den User (zumindest nicht für visuelle Ausgabemedien), sondern allenfalls um welche für Suchmaschinen & Co.!
Auch erscheint mir der gewählte Weg, nämlich der der neuen Elemente, wenig sinnvoll. Denn erstens reichen diese paar neuen Elemente garantiert nicht aus und zweitens sind Veränderungen/ Erweiterungen schwierig, da diese immer von der jeweiligen Unterstützung durch die Browser abhängig sind.
Ich hätte es als wesentlich sinnvoller erachtet, wenn man stattdessen ein/ mehrere neues/ neue Attribut/e eingeführt hätte, wie bspw. die Übernahme des 'role' Attributs aus XHTML. Denn mal ehrlich - wo ist der Unterschied zwischen <nav> und <div role="nav">? Einen Unterschied gibt es auf jeden Fall: Die Handhabung unbekannter Elemente (im Vergleich zu der unbekannter Attribute) seitens der Browser. Und wie groß ist der tatsächliche Nutzen dieses neuen <nav> Elements, wenn es sowohl die Hauptnavigation einer Seite, als auch die Blogroll eines Blogs oder die Sammlung von Links zu anderen Artikeln in einem CMS umschließen kann?
Und mit den anderen neuen Elementen verhält es sich imho genauso. Ebenfalls bestens als "ungünstig" ist auch die Namensgebung zu erachten. So ist es doch schon ein quasi Standard, dass sehr viele Autoren ihre Seiten mittels DIV Container in <div id="header">, <div id="nav">, <div id="content"> und <div id="footer"> unterteilen (nicht zuletzt auch durch die weit verbreiteten Skripte wie Wordpress & Co.). Sehr clever, genau diese Bezeichnungen zu wählen und den Elementen dabei aber eine teils völlig andere Bedeutung zukommen zu lassen. So sieht man bspw. schon sehr häufig auf Seiten, die HTML5 verwenden, den Einsatz von <header> anstelle von <div id="header"> (gleiches gilt für das <footer> Element). Tatsächlich ist das <header> Element mehr zur Kennzeichnung von Überschriften/ Titeln einzelner semantischer Blöcke gedacht (vgl. http://www.w3.org/TR/html5/sections.html#the-article-element). Mir stellt sich in dem Zusammenhang erneut die Frage nach dem Sinn & Nutzen, außer dass der Quelltext zusätzlich aufgebläht wird?
Und zumindest bei "aufwändigeren" Layouts wird man auch zukünftig nicht um die Verwendung von DIVs herumkommen. Das bestärkt mich in meiner Meinung, dass es besser gewesen wäre, Autoren die Möglichkeit zu geben, bestimmten ansonsten "inhaltsleeren" DIV Elementen per Attribut eine entsprechende semantische Bedeutung zu verpassen (und/ oder auch eine repräsentative).
Viele der weiteren Neuerungen von HTML5 mögen durchaus sehr sinnvoll sein, allerdings habe ich mich mit denen noch nicht eingehend genug beschäftigt, um mir eine Meinung zu bilden.
Die oben genannten Neuerungen sind aber für mich auch primär die, um die zukünftig kein Autor drumherum kommen wird (sofern er HTML5 verwendet). Insofern "reichen" mir diese auch für den Anfang ...!
Mit anderen Worten sehe ich es so, dass uns HTML5 im wesentlichen eine Verkomplizierung von HTML bringt (aufgrund des neuen Sectioning Modells), deren Nutzen für den "gemeinen Autor" für mich mehr als fragwürdig ist. Auch semantisch korrektes Markup zu schreiben dürfte eher schwieriger, als einfacher werden, weil gerade die neuen Elemente dafür prädestiniert sind, sie "falsch" zu verwenden.
Ferner werden zumindest auch neue "Stolpersteine" bezüglich des Stylings durch CSS geschaffen.
Mein Fazit:
Wesentliche Teile der Neuerungen sind wenig sinnvoll und hätten anders besser gelöst werden können. Auch werden teilweise unnötig neue Probleme geschaffen. Und das alles mit einem fragwürdigen Nutzen für Autoren und Besucher.
Das bringt mich zu der alles entscheidenden Frage: "Warum ich sollte ich HTML5 (jetzt|zukünftig|jemals) verwenden?"
Aber vielleicht liegt es wie eingangs bereits erwähnt auch nur daran, dass sich mir der "große Zusammenhang" (bisher zumindest) noch nicht erschlossen hat?
Wie ist eure Meinung/ Sicht der Dinge?
Gruß Gunther
Sections funktionieren eher so - besonders wenn deine "What I do for a living"-Abschnitte gleichrangig sind.
<section>
<h1>What I do for a living 1</h1>
<p>I sell enterprise-managed ant farms.</p>
</section>
<section>
<h1>What I do for a living 2</h1>
<p>I sell enterprise-managed ant farms.</p>
</section>
Sections funktionieren eher so - besonders wenn deine "What I do for a living"-Abschnitte gleichrangig sind.
Nein, sollen sie eben nicht sein. Es geht auch nicht um das <section> Element, sondern vielmehr um die Outline. Wie du diese erreichst, ist dabei erstmal nebensächlich. Ich wollte damit das m.M.n. bestehende Problem einer entsprechenden Auszeichnung der jeweiligen Überschriften per CSS aufzeigen.
Gruß Gunther
Hallo,
Das heißt für mich, dass wenn ich Überschriften gemäß ihrer eigentlichen Gewichtung optisch entsprechend dargestellt haben möchte (was ja nicht ganz unwesentlich ist), dann muss ich auf das Konzept der ausschließlichen Verwendung von <h1> Elementen zurückgreifen.
Nein, musst du nicht.
Erstens kannst du weiterhin h1, h2, h3 verwenden, wie es in HTML 4 üblich ist, zweitens hast du Sections anscheinend missverstanden. Wenn du sämtliche Abschnitte sinnvoll mit Sectioning-Elementen auszeichnest, dann funktioniert das auch hervorragend. Ob mit h1, h2, h3 ... oder mit ausschließlich h1. Ich verstehe dein Problem damit nicht.
http://coding.smashingmagazine.com/2011/08/16/html5-and-the-document-outlining-algorithm/ bietet eine gute Übersicht und Links.
Zusätzlich wird mein Quellcode dadurch noch aufgebläht, weil ich jedesmal noch ein weiteres 'sectioning' Element drumherum benötige.
?? Ein Abschnitt wird mit section (oder article, aside, footer, header, nav) ausgezeichnet, das ist der Sinn davon.
Oder es bleibt alles beim alten, indem ich selber für die Wahl des korrekten <hx> Elements zuständig bin (womit ja dann nichts gewonnen wäre).
Doch. Du hast Abschnitte explizit als solche ausgezeichnet, als dass es nur implizit über die Überschriftenhierarchie getan wird.
Ebenso unverständlich ist mir, warum man, will man eine fehlende Überschrift in der Outline vermeiden, der Body Sektion zwingend eine Überschrift verpassen muss, und warum man dafür nicht das <title> Element aus dem <head> verwendet hat!?
Weil der Titel des Dokuments gleich nicht die oberste Überschrift des Dokuments ist?
Davon abgesehen sehe ich nicht, was so schwierig dabei ist, die oberste Überschrift mit h1 auszuzeichnen und dafür zu sorgen, dass sie vom Sectioning zur obersten body-Section gehört. Man macht m.M.n. etwas falsch, wenn es nicht automatisch so ist.
halten wir mal fest, dass User/ Besucher einer Seite nicht den Quellcode präsentiert bekommen, sondern das durch einen UA interpretierte Ergebnis dessen. Hier handelt es sich also schon mal nicht um eine Neuerung, Bereicherung oder Verbesserung für den User (zumindest nicht für visuelle Ausgabemedien), sondern allenfalls um welche für Suchmaschinen & Co.!
Ja. Das nennt sich semantisches Markup. Das ist, was HTML seit 15 Jahren tut. Der Benutzer sieht ggf. nicht, ob ein ihm fett erscheinender Text mit <b> ausgezeichnet ist oder mit <strong>, welches per CSS fett formatiert wurde. Der Benutzer sieht ggf. nicht, ob eine Überschrift mit <br><font></font><br> ausgezeichnet ist, oder mit <h2>. Semantisches Markup ist trotzdem vorzuziehen.
Auch erscheint mir der gewählte Weg, nämlich der der neuen Elemente, wenig sinnvoll. Denn erstens reichen diese paar neuen Elemente garantiert nicht aus und zweitens sind Veränderungen/ Erweiterungen schwierig, da diese immer von der jeweiligen Unterstützung durch die Browser abhängig sind.
So ist die Welt der Browsertechnik. Neuerungen sind anfangs nie von allen Browsern unterstützt. Ist das jetzt ein Argument, das prinzipiell gegen sämtliche Erweiterungen spricht? Sicher nicht.
Wie schwierig Erweiterungen sind, hängt ganz vom jeweiligen Element ab. Beim Sectioning ist es eigentlich kein Problem, wenn man den IE per HTML5-Shiv versorgt. Bei komplexeren Elementen wie canvas bedarf es aufwändigerer Polyfills.
Ich hätte es als wesentlich sinnvoller erachtet, wenn man stattdessen ein/ mehrere neues/ neue Attribut/e eingeführt hätte, wie bspw. die Übernahme des 'role' Attributs aus XHTML.
role ist Bestandteil von WAI-ARIA und WAI-ARIA ist in HTML5 direkt nutzbar, oft zusätzlich zu den HTML5-Elementen. Andere HTML5-Elemente haben von Haus aus eine Landmark-Role.
http://dev.w3.org/html5/spec/content-models.html#wai-aria
http://www.paciellogroup.com/blog/2010/10/using-wai-aria-landmark-roles/
Denn mal ehrlich - wo ist der Unterschied zwischen <nav> und <div role="nav">?
Das eine ist ein spezifisches HTML-Element mit der passenden Semantik und das andere ist ein generisches HTML-Element mit einer Erweiterung aus einem anderen Sprachvokabular, um seine Bedeutung zu spezifizieren. Welches ist wohl vorzuziehen?
Und wie groß ist der tatsächliche Nutzen dieses neuen <nav> Elements, wenn es sowohl die Hauptnavigation einer Seite, als auch die Blogroll eines Blogs oder die Sammlung von Links zu anderen Artikeln in einem CMS umschließen kann?
Wenn man nav richtig verwendet, dann ist der Nutzen groß.
Ein Blogroll oder eine Linksammlung sollten nicht mit nav ausgezeichnet werden.
So sieht man bspw. schon sehr häufig auf Seiten, die HTML5 verwenden, den Einsatz von <header> anstelle von <div id="header"> (gleiches gilt für das <footer> Element).
Dagegen spricht nichts. Die header- und footer-Elemente können auf oberster Section-Ebene für viele bestehende Header und Footer verwendet werden. Nicht immer, aber häufig.
Tatsächlich ist das <header> Element mehr zur Kennzeichnung von Überschriften/ Titeln einzelner semantischer Blöcke gedacht (vgl. http://www.w3.org/TR/html5/sections.html#the-article-element).
Das ist kein Widerspruch.
Und zumindest bei "aufwändigeren" Layouts wird man auch zukünftig nicht um die Verwendung von DIVs herumkommen.
Selbstverständlich. div-Elemente existieren weiterhin und haben ihre Anwendungszwecke. Sectioning-Elemente waren nie als ein Ersatz für div als rein gruppierendes Element ohne Sectioning-Bedeutung gedacht.
Das bestärkt mich in meiner Meinung, dass es besser gewesen wäre, Autoren die Möglichkeit zu geben, bestimmten ansonsten "inhaltsleeren" DIV Elementen per Attribut eine entsprechende semantische Bedeutung zu verpassen (und/ oder auch eine repräsentative).
Das tun die neuen Sectioning-Elemente.
Die oben genannten Neuerungen sind aber für mich auch primär die, um die zukünftig kein Autor drumherum kommen wird (sofern er HTML5 verwendet).
Jeder kann darum herum kommen. Es wird niemand dazu gezwungen, die neuen Elemente zu verwenden.
Auch semantisch korrektes Markup zu schreiben dürfte eher schwieriger, als einfacher werden, weil gerade die neuen Elemente dafür prädestiniert sind, sie "falsch" zu verwenden.
Das ist nun nichts neues. Auch die Elemente von HTML 4 waren ständig Gegenstand einer Diskussion um deren richtige Benutzung. HTML 5 hat da aber mehr für Aufklärung gesorgt. Es ist weitgehend gut definiert, für was die neuen Elemente gedacht sind. Was natürlich nicht verhindern kann, dass irgendjemand sie falsch verwendet. Diese Möglichkeit ist aber kein Argument gegen sie.
Aber vielleicht liegt es wie eingangs bereits erwähnt auch nur daran, dass sich mir der "große Zusammenhang" (bisher zumindest) noch nicht erschlossen hat?
Zumindest scheinst du noch einigen Missverständnissen aufzusitzen.
Mathias
Hallo,
Das heißt für mich, dass wenn ich Überschriften gemäß ihrer eigentlichen Gewichtung optisch entsprechend dargestellt haben möchte (was ja nicht ganz unwesentlich ist), dann muss ich auf das Konzept der ausschließlichen Verwendung von <h1> Elementen zurückgreifen.
Nein, musst du nicht.
Erstens kannst du weiterhin h1, h2, h3 verwenden, wie es in HTML 4 üblich ist,
Das sagte ich ja bereits. Nur was habe ich dann durch HTML5 "gewonnen"? Nach meinem Verständnis sollte doch gerade die Problematik der Überschriften Hierarchien (insbesondere bei dynamisch generierten Seiten) gelöst werden.
zweitens hast du Sections anscheinend missverstanden.
Nein, habe ich nicht.
Wenn du sämtliche Abschnitte sinnvoll mit Sectioning-Elementen auszeichnest, dann funktioniert das auch hervorragend. Ob mit h1, h2, h3 ... oder mit ausschließlich h1. Ich verstehe dein Problem damit nicht.
Den Eindruck habe ich auch. Was ich sagen will, ist dass das Problem der Überschriften Hierarchien nicht gelöst, sondern lediglich verlagert worden ist, nämlich von den Überschriften zu den Sections. Damit hat man als Autor unterm Strich nichts gewonnen. Stattdessen muss man aber zukünftig verdammt darauf aufpassen, dass man die gewünschte Dokument Struktur (Outline) erhält.
http://coding.smashingmagazine.com/2011/08/16/html5-and-the-document-outlining-algorithm/ bietet eine gute Übersicht und Links.
Danke - die Quellen sind mir alle bekannt und ich habe die meisten davon auch bereits ausführlich studiert.
Zusätzlich wird mein Quellcode dadurch noch aufgebläht, weil ich jedesmal noch ein weiteres 'sectioning' Element drumherum benötige.
?? Ein Abschnitt wird mit section (oder article, aside, footer, header, nav) ausgezeichnet, das ist der Sinn davon.
Du irrst hier übrigens, was das header und footer Element anbelangt - http://www.w3.org/TR/html5/sections.html#the-header-element
Oder es bleibt alles beim alten, indem ich selber für die Wahl des korrekten <hx> Elements zuständig bin (womit ja dann nichts gewonnen wäre).
Doch. Du hast Abschnitte explizit als solche ausgezeichnet, als dass es nur implizit über die Überschriftenhierarchie getan wird.
OK. Und welchen Nutzen/Sinn hat das (für 90% aller Webseiten)?
Ebenso unverständlich ist mir, warum man, will man eine fehlende Überschrift in der Outline vermeiden, der Body Sektion zwingend eine Überschrift verpassen muss, und warum man dafür nicht das <title> Element aus dem <head> verwendet hat!?
Weil der Titel des Dokuments gleich nicht die oberste Überschrift des Dokuments ist?
Davon abgesehen sehe ich nicht, was so schwierig dabei ist, die oberste Überschrift mit h1 auszuzeichnen und dafür zu sorgen, dass sie vom Sectioning zur obersten body-Section gehört. Man macht m.M.n. etwas falsch, wenn es nicht automatisch so ist.
Ach, du meinst so wie beim Weblog?
Das kommt für mich dem Zwang zu
<body><h1></h1>...
gleich. Und ich frage ernsthaft nach dem Sinn & Zweck. Wenn die Body (=Root) Sektion keine Überschrift hat, warum wird dann nicht automatisch der <title> genommen? Das würde ja nun wirklich keinem weh tun, aber sehr wirkungsvoll verhindern, dass eine Outline mit fehlender oberster Überschrift entsteht. Frei nach dem Motto "Keep it as simple as possible!" und nicht immer mehr "Stolpersteine" ...!
halten wir mal fest, dass User/ Besucher einer Seite nicht den Quellcode präsentiert bekommen, sondern das durch einen UA interpretierte Ergebnis dessen. Hier handelt es sich also schon mal nicht um eine Neuerung, Bereicherung oder Verbesserung für den User (zumindest nicht für visuelle Ausgabemedien), sondern allenfalls um welche für Suchmaschinen & Co.!
Ja. Das nennt sich semantisches Markup. Das ist, was HTML seit 15 Jahren tut. Der Benutzer sieht ggf. nicht, ob ein ihm fett erscheinender Text mit <b> ausgezeichnet ist oder mit <strong>, welches per CSS fett formatiert wurde. Der Benutzer sieht ggf. nicht, ob eine Überschrift mit <br><font></font><br> ausgezeichnet ist, oder mit <h2>. Semantisches Markup ist trotzdem vorzuziehen.
Auch wenn ich dir im Kern durchaus zustimme, würde mich dennoch interessieren warum?
Denn prinzipiell zählt ja wohl erstmal die syntaktische Korrektheit. Und die Semantik (für den User) ergibt sich bei visuellen Ausgabemedien durch die Präsentation (also letztlich durch die CSS Formatierung).
Auch erscheint mir der gewählte Weg, nämlich der der neuen Elemente, wenig sinnvoll. Denn erstens reichen diese paar neuen Elemente garantiert nicht aus und zweitens sind Veränderungen/ Erweiterungen schwierig, da diese immer von der jeweiligen Unterstützung durch die Browser abhängig sind.
So ist die Welt der Browsertechnik. Neuerungen sind anfangs nie von allen Browsern unterstützt. Ist das jetzt ein Argument, das prinzipiell gegen sämtliche Erweiterungen spricht? Sicher nicht.
Es geht nicht um die Frage Neuerungen Ja oder Nein, sondern darum Wie!
Wie schwierig Erweiterungen sind, hängt ganz vom jeweiligen Element ab. Beim Sectioning ist es eigentlich kein Problem, wenn man den IE per HTML5-Shiv versorgt. Bei komplexeren Elementen wie canvas bedarf es aufwändigerer Polyfills.
Alle diese Varianten setzen Javascript voraus. Aber darum geht es auch nicht. Bisher war eine der obersten Grundregeln, dass ein Browser alles ignoriert, was er nicht kennt. Wenn man sich weiterhin an diesen Grundsatz hält (der sich imho sehr bewährt hat), dann erscheint mir es zumindest sinnvoller, eher neue Attribute anstelle von neuen Elementen zu verwenden. Denn wenn ein Attribut mangels Kenntnis ignoriert wird, dann geht lediglich ein Stück der Semantik des Markups "verloren"!
Ich hätte es als wesentlich sinnvoller erachtet, wenn man stattdessen ein/ mehrere neues/ neue Attribut/e eingeführt hätte, wie bspw. die Übernahme des 'role' Attributs aus XHTML.
role ist Bestandteil von WAI-ARIA und WAI-ARIA ist in HTML5 direkt nutzbar, oft zusätzlich zu den HTML5-Elementen. Andere HTML5-Elemente haben von Haus aus eine Landmark-Role.
http://dev.w3.org/html5/spec/content-models.html#wai-aria
http://www.paciellogroup.com/blog/2010/10/using-wai-aria-landmark-roles/
Es kann doch nicht Sinn der Sache sein, dass wenn ich schon einen Standard erweitere, bzw. teilweise völlig neu definiere, von vorneherein auf Bestandteile anderer Standards zurückzugreifen, anstatt diese direkt in den Standard zu implementieren.
Denn mal ehrlich - wo ist der Unterschied zwischen <nav> und <div role="nav">?
Das eine ist ein spezifisches HTML-Element mit der passenden Semantik und das andere ist ein generisches HTML-Element mit einer Erweiterung aus einem anderen Sprachvokabular, um seine Bedeutung zu spezifizieren. Welches ist wohl vorzuziehen?
Man kann Dinge auch absichtlich missverstehen ...! Wie man das Attribut nennt, sei doch erstmal dahingestellt. Von mir aus kannst du es auch "meaning" oder sonstwie nennen. Und imho geht eben vielen der neuen Elemente eine entsprechende semantische Bedeutung ab, bzw. ist so "verschwommen", dass die Bedeutung gegen Null geht - bspw. beim <aside> Element. Aber auch <header> und <footer> sind nicht viel eindeutiger. Hier wäre man eben m.E.n. mit einem, bzw. mehreren neuen Attributen und einer entsprechenden Vielzahl möglicher Werte wesentlich besser bedient gewesen. Zumal dieses "System" wesentlich besser und einfacher zu erweitern wäre und außerdem die Möglichkeit der Angabe mehrerer Werte zu einer genaueren Spezifizierung zugelassen hätte.
Und wie groß ist der tatsächliche Nutzen dieses neuen <nav> Elements, wenn es sowohl die Hauptnavigation einer Seite, als auch die Blogroll eines Blogs oder die Sammlung von Links zu anderen Artikeln in einem CMS umschließen kann?
Wenn man nav richtig verwendet, dann ist der Nutzen groß.
Ein Blogroll oder eine Linksammlung sollten nicht mit nav ausgezeichnet werden.
Sagt wer?
Zitat:"The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links." (http://www.w3.org/TR/html5/sections.html#the-nav-element)
Das kann man aber auch völlig anders interpretieren. Das ist im Grunde auch einer meiner Kritikpunkte, dass ich der Auffassung bin, dass der Wunsch nach semantisch korrekterem Markup bei der gewählten Umsetzung eher zum Gegenteil führt.
So sieht man bspw. schon sehr häufig auf Seiten, die HTML5 verwenden, den Einsatz von <header> anstelle von <div id="header"> (gleiches gilt für das <footer> Element).
Dagegen spricht nichts. Die header- und footer-Elemente können auf oberster Section-Ebene für viele bestehende Header und Footer verwendet werden. Nicht immer, aber häufig.
Das mag ja sein, ist aber nicht der von mir angesprochene Punkt. Denn ein <div id="header"> ist häufig nicht auf den Inhalt (also die Semantik) bezogen, sondern vielmehr auf die Präsentation und kann bspw. die Hauptnavigation beinhalten. Die Wahl der Bezeichnungen "verleitet" also eindeutig aufgrund gängiger Praxis und bestehender Gewohnheiten dazu, semantisch unkorrektes Markup zu schreiben - sehr praktisch wie ich finde, wenn man eigentlich das genaue Gegenteil erreichen will.
Tatsächlich ist das <header> Element mehr zur Kennzeichnung von Überschriften/ Titeln einzelner semantischer Blöcke gedacht (vgl. http://www.w3.org/TR/html5/sections.html#the-article-element).
Das ist kein Widerspruch.
Nö, das nicht, aber s.o.!
Und zumindest bei "aufwändigeren" Layouts wird man auch zukünftig nicht um die Verwendung von DIVs herumkommen.
Selbstverständlich. div-Elemente existieren weiterhin und haben ihre Anwendungszwecke. Sectioning-Elemente waren nie als ein Ersatz für div als rein gruppierendes Element ohne Sectioning-Bedeutung gedacht.
Das bestärkt mich in meiner Meinung, dass es besser gewesen wäre, Autoren die Möglichkeit zu geben, bestimmten ansonsten "inhaltsleeren" DIV Elementen per Attribut eine entsprechende semantische Bedeutung zu verpassen (und/ oder auch eine repräsentative).
Das tun die neuen Sectioning-Elemente.
Ja, und andersherum hätte man dasselbe erreicht mit mehr Vorteilen und ohne die jetzigen Nachteile ...
Die oben genannten Neuerungen sind aber für mich auch primär die, um die zukünftig kein Autor drumherum kommen wird (sofern er HTML5 verwendet).
Jeder kann darum herum kommen. Es wird niemand dazu gezwungen, die neuen Elemente zu verwenden.
Sehr sinnig ...
Auch semantisch korrektes Markup zu schreiben dürfte eher schwieriger, als einfacher werden, weil gerade die neuen Elemente dafür prädestiniert sind, sie "falsch" zu verwenden.
Das ist nun nichts neues. Auch die Elemente von HTML 4 waren ständig Gegenstand einer Diskussion um deren richtige Benutzung. HTML 5 hat da aber mehr für Aufklärung gesorgt. Es ist weitgehend gut definiert, für was die neuen Elemente gedacht sind.
Entschuldige bitte - die "Beschreibungen" könnten kaum "schwammiger" formuliert sein. Beispiel gefällig?
"Not all groups of links on a page need to be in a nav element — the element is primarily intended for sections that consist of major navigation blocks. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases; while a nav element can be used in such cases, it is usually unnecessary."
Schon alleine hier hätte doch eigentlich jedem auffallen müssen, dass eventuell die Möglichkeit einer Unterscheidung zwischen der Hauptnavigation einer Seite und anderen "Linksammlungen" einer Seite ganz gut getan hätte. Und auch Formulierungen wie "not all .. need to be ..." lassen mehr Interpretationsspielraum als dass sie für Klarheit sorgen würden. Und so zieht sich das durch weite Teile der Spezifikation.
Und von einer "Aufklärung" durch HTML5 kann meiner Meinung nach auch keine Rede sein. Vielmehr von allgemeiner "Verwirrung", sei es durch Beiträge, die 2-3 Jahre alt sind und durch zwischenzeitliche Änderungen am Entwurf längst überholt sind, oder durch die unterschiedliche Auslegung der o.g. "sehr allgemein/ schwammig gehaltenen Definitionen" seitens der Autoren.
Und solange der gesamte Entwurf nicht endgültig fertig ist (wenn er das überhaupt jemals sein wird), kann sowieso niemand mit Sicherheit sagen, was nun letztendlich richtig oder falsch ist.
Was natürlich nicht verhindern kann, dass irgendjemand sie falsch verwendet. Diese Möglichkeit ist aber kein Argument gegen sie.
Dinge unnötig verwirrend oder kompliziert zu machen, bzw. Definitionen sehr allgemein zu halten, sind aber auch keines dafür.
Aber vielleicht liegt es wie eingangs bereits erwähnt auch nur daran, dass sich mir der "große Zusammenhang" (bisher zumindest) noch nicht erschlossen hat?
Zumindest scheinst du noch einigen Missverständnissen aufzusitzen.
Das mag ja sein. Allerdings vermute ich mal, dass es nicht nur mir so geht. Und wenn ich mir so manche Beiträge von durchaus "angesehenen" Webworkern im Netz anschaue, dann legt das die Vermutung nahe, dass es zumindest bei einigen Punkten definitiv nicht nur an mir liegt ...!
Gruß Gunther
@@Gunther:
nuqneH
[…] dann muss ich auf das Konzept der ausschließlichen Verwendung von <h1> Elementen zurückgreifen.
[…] Nach meinem Verständnis sollte doch gerade die Problematik der Überschriften Hierarchien (insbesondere bei dynamisch generierten Seiten) gelöst werden.
Hm, wird es doch. Allerdings ist der Elementbezeichner 'h1' dann unsinnig, denn das Element steht eben nicht für eine Überschrift der 1. Hierarchie-Ebene. Es hätte ein 'h'-Element eingeführt werden müssen, wie es XHTML 2 vorsah. NIH-Syndrom?
Es kann doch nicht Sinn der Sache sein, dass wenn ich schon einen Standard erweitere, bzw. teilweise völlig neu definiere, von vorneherein auf Bestandteile anderer Standards zurückzugreifen, anstatt diese direkt in den Standard zu implementieren.
Sinn oder nicht, HTML5 tut es. Siehe Ruby-Anotationen.
Und imho geht eben vielen der neuen Elemente eine entsprechende semantische Bedeutung ab, bzw. ist so "verschwommen", dass die Bedeutung gegen Null geht
Ja, siehe Elemente 'i' und 'b'. Zu beiden gibt es nur eine vage Erklärung, die nicht ohne „such as“ auskommt. Der urprünglich enthaltene Passus „whose typical typographic presentation is italicized“ bzw. „boldened“ war nicht tragbar und wurde entfernt. Damit haben die Elemente eine völlig neue Bedeutung als bisher (so sie denn überhaupt eine haben) – von Abwärtskompatibilität keine Spur.
HTML5 ist hier an seinem Anspruch, das Web neu erfinden zu wollen, aber abwärtskompatibel sein zu wollen, kläglich gescheitert.
Qapla'
Hallo,
HTML5 ist hier an seinem Anspruch, das Web neu erfinden zu wollen, aber abwärtskompatibel sein zu wollen, kläglich gescheitert.
Abwärtskompatibilität ist nicht einseitig und hat viele Facetten, die sich auch widersprechen können.
Die Definitionen von b und i sind nicht insofern abwärtskompatibel, dass sie sich mit der Bedeutung decken, die HTML 4 ihnen zuweist. Das ist bekannt, das ist Absicht. Insbesondere diesen Fall nun als »klägliches Scheitern« zu bezeichnen, ist ein wenig billig. Sämtliche Entscheidungen beim Korrigieren und Erweitern von Techniken sind bloß Kompromisse.
Das gilt nicht nur für HTML, sondern auch beispielsweise für Programmiersprachen und APIs. Gewisse Kompatibilitätsbrüche passieren und müssen passieren, auch wenn man eine Sprache sehr vorsichtig anpasst und erweitert. Was herauskommt, ist nicht unbedingt schön, sondern erst einmal pragmatisch. Es sei denn, man bricht ab und zu mit der Abwärtskompatibilität völlig. Bei XHTML ist das gescheitert, wer sagt, dass es z.B. bei ECMAScript Harmony hinhauen wird?
Die Neudefinition von b und i in HTML5 soll die tatsächlichen Use-Cases in den bestehenden Milliarden HTML-Dokumenten abdecken, in denen keine anderen Elemente passen und deshalb b und i mangels passenderer Elemente verwendet werden. Das ist auch ein Aspekt der Abwärtskompatibilität (siehe Link).
Bei i ist die Definition m.E. auch gelungen, da es viele Fälle gibt, in denen Textteile entsprechend abgehoben werden. Dass »whose typical typographic presentation is italicized« herausgeflogen ist, halte ich für richtig, schließlich beschreibt es nicht, warum diese Formatierung angewendet wird. Bei b ist es nicht so gut gelungen, weil es mir ziemlich selten scheint, dass eine solche Hervorhebung nicht mit Betonung/Wichtigkeit einhergeht. Den Leadsatz, ein Beispiel aus der Spezifikation, hätte ich mit strong ausgezeichnet oder einfach in einen header eingeschlossen.
Mathias
@@molily:
nuqneH
Bei i ist die Definition m.E. auch gelungen, da es viele Fälle gibt, in denen Textteile entsprechend abgehoben werden. Dass »whose typical typographic presentation is italicized« herausgeflogen ist, halte ich für richtig, schließlich beschreibt es nicht, warum diese Formatierung angewendet wird.
Schlimmer noch: Es beschreibt nicht, DASS diese Formatierung überhaupt angewendet wird. Werden im Deutschen Wendungungen aus anderen Sprachen kursiv gesetzt? Namen von Schiffen? Wohl eher nicht; und wenn, dann ist es erst in jüngerer Zeit aus dem Englischen rübergeschwappt.
Und das ist noch harmlos. In anderen Schriftsystemen werden ganz andere Formen der Hervorhebung verwendet als Kusiv- oder Fettschrift.
Der grundlegende Irrtum, den Hixie hier begangen hat, ist, dass er von der Verwendung im Englischen ausgegangen ist. Man kann keine Spezifikation fürs _Worldwide_ Web schreiben, indem man die englische Sprache als das Maß aller Dinge ansetzt.
Das ist dann wohl auch der Grund, warum „whose typical typographic presentation is …“ rausgeflogen ist; man kann ja in einer Spec fürs WWW schlecht schreiben „whose typical typographic presentation in English language is …“.
Nein, die Umdeutung von 'i' und 'b' ist gründlich misslungen. „Da ihre Namen jedoch 'b' wie bold (fett) und 'i' wie italic (kursiv) lauten, werden Autoren sie vermutlich auch weiterhin als schnellen darstellungsbezogenen Fix einsetzen.“ [qa-b-and-i-tags]
Man hätte die Elemente wohl ebenso wie 's' und 'u' aus dem Standard streichen sollen. Sie erfüllen kaum irgendeinen Zweck. Oder anders gesagt: Um einen Zweck zu erfüllen, müsste man ihnen eine Klasse verpassen, das Warum beschreibt. [ibid.] Dann kann man aber auch gleich 'span' verwenden.
Qapla'
Werden im Deutschen Wendungungen aus anderen Sprachen kursiv gesetzt? Namen von Schiffen? Wohl eher nicht;
Ich habe mir mal ein Buch aus dem Regal geschnappt:
»Schrift und Natur sind in der irischen Sprache eng verwandt: <i lang="ga">fid</i> bedeutet sowohl Wald als auch Buchstabe, <i lang="ga">rusc</i> die Rinde und <i lang="ga">rosc</i> das deklamatorische Gedicht. Religion und Natur gehören in den Kontext, der das keltische Erbe verrät: die alten keltischen Götter waren gesichts- und körperlos, sie wohnten in den Bäumen und den Steinen, wie auch eine alte, aber falsche Etymologie die Druiden mit <i lang="ga">doire</i>, dem Eichenhain, in Verbindung bringt. Was die Gedichte dieser Zeit verraten, von den Anachoreten bis zu den Scholasten in ihren Marginalien, ist ein tief empfundener Pantheismus.«
Raoul Schrott: Die Erfindung der Poesie. München 2003. S. 299
Ferner habe ich eine Einführung in die Literaturwissenschaft gefunden, welche sämtliche fremdsprachigen Fachbegriffe (hauptsächlich griechische und lateinische) kursiv setzt. Und eine Einführung in das Mittelhochdeutsche, welches sämtliche mittelhochdeutschen Wörter kursiv setzt. In Peter Handkes »Mein Jahr in der Niemandsbucht« sind französische Begriffe ebenfalls in kursiv gesetzt, ich habe beim schnellen Suchen drei Stellen entdeckt.
Bücher mit Schiffsnamen habe ich gerade nicht zur Hand.
und wenn, dann ist es erst in jüngerer Zeit aus dem Englischen rübergeschwappt.
<i>Ach so!</i> Dagegen müssen wir uns wehren!!1
Mathias
@@molily:
nuqneH
Ich habe mir mal ein Buch aus dem Regal geschnappt:
Hm, deine Beispiele sollten jetzt aber nicht mein ganzes Posting ad absurdum führen, oder? ;-)
Du hast dir den unwesentlichsten Teil rausgepickt (von mir als solcher markiert: „Und das ist noch harmlos.“). Bedeutender war der Hinweis auf Schriften (CJK, …), in denen gar nicht kursiv oder fett hervorgehoben wird.
Und es bleibt auch die Frage, ob in deinen Büchern die Begriffe kursiv gesetzt sind, weil sie fremdsprachig sind, oder ob es dafür andere Gründe gibt, bspw. weil genau diese Begriffe erklärt werden, also eher »Schrift und Natur sind in der irischen Sprache eng verwandt: <dfn lang="ga">fid</dfn> bedeutet sowohl Wald als auch Buchstabe, <dfn lang="ga">rusc</dfn> die Rinde und <dfn lang="ga">rosc</dfn> das deklamatorische Gedicht.« (Raoul Schrott: Die Erfindung der Poesie. München 2003. S. 299)
Nochmal zurück zu meinem ersten Satz, dieser hatte nämlich sogar einen Hintergrund: Würde man im Deutschen „ad absurdum“ kursiv setzen? Im Englischen würde man, AFAIK.
Bücher mit Schiffsnamen habe ich gerade nicht zur Hand.
Ich habe mir mal ein Buch aus dem Regal geschnappt. ;-) In den deutschen Übersetzungen der Star-Trek-Romane wird „Enterprise“ etc. kursiv gesetzt. Meine Frage ist, ob das im Deutschen üblich ist oder hier einfach mal so aus dem Original übernommen wurde.
Qapla'
Hallo,
Nochmal zurück zu meinem ersten Satz, dieser hatte nämlich sogar einen Hintergrund: Würde man im Deutschen „ad absurdum“ kursiv setzen? Im Englischen würde man, AFAIK.
würde man vielleicht - aber es hängt sehr davon ab, ob dem Schreiber diese Redewendung geläufig ist oder als fremdsprachlicher Einfluss bewusst ist - ebenso fremdsprachliche Wendungen wie "pro bono" oder "bona fide", die gelegentlich durch anderen Schriftsatz hervorgehoben werden, aber nicht immer und überall.
Bücher mit Schiffsnamen habe ich gerade nicht zur Hand.
Ich habe mir mal ein Buch aus dem Regal geschnappt. ;-) In den deutschen Übersetzungen der Star-Trek-Romane wird „Enterprise“ etc. kursiv gesetzt. Meine Frage ist, ob das im Deutschen üblich ist oder hier einfach mal so aus dem Original übernommen wurde.
Nur unspezifisch aus der Erinnerung, weil ich doch schon gelegentlich Romane mit maritimem Hintergrund gelesen habe: Ja, es gibt Autoren, die den Namen eines Schiffes kursiv setzen oder durch eine andere Schriftart hervorheben. Aber konsequent angewendet wird das nicht.
Ciao,
Martin
Hallo,
Bedeutender war der Hinweis auf Schriften (CJK, …), in denen gar nicht kursiv oder fett hervorgehoben wird.
Und das soll ein Argument gegen b und i sein?
Erstens haben b und i seit HTML5 nichts mehr direkt mit bold und italic zu tun. Man kann mit b und i auszeichnen, wenn man meint, die Bedeutung ließe dies zu, aber kann die Elemente so formatieren, wie es im jeweiligen Schriftsystem bei derartigen Hervorhebungen üblich ist.
Zweitens könnte man mit dem Argument »in manchen Schriften gibt es kein fett/kursiv« selbst gegen font-weight: bold und font-style: italic in CSS wettern. Es ist offensichtlich, dass manche Features nicht universell sind. In arabischer, hebräischer, lateinischer, griechischer, kyrillischer Schrift ergeben Ruby-Annotations i.d.R. wenig Sinn. Ist das jetzt ein Argument dagegen?
Nochmal zurück zu meinem ersten Satz, dieser hatte nämlich sogar einen Hintergrund: Würde man im Deutschen „ad absurdum“ kursiv setzen? Im Englischen würde man, AFAIK.
Dieser Begriff ist schon in die deutsche Sprache übergegangen, daher würde man es in dem Fall nicht. Im Englischen scheint mir das auch häufiger zu sein, selbst bei im Deutschen recht verbreiteten Wendungen wie etwa »per se«.
Mathias
@@molily:
nuqneH
Erstens haben b und i seit HTML5 nichts mehr direkt mit bold und italic zu tun.
Sie haben gar nichts mehr mit bold und italic zu tun, seitdem, „whose typical typographic presentation is …“ rausgeflogen ist.
Außer ihrer Formatierung per Browserstylesheet. Und das genau ist das Problem: Autoren werden sie weiterhin darstellungsbezogen einsetzen, nicht gemäß ihrer Bestimmung laut HTML5 (was auch immer die sein mag).
Die Bezeichner 'i' und 'b' sind nun einfach irgendwelche Buchstaben des lateinischen Alphabets, die rein gar nichts mit der Semantik der Elemente zu tun haben. Es wäre also sinnvoll gewesen, 'i' und 'b' ganz fallenzulassen und für die beabsichtigte Verwendung neue Elementbezeichner einzuführen. So schwammig, wie die Erklärung in der Spec ist, wage ich aber zu bezweifeln, dass solche Elemente überhaupt gebraucht werden.
In arabischer, hebräischer, lateinischer, griechischer, kyrillischer Schrift ergeben Ruby-Annotations i.d.R. wenig Sinn.
Für die Notation von Begleitakkorden ergeben Ruby-Annotationen auch in lateinischer Schrift viel Sinn:
F Bb F
The screen door slams, Mary's dress waves
C Bb
Like a vision she dances across the porch as the radio plays
C
Roy Orbison singing for the lonely
F Bb
Hey that's me and I want you only
F C
Don't turn me home again, I just can't face myself alone again
Nochmal zurück zu meinem ersten Satz, dieser hatte nämlich sogar einen Hintergrund: Würde man im Deutschen „ad absurdum“ kursiv setzen? Im Englischen würde man, AFAIK.
Dieser Begriff ist schon in die deutsche Sprache übergegangen, daher würde man es in dem Fall nicht. Im Englischen scheint mir das auch häufiger zu sein, selbst bei im Deutschen recht verbreiteten Wendungen wie etwa »per se«.
Ja, derartige Wendungen meinte ich.
Qapla'
Hi,
Werden im Deutschen Wendungungen aus anderen Sprachen kursiv gesetzt? Namen von Schiffen? Wohl eher nicht; und wenn, dann ist es erst in jüngerer Zeit aus dem Englischen rübergeschwappt.
Ist das was schlechtes?
Was wäre denn die Alternative – Anführungszeichen? Nein, wenn ich den Schiffsnamen im Text oft verwende, finde ich die optisch doch eher störend.
Und ganz ohne eine Kennzeichnung oder Abhebung möchte ich einen Schiffsnamen auch nicht schreiben. „Die Auto wurde 1965 in Hamburg gebaut“ läse sich reichlich bescheuert, wenn jemand mal auf die Idee kam, sein Schiff Auto zu taufen. Selbst wenn ich vorher einführend erwähnt habe, dass es sich bei diesem Auto um ein Schiff handelt, bleibt ein Nicht-Sprachlegastheniker an einem Satz wie diesem beim Lesen erst mal hängen, wenn keine Abhebung vom umgebenden Text gegeben ist.
MfG ChrisB
@@molily:
nuqneH
Den Leadsatz, ein Beispiel aus der Spezifikation, hätte ich mit strong ausgezeichnet oder einfach in einen header eingeschlossen.
Ich nicht.
Und hier sind wir beim Problem: Warum bietet HTML5 Autoren so viele Möglichkeiten, dasselbe auszudrücken? Warum gibt es kein eindeutiges Element für Leadsätze; schließlich ist das ein nicht allzu seltener Anwendungsfall.
HTML5 bietet nicht das, was Webautoren benötigen, sondern das, was Browserhersteller mal eben Lust haben zu implementieren. Und das ist ein (wenn nicht DAS) Grundübel von HTML5.
Man kann sich HTML5 schönreden wie man will, es wird dadurch nicht besser.
Qapla'
nuqneH
Und hier sind wir beim Problem: Warum bietet HTML5 Autoren so viele Möglichkeiten, dasselbe auszudrücken? Warum gibt es kein eindeutiges Element für Leadsätze; schließlich ist das ein nicht allzu seltener Anwendungsfall.
Meine Rede. Und die meistens sehr "schwammigen" Formulierungen in der Spec tragen auch nicht gerade zur Klärung bei ...
HTML5 bietet nicht das, was Webautoren benötigen, sondern das, was Browserhersteller mal eben Lust haben zu implementieren. Und das ist ein (wenn nicht DAS) Grundübel von HTML5.
ACK
Man kann sich HTML5 schönreden wie man will, es wird dadurch nicht besser.
Den Eindruck gewinne ich leider auch immer mehr ...! :-(
Gruß Gunther
Hallo,
Man kann sich HTML5 schönreden wie man will, es wird dadurch nicht besser.
Völlig richtig! Besser wird es dadurch, in unbedeutenden Foren in Beiträgen, die null Reichweite besitzen, zu jammern, wie schlimm alles ist. Es trägt zum Positiven bei, konkrete Fragen bloß suggestiv zu stellen, anstatt sie etwa durch eine Recherche im Archiv von public-html zu beantworten zu versuchen. Es führt zu besseren Webstandards, Kritik in selbige Lästerforen reinzuschreiben, anstatt sie beispielsweise an die HTML-WG zu adressieren. Sicherlich wird es sich zum Besseren wenden, wenn man ständig Behauptungen aufstellt, anstatt beispielsweise in Artikeln eine Argumentation zu entfalten und damit Einfluss auszuüben, wie viele andere es tun.
In diesem Sinne: Weitermachen!
Mathias
Hallo,
Damit hat man als Autor unterm Strich nichts gewonnen. Stattdessen muss man aber zukünftig verdammt darauf aufpassen, dass man die gewünschte Dokument Struktur (Outline) erhält.
Was ist das Problem dabei? Was ist daran so schwierig?
Ich sehe nicht, dass man »verdammt aufpassen« muss. Man muss jeden Abschnitt in eine Section hüllen, das ist alles. Ich habe damit schon einige Websites umgesetzt, auch dynamisch generierte, mehrfach verschachtelte Sections.
Du hast Abschnitte explizit als solche ausgezeichnet, als dass es nur implizit über die Überschriftenhierarchie getan wird.
OK. Und welchen Nutzen/Sinn hat das (für 90% aller Webseiten)?
Du kannst sie per CSS formatieren, du kannst sie per Script z.B. auf- und zuklappen, ein Inhaltsverzeichnis generieren und vieles mehr.
Ach, du meinst so wie beim Weblog?
Das kommt für mich dem Zwang zu
<body><h1></h1>...
gleich.
Auch wenn ich es präferiere, so muss auf oberster Ebene muss nicht unbedingt nur eine Section liegen, die alle anderen umschließt. Für beide Varianten gibt es Vor- und Nachteile und m.W. sind auch beide verbreitet. Ich sehe kein praktisches Problem darin, dass der body eine »Untitled Section« bildet. Beispielsweise Screenreader, welche einem ein Outline erzeugen und dem Nutzer präsentieren, werden sicherlich nicht »Unbenannter Abschnitt« o.ä. daraus machen. Ihnen steht es frei, unbenannte Abschnitte auf oberster Ebene nicht in diese Navigation aufzunehmen.
Das SELFHTML-Weblog ist so eingerichtet, dass die Struktur auf einer Einzelseite Sinn ergibt (wo es nur ein h1 gibt). Dass auf der Übersichtsseite dasselbe Markup verwendet wird und somit viele <h1> auf einer Ebene liegen, hat liegt mehr an Template-Beschränkungen.
Semantisches Markup ist trotzdem vorzuziehen.
Auch wenn ich dir im Kern durchaus zustimme, würde mich dennoch interessieren warum?
Weil ein sinnvoll strukturiertes Dokument viele Präsentationen haben kann anstatt nur eine. Weil User-Agents die Daten vielseitig auswerten können, was bei <font> nicht möglich ist.
Denn prinzipiell zählt ja wohl erstmal die syntaktische Korrektheit. Und die Semantik (für den User) ergibt sich bei visuellen Ausgabemedien durch die Präsentation (also letztlich durch die CSS Formatierung).
Nicht ausschließlich. Der Nutzer kann etwa durch die Überschriften springen, wenn sie sinnvoll ausgezeichnet sind. Es ist überhaupt möglich, eine Präsentation auf Dokumentenstruktur basieren zu lassen, beispielsweise durch User-Stylesheets.
Bisher war eine der obersten Grundregeln, dass ein Browser alles ignoriert, was er nicht kennt. Wenn man sich weiterhin an diesen Grundsatz hält (der sich imho sehr bewährt hat), dann erscheint mir es zumindest sinnvoller, eher neue Attribute anstelle von neuen Elementen zu verwenden. Denn wenn ein Attribut mangels Kenntnis ignoriert wird, dann geht lediglich ein Stück der Semantik des Markups "verloren"!
Bei Elementen ist dasselbe der Fall, wie Daniel auch schreibt. Lediglich ältere IEs parsen ohne Shim die Elemente nicht. Die Idee ist jedoch, dass unbekannte Elemente und Attribute ins DOM aufgenommen werden. HTML5 spezifiziert diese Aufwärtskompatibilität.
Und imho geht eben vielen der neuen Elemente eine entsprechende semantische Bedeutung ab, bzw. ist so "verschwommen", dass die Bedeutung gegen Null geht - bspw. beim <aside> Element. Aber auch <header> und <footer> sind nicht viel eindeutiger. Hier wäre man eben m.E.n. mit einem, bzw. mehreren neuen Attributen und einer entsprechenden Vielzahl möglicher Werte wesentlich besser bedient gewesen.
Selbst angenommen, die Bedeutung wäre schlecht definiert – eine Meinung, die ich nicht teile –, so sehe ich nicht, welchen Vorteil es gehabt hätte, an ihrer statt Attribute zu definieren.
Mathias
Hallo Mathias und alle anderen,
wenn du ja so überzeugt bist von der sinnvollen praktischen Anwendung der neuen HTML 5 Elemente, dann kannst du mir ja bestimmt eine Frage beantworten. ;-)
Als Beispiel sei eine typische Artikelseite angenommen, wie sie bspw. Wordpress erzeugt.
Auf unserer Seite sei der Aufbau wie folgt:
┌-----------------------------------------------------┐
| masthead |
| |
| |
├-----------------------------------------------------┤
| main navigation |
| |
| |
├----------------------------------┬------------------┤
| | |
| | |
| content | sidebar |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
├----------------------------------┴------------------┤
| |
| (page) footer |
| |
└-----------------------------------------------------┘
Der Kopfbereich beinhaltet u.a. das Logo, einen Slogan und Links zu den Seiten 'Impressum' und 'Kontakt'.
Darunter folgt die Hauptnavigation der Seite (main navigation).
Der 'Content' Bereich soll wie gesagt *einen* Artikel mit TOC beinhalten, plus einige Links zu verwandten Artikeln darunter.
Danach folgen noch einige Kommentare zum Artikel und im Anschluss das Formular um einen Kommentar zu verfassen.
Die 'Sidebar' soll u.a. (die/das)? Blogroll beinhalten, sowie einen Block mit einer Auflistung der Blog-Kategorien und einen Archiv-Block.
Der 'Footer' möge ebenfalls nochmals 3 Blöcke mit diversen Links (intern + extern) umfassen.
Alles in allem also eine "ganz normale" Blogseite, wie man sie millionenfach im Netz findet.
Frage: Wie sähe jetzt ein semantisch korrekter Aufbau der Seite in HTML 5 aus?
Dank & Gruß
Gunther
Hallo,
Der Kopfbereich beinhaltet u.a. das Logo, einen Slogan und Links zu den Seiten 'Impressum' und 'Kontakt'.
<header>
<h1>Unsere tolle Site</h1>
<p>Unser toller Slogan</p>
<ul>
<li><a>Kontakt</a></li>
<li><a>Impressum</a></li>
</ul>
</head>
Darunter folgt die Hauptnavigation der Seite (main navigation).
<nav>
<h1>Hauptnavigation</h1>
<ul>…</ul>
</nav>
Der 'Content' Bereich soll wie gesagt *einen* Artikel mit TOC beinhalten, plus einige Links zu verwandten Artikeln darunter.
<article>
<header>
<h1>Der Artikel</h1>
<ul><!-- Inhaltsverzeichnis --></ul>
</header>
<p>Artikeltext (evtl. mit weiteren sections)</p>
<section>
<h2>Links</h2>
<ul>…</ul>
</section>
Danach folgen noch einige Kommentare zum Artikel und im Anschluss das Formular um einen Kommentar zu verfassen.
<section>
<h2>Kommentare</h2>
<ol>…</ol>
</section>
<section>
<h2>Kommentar verfassen</h2>
<form>…</form>
</section>
</article>
Die 'Sidebar' soll u.a. (die/das)? Blogroll beinhalten, sowie einen Block mit einer Auflistung der Blog-Kategorien und einen Archiv-Block.
<aside>
<h1>Seitenleiste mit Blogroll und Archiv</h1>
<section>
<h2>Blogroll</h2>
<ul>…</ul>
</section>
<section>
<h2>Kategorien</h2>
<ul>…</ul>
</section>
<section>
<h2>Archiv</h2>
<ul>…</ul>
</section>
</aside>
Der 'Footer' möge ebenfalls nochmals 3 Blöcke mit diversen Links (intern + extern) umfassen.
<footer>
<section>
<h1>Sinnvolle Überschrift</h1>
<ul>…</ul>
</section>
…
</footer>
Viele der section-Elemente muss man nicht setzen, da HTML5 implizite Sections bei der Verwendung von hX-Elementen erzeugt. Ich halte es dennoch für sauberer, und beim Styling kann man diese gruppierenden Elemente ebenfalls gebrauchen.
Gewisse Überschriften müssen zudem nicht immer sichtbar sein, aber für Tastaturnavigation und Sprunglinks tragen sie zur Zugänglichkeit der Seite bei.
Mathias
Hallo Mathias,
recht herzlichen Dank für deine Antwort und die damit verbundene Mühe. :-)
Ich hatte absichtlich meine Ideen/ Vorstellungen erstmal nicht gepostet, um ein möglichst "unverfälschtes" Resultat zu erhalten. Daher jetzt meine Fragen, bzw. Ideen dazu:
Der Kopfbereich beinhaltet u.a. das Logo, einen Slogan und Links zu den Seiten 'Impressum' und 'Kontakt'.
<header>
<h1>Unsere tolle Site</h1>
<p>Unser toller Slogan</p>
<ul>
<li><a>Kontakt</a></li>
<li><a>Impressum</a></li>
</ul>
</head>
OK, soweit.
Man hätte evt. auch Überschrift und Slogan als
~~~html
<hgroup>
<h1>Unsere tolle Site</h1>
<h2>Unser toller Slogan</h2>
</hgroup>
auszeichnen können?
Darunter folgt die Hauptnavigation der Seite (main navigation).
<nav>
<h1>Hauptnavigation</h1>
<ul>…</ul>
</nav>
>
> > Der 'Content' Bereich soll wie gesagt \*einen\* Artikel mit TOC beinhalten, plus einige Links zu verwandten Artikeln darunter.
>
> ~~~html
<article>
>
> <header>
> <h1>Der Artikel</h1>
> <ul><!-- Inhaltsverzeichnis --></ul>
> </header>
>
> <p>Artikeltext (evtl. mit weiteren sections)</p>
>
> <section>
> <h2>Links</h2>
> <ul>…</ul>
> </section>
Hmmm ..., hier hätte ich etwas anderes erwartet.
Denn nach http://dev.w3.org/html5/spec/Overview.html#the-nav-element ist imho das TOC doch genau der zweite Anwendungsfall für das <nav> Element neben der Hauptnavigation, während eben bspw. die Links im Head und im Footer eben nicht in <nav> eingeschlossen werden (müssen).
Danach folgen noch einige Kommentare zum Artikel und im Anschluss das Formular um einen Kommentar zu verfassen.
<section>
<h2>Kommentare</h2>
<ol>…</ol>
</section><section>
<h2>Kommentar verfassen</h2>
<form>…</form>
</section></article>
Auch hier bin ich erstaunt, dass du wieder nur das (semantisch (fast) nichts sagende) <section> Element verwendet hast.
Ich hätte eher ein <aside> für die Kommentare erwartet.
Und ich habe auch schon des öfteren gesehen, dass Autoren jeden Kommentar als eigenständigen <article>, teils mit <header> und <footer>, ausgezeichnet haben.
Gerade bei Kommentaren zu einem Artikel finde ich es besonders schwierig, eine semantisch korrekte Auszeichnung zu finden. Denn ohne den zugehörigen Artikel machen alle Kommentare wenig Sinn. Insofern gehören sie eigentlich fest zum jeweiligen Artikel. Während dieser aber wiederum auch sehr gut ohne die Kommentare auskommt. Bei den Kommentaren wiederum kommt es stark auf den Inhalt an. Bezieht sich dieser ausschließlich auf den Artikel, ist der Kommentar quasi "eigenständig". Nimmt er aber (auch) Bezug auf einen oder mehrere andere(n) Kommentar(e), bilden diese eigentlich eine zusammengehörende Gruppe. Da man letzteres nie ausschließen kann, müssen für mich also alle Kommentare eine Gruppe bilden, die fest mit dem Artikel verbunden/ zusammengehörig ist.
> > Die 'Sidebar' soll u.a. (die/das)? Blogroll beinhalten, sowie einen Block mit einer Auflistung der Blog-Kategorien und einen Archiv-Block.
>
> ~~~html
<aside>
> <h1>Seitenleiste mit Blogroll und Archiv</h1>
>
> <section>
> <h2>Blogroll</h2>
> <ul>…</ul>
> </section>
>
> <section>
> <h2>Kategorien</h2>
> <ul>…</ul>
> </section>
>
> <section>
> <h2>Archiv</h2>
> <ul>…</ul>
> </section>
>
> </aside>
Wiederum hätte ich etwas leicht anderes erwartet. ;-)
Irgendwo (kann es gerade nicht wiederfinden) habe ich mal gelesen (sinngemäß):
"aside != sidebar".
Von daher erschiene es mir richtiger, die Sidebar erst per <div id="sidebar"> zu setzen und innerhalb dessen für jeden Block ein <aside> anstelle von <section> zu verwenden.
Der 'Footer' möge ebenfalls nochmals 3 Blöcke mit diversen Links (intern + extern) umfassen.
<footer>
<section>
<h1>Sinnvolle Überschrift</h1>
<ul>…</ul>
</section>…
</footer>
>
> Viele der section-Elemente muss man nicht setzen, da HTML5 implizite Sections bei der Verwendung von hX-Elementen erzeugt. Ich halte es dennoch für sauberer, und beim Styling kann man diese gruppierenden Elemente ebenfalls gebrauchen.
Prinzipiell stimme ich dir zu, aber mir scheint, dass du das <section> Element zumindest häufig falsch, bzw. missbräuchlich verwendest - vgl. <http://html5doctor.com/the-section-element/>
Also wäre imho im vorliegenden Fall bspw. ein <aside> für den Block "mit diversen Links (intern + extern)" semantisch richtiger, als ein <section>
> Gewisse Überschriften müssen zudem nicht immer sichtbar sein, aber für Tastaturnavigation
Das verstehe ich gerade nicht so ganz? Nicht sichtbar, aber helfen bei der Tastaturnavigation!?
Da finde ich die neue Option, dass <a>'s jetzt auch ganze Blöcke umschließen können schon hilfreicher.
> und Sprunglinks tragen sie zur Zugänglichkeit der Seite bei.
Also mich bestärkt alleine dieses kleine und sehr gängige Beispiel in meinem Eindruck, dass es wesentlich schwieriger ist mit HTML5 semantisch korrektes Markup zu schreiben, als mit HTML 4.
Denn ich bin mir ziemlich sicher, dass unsere beiden Entwürfe mit HTML 4 wesentlich ähnlicher gewesen wären. Und wenn noch 5 Leute einen HTML 5 Entwurf erstellen, werden vermutlich noch mind. 2 andere Varianten dabei sein ...!
Und dann habe ich noch eine ganz andere Frage: Ich habe die letzten Jahre eigentlich immer XHTML 1.0 strict verwendet. Nun erlaubt HTML5 ja einige Dinge (<a> für Blöcke, <noscript> im <head> u.a.), die bisher bei HTML 4 nicht erlaubt waren. Allerdings sind diese dann ja nicht XHTML konform. Andererseits stellt sich ja die Frage, ob (m)ein HTML5 Dokument denn auch unbedingt XHTML konform sein muss. Für die meisten User wahrscheinlich eher nicht (unbedingt). Oder sehe ich da etwas nicht/falsch?
Gruß Gunther
Hallo!
<header>
<h1>Unsere tolle Site</h1>
<p>Unser toller Slogan</p>
<ul>
<li><a>Kontakt</a></li>
<li><a>Impressum</a></li>
</ul>
</head>
> OK, soweit.
> Man hätte evt. auch Überschrift und Slogan als
> ~~~html
> <hgroup>
> <h1>Unsere tolle Site</h1>
> <h2>Unser toller Slogan</h2>
> </hgroup>
>
auszeichnen können?
Habe ich auch so verstanden. Meine Güte. Hätte man da nicht lieber ein <subtitle>-Element oder sowas einführen können?
Und vor allem das <h>-Element aus XHTML 2, anstatt <h1> mehrdeutig zu machen, mit einer dann völlig blödsinnigen 1 im Namen?
Irgendwo (kann es gerade nicht wiederfinden) habe ich mal gelesen (sinngemäß):
"aside != sidebar".
Von daher erschiene es mir richtiger, die Sidebar erst per <div id="sidebar"> zu setzen und innerhalb dessen für jeden Block ein <aside> anstelle von <section> zu verwenden.
Hmm, "aside" heißt ja sinngemäß sowas wie "nebenbei bemerkt", "ach übrigens", also Text, der nicht ganz so wichtig ist wie der Haupttext und/oder eher am Rande mit dem Thema zu tun hat. "sidebar" assoziiere ich eher damit, dass der Block an der Seite angezeigt wird (rechts oder links) und tendenziell eher hoch als breit ist. So gesehen wäre "sidebar" ein darstellungsbezogener Klassenname (oder ID), den man besser gar nicht verwenden sollte.
Also mich bestärkt alleine dieses kleine und sehr gängige Beispiel in meinem Eindruck, dass es wesentlich schwieriger ist mit HTML5 semantisch korrektes Markup zu schreiben, als mit HTML 4.
Denn ich bin mir ziemlich sicher, dass unsere beiden Entwürfe mit HTML 4 wesentlich ähnlicher gewesen wären. Und wenn noch 5 Leute einen HTML 5 Entwurf erstellen, werden vermutlich noch mind. 2 andere Varianten dabei sein ...!
Ich hoffe derzeit noch, dass das nur an mangelnder Gewöhnung liegt. Der HTML-4-Kram wurde ja schließlich schon seit Jahren durchdiskutiert, so dass sich in vielen Dingen eine Art "common sense" herausgebildet hat. Manche Sachen führen da aber auch immer noch zu Uneinigkeit (z.B. wann <dl> und wann zweispaltige Tabelle? <dl> nur für Glossare vs. <dl> als allgemeine Liste von Key-Value-Paaren und ähnliche Fragen).
Auf der anderen Seite sehe ich auch einiges an Gefrickel in HTML5, insbesondere wenn man interessante Ideen aus XHTML 2 aufgreift, aber sie (anscheinend aus Prinzip?) anders umsetzen will.
href als Universalattribut? => Nein, aber alles darf mit <a> umschlossen werden. (Tabellenzeilen und -zellen eigentlich auch?)
Überschriften als <h>, Hierarchie wird durch Container abgebildet? => Im Prinzip ja, aber mit <h1> statt <h>.
Usw.
Und dann habe ich noch eine ganz andere Frage: Ich habe die letzten Jahre eigentlich immer XHTML 1.0 strict verwendet. Nun erlaubt HTML5 ja einige Dinge (<a> für Blöcke, <noscript> im <head> u.a.), die bisher bei HTML 4 nicht erlaubt waren. Allerdings sind diese dann ja nicht XHTML konform. Andererseits stellt sich ja die Frage, ob (m)ein HTML5 Dokument denn auch unbedingt XHTML konform sein muss. Für die meisten User wahrscheinlich eher nicht (unbedingt). Oder sehe ich da etwas nicht/falsch?
Du kannst einfach HTML5 in XHTML-Syntax schreiben, IMHO ist das auch sinnvoll. Wenn Du ein verarbeitendes Programm erstellst, z.B. einen Bot, kannst Du durchaus einen XML-/XHTML-Parser verwenden. Und fremde Bots sollten grundsätzlich eine gewisse Fehlertoleranz haben, wenn sie aufs Web losgelassen werden - schließlich sind sehr, sehr viele Seiten gar nicht valide, egal nach welcher (X)HTML-Version.
Viele Grüße,
Alexander
Man hätte evt. auch Überschrift und Slogan als
<hgroup>
<h1>Unsere tolle Site</h1>
<h2>Unser toller Slogan</h2>
</hgroup>
> auszeichnen können?
Ja, das wäre eine mögliche Alternative.
> Denn nach <http://dev.w3.org/html5/spec/Overview.html#the-nav-element> ist imho das TOC doch genau der zweite Anwendungsfall für das <nav> Element neben der Hauptnavigation, während eben bspw. die Links im Head und im Footer eben nicht in <nav> eingeschlossen werden (müssen).
Stimmt, das wäre wohl die bessere Variante.
> Ich hätte eher ein <aside> für die Kommentare erwartet.
Passt durchaus auch, ja.
> Und ich habe auch schon des öfteren gesehen, dass Autoren jeden Kommentar als eigenständigen <article>, teils mit <header> und <footer>, ausgezeichnet haben.
Von der Struktur her ist das sicher gerechtfertigt, für mich wäre das im Kontext von Blogs Sectioning-Overkill.
> Irgendwo (kann es gerade nicht wiederfinden) habe ich mal gelesen (sinngemäß):
> "aside != sidebar".
Es gab mal einen HTML5Doctor-Artikel, der aber [revidiert wurde](http://html5doctor.com/aside-revisited/).
Die aktuelle Spezifikation erlaubt es durchaus, dass eine Blog-Sidebar mit aside ausgezeichnet wird (auf Ebene der body-Section).
Ein [Beispiel in der Spec](http://dev.w3.org/html5/spec/sections.html#the-aside-element) zeigt den Code eines Blogs und nutzt aside + mehrere navs für die klassische Sidebar.
> Also wäre imho im vorliegenden Fall bspw. ein <aside> für den Block "mit diversen Links (intern + extern)" semantisch richtiger, als ein <section>
Du meinst im Footer?
Wenn diese Linklisten aside sein sollen, was ist der Hauptinhalt des Footers?
Ein Footer als Liste von asides? Das ergibt keinen Sinn. footer auf oberster Ebene sagt ja bereits, dass es sich um Zusatz- oder Meta-Inhalt handelt. Das jeweils nochmal in asides zu verpacken, halte ich für doppelt gemoppelt.
> > Nicht sichtbar, aber helfen bei der Tastaturnavigation!?
Ja. Erstens kann man Überschriften »zugänglich« verstecken, sodass sie beispielsweise in Screenreadern existent sind und durch entsprechende Tastatur-Shortcuts (z.B. auch im Opera) angesprungen werden können. Zweitens gibt es Techniken, bei denen z.B. eigentlich versteckte Sprunglinks beim Fokussieren eingeblendet werden.
> Also mich bestärkt alleine dieses kleine und sehr gängige Beispiel in meinem Eindruck, dass es wesentlich schwieriger ist mit HTML5 semantisch korrektes Markup zu schreiben, als mit HTML 4.
Mehr Möglichkeiten heißt auch mehr Lösungsvarianten.
> Denn ich bin mir ziemlich sicher, dass unsere beiden Entwürfe mit HTML 4 wesentlich ähnlicher gewesen wären.
Das denke ich nicht. Jeder hätte seine ganz eigene div-Suppe gekocht und wir hätten uns trefflich über sinnvolle Gruppierung und sinnvolle Benennung der IDs und Klassen streiten können.
> Und wenn noch 5 Leute einen HTML 5 Entwurf erstellen, werden vermutlich noch mind. 2 andere Varianten dabei sein ...!
Wo ist das Problem? Es gibt nicht die eine korrekte Auszeichnung und alle anderen sind falsch oder suboptimal. Man kann unterschiedliche Schwerpunkte setzen.
> Und dann habe ich noch eine ganz andere Frage: Ich habe die letzten Jahre eigentlich immer XHTML 1.0 strict verwendet. Nun erlaubt HTML5 ja einige Dinge (<a> für Blöcke, <noscript> im <head> u.a.), die bisher bei HTML 4 nicht erlaubt waren. Allerdings sind diese dann ja nicht XHTML konform.
a für Blöcke sollte XHTML5-konform sein. Habe ich gerade mit dem [Validator](http://validator.nu/) geprüft (als Preset XHTML5 einstellen).
noscript wird in XHTML5 – welches sich immer als application/xhtml+xml definiert – an sämtlichen Stellen nicht unterstützt, weil es eine Parseranweisung ist, welche von einem XML-Parser nicht unterstützt werden kann. Das ist aber nichts neues, das galt auch für XHTML 1.x als application/xhtml+xml.
Mathias
Auch hier bin ich erstaunt, dass du wieder nur das (semantisch (fast) nichts sagende) <section> Element verwendet hast.
Ich hätte eher ein <aside> für die Kommentare erwartet.
Und ich habe auch schon des öfteren gesehen, dass Autoren jeden Kommentar als eigenständigen <article>, teils mit <header> und <footer>, ausgezeichnet haben.
<article>s in <article> halte ich auch am vernünftigsten. Geht übrigens auf ein Beispiel in der Spec zurück.
Gerade bei Kommentaren zu einem Artikel finde ich es besonders schwierig, eine semantisch korrekte Auszeichnung zu finden. Denn ohne den zugehörigen Artikel machen alle Kommentare wenig Sinn.
Die Faustregel zur Anwendung von <article> im Gegensatz zum leicht allgemeineren <section> ist, dass der Inhalt auch eigenständig veröffentlicht werden könnte. Kann man das bei Kommentaren sagen? Jein. Sie beziehen sich auf einen Artikel. Andererseits ... jedes Subposting in einem Thread hier wird auf einer eigenen Ressource veröffentlicht (zumindest in der Defaultansicht). Kommentare können auch als eigenständiger atom:entry in einem Feed stehen. Abwägungssache halt.
Wenn ich Dich mal kritisieren darfst: Du suchst ein bisschen so etwas wie Eindeutigkeit für Deine Anwendungsfälle in HTML5. Nur ist die Welt groß und kompliziert und jede Sekunde wird was Neues gemacht. Ein Standard kann vieles nicht abdecken. Die Strategie von Hixie für HTML ist es, bekanntere Anwendungsfälle zu untersuchen und wenn sie überzeugend* genug sind, diese dann zu standardisieren. Man kann aber nie so verallgemeinern, dass alles abgedeckt ist, besonders bei einem Sprachformat wie HTML, das ja ein Mischmasch aus Dokumentenbescheibungssprache und Anwendungsbeschreibungssprache ist. HTML(5) bietet einfach nur (einen Haufen) mehr. Vielleicht hier nicht genug im Details (<comment> wurde natürlich in der langen Geschichte mehrmals vorgeschlagen), ansonsten nicht allgemein genug. Ein perfektes HTML zu schaffen, besonders unter den leicht härteren Rahmenbedingungen wie Abwärtskompabilität und der Spezifizierung von Entwurfsmustern, die sich die WHATWG selber setzt, ist unmöglich.
Wie in HTML4-Zeiten heisst das dann für den Autor einfach, querzulesen, um sich einen Überblick zu schaffen und dann das nächstbeste Element für seinen Anwendungsfall zu nehmen. Im Notfall kann man noch mit ARIA-Rollen viel dazu definieren. Aber auch die leiden unter dem gleichen Problem wie der HTML-Elemente-Vorrat. Ok, man kann sich im Prinzip für das role-Attribut eigene Rollen definieren. Aber dann ist die Interoperabilität dahin. Die Welt ist einfach stark und groß inperfekt. Man lebt leichter, wenn man das schulterzuckend einfach akzeptiert und weiter atmet.
Hallo Gunther,
Auch erscheint mir der gewählte Weg, nämlich der der neuen Elemente, wenig sinnvoll. Denn erstens reichen diese paar neuen Elemente garantiert nicht aus und zweitens sind Veränderungen/ Erweiterungen schwierig, da diese immer von der jeweiligen Unterstützung durch die Browser abhängig sind.
HTML5 definiert seinen eigenen Parser, der das parsen von neuen Elementen vorwärtskompatibel ermöglicht. Erste Vereinheitlichugen fanden schon vor Jahren statt z.B. im Firefox 3. Inzwischen besitzen Chrome, Safari und Firefox einen vollständig HTML5 fähigen Parser, im IE10 wird ebenfalls einer enthalten sein und bei Opera gibts ebenfalls schon relativ stabile Builds mit HTML5-Parser.
HTML5 hat in einigen Bereichen stark für eine Vereinheitlichung der Browser gesorgt, was dazu führt, dass es in Zukunft weniger Probleme auf Grund unterschiedlicher Interpretation geben sollte.
Dass early adopters vielleicht ein display: block; zusätzlich notieren müssen, sollte dabei kein Hindernis darstellen.
Und mit den anderen neuen Elementen verhält es sich imho genauso. Ebenfalls bestens als "ungünstig" ist auch die Namensgebung zu erachten. So ist es doch schon ein quasi Standard, dass sehr viele Autoren ihre Seiten mittels DIV Container in <div id="header">, <div id="nav">, <div id="content"> und <div id="footer"> unterteilen (nicht zuletzt auch durch die weit verbreiteten Skripte wie Wordpress & Co.). Sehr clever, genau diese Bezeichnungen zu wählen und den Elementen dabei aber eine teils völlig andere Bedeutung zukommen zu lassen. So sieht man bspw. schon sehr häufig auf Seiten, die HTML5 verwenden, den Einsatz von <header> anstelle von <div id="header"> (gleiches gilt für das <footer> Element). Tatsächlich ist das <header> Element mehr zur Kennzeichnung von Überschriften/ Titeln einzelner semantischer Blöcke gedacht (vgl. http://www.w3.org/TR/html5/sections.html#the-article-element). Mir stellt sich in dem Zusammenhang erneut die Frage nach dem Sinn & Nutzen, außer dass der Quelltext zusätzlich aufgebläht wird?
Die Namen wurden tatsächlich deshalb gewählt, weil es sich um die meistvergebenen Klassennamen handelt (laut einer Google-Statistik).
Damit wird versucht, den Bedürfnissen vieler Autoren gerecht zu werden. Eine Nachrichtenwesbeite besteht eben aus mehreren Artikeln, die aus jeweils Kopf-, Inhalts- und Fußbereich bestehen. Das macht durchaus Sinn. Dennoch ist HTML5 flexibel genug, auch einfache Strukturen abbilden zu können.
Das bringt mich zu der alles entscheidenden Frage: "Warum ich sollte ich HTML5 (jetzt|zukünftig|jemals) verwenden?"
Dir bleibt gar nichts anderes übrig. HTML5 umfasst alle HTML-Dokumente, die es gibt und die in Zukunft geschrieben werden (bis HTML6 herauskommt, welches dann diese Rolle einnimmt).
Wie ist eure Meinung/ Sicht der Dinge?
Ich persönlich finde HTML5 gut. Das Web hat sich durch HTML5 in den letzten jahren positiv verändert. Nicht alles ist perfekt gelöst oder hat tatsächlich so funktioniert, wie man es sich vorgestellt hat, das wird sicher niemand behaupten.
Aber die ganze Vereinheitlichung die stattgefunden hat und nach wie vor stattfindet bewerte ich sehr positiv. HTML5 hat es mit seinem Parser geschafft, dass ein Dokument im IE und anderen Browsern die selbe DOM-Repräsentierung erzeugt. HTML5 wurde auch stark an XHTML angepasst, zum Beispiel durch das erlauben bestimmter Attribute oder Schreibweisen oder auch die Namensraumzugehörigkeit. Neue DOM-Methoden wurden hinzugefügt und bestehende genauer spezifiziert, sofern die bisher nicht der Fall war. Manche Dinge wurden ursprünglich überhaupt erst durch HTML5 spezifiziert, obwohl es sie schon fast seit Anbegin des WWW gibt (das Window-Objekt beispielsweise).
Allgemein finde ich, dass die bemühungen um HTML5 dazu geführt haben, dass sich in Sachen Webstandards wieder einiges tut. Heute ist kein Vergleich zu vor 10 Jahren. Nichtmal zu vor 5 Jahren.
Nebenbei: HTML5 ist noch nicht fertiggestellt. Du hast immernoch die Möglichkeit selbst tätig zu werden und Verbesserungsvorschläge einzubringen. Dazu kannst du dich an das W3C oder an die WHATWG wenden.
Gruß.
Hallo Gunther
Mal abgesehen davon, dass dieser derzeit noch von keinem HTML verarbeitenden Programm unterstützt wird...
Microsoft hat den Algorithmus zu demonstrationszwecken in JavaScript implementiert, vielleicht nutzt dir das beim Verständnis: Semantic Notepad.
Gruß, Daniel
Hallo Daniel,
vielen Dank für den Link (kannte ich schon).
Mal abgesehen davon, dass dieser derzeit noch von keinem HTML verarbeitenden Programm unterstützt wird...
Microsoft hat den Algorithmus zu demonstrationszwecken in JavaScript implementiert, vielleicht nutzt dir das beim Verständnis: Semantic Notepad.
Ich habe auch kein (grundsätzliches) Verständnisproblem mit der Outline. Ich finde lediglich, dass es erstens wesentlich schwieriger ist, die gewünschte (korrekte) Outline zu erhalten, und zweitens dafür u.U. das Markup (unnötig) aufgebläht wird.
Zusätzlich sehe ich noch das spezielle Problem bei den Überschriften und deren korrektem Styling per CSS.
Wenn man sich mal den Quellcode von diesem Beispiel anguckt, dann ist das imho schon ein gutes Beispiel dafür, wie man es eben genau nicht machen sollte.
Und wo früher von "Divitis" die Rede war, reden wir dann zukünftig von "Sectionitis", nur mit dem feinen Unterschied, dass DIVs keine automatische Auswirkung auf die Outline des Dokuments haben ...!
Gruß Gunther
Grüße dich, Gunther,
Ich habe auch kein (grundsätzliches) Verständnisproblem mit der Outline. Ich finde lediglich, dass es erstens wesentlich schwieriger ist, die gewünschte (korrekte) Outline zu erhalten, und zweitens dafür u.U. das Markup (unnötig) aufgebläht wird.
Das glaube ich nicht. Wenn man nicht absichtlich nav für Überschriften oder header für Zitate verwendet dürfte es sogar relativ schwierig sein, eine falsche Outline zu erhalten.
Vielleicht ist das Prinzip einfach nur ungewohnt.
Zusätzlich sehe ich noch das spezielle Problem bei den Überschriften und deren korrektem Styling per CSS.
Davon ist nur die Standardarstellung betroffen. Wenn stimmen würde, was du vermutest, dann hätte es in den letzte Jahren unzählige Berichte darüber gegeben, wie schwierig doch das Styling von h-Elementen sei. Denn diese werden auch erst seit kurzem wirklich effektiv eingesetzt.
Wenn man sich mal den Quellcode von diesem Beispiel anguckt, dann ist das imho schon ein gutes Beispiel dafür, wie man es eben genau nicht machen sollte.
Nun gut, dass Microsoft nicht immer ein gutes Beispiel darstellt dürfte bekannt sein :) In manchen Beispielen steht auch explizit dabei, dass es sich nicht um best practice handelt. Inzwischen hat MS angekündigt diese Vorgehen zu ändern. Das hat aber jetzt nicht unbedingt Bezug zum Thema.
Und wo früher von "Divitis" die Rede war, reden wir dann zukünftig von "Sectionitis", nur mit dem feinen Unterschied, dass DIVs keine automatische Auswirkung auf die Outline des Dokuments haben ...!
Nicht explizit, das stimmt. Die Definition des div-Elements ist dabei (in der "flexiblen" Art und Weise, in der ältere HTML Versionen nun mal geschrieben sind) aber der der neuen Element garnichtmal so unähnlich.
Gruß, Daniel