nicht angemeldet molily
molily
Matthias Apsel
Matthias Apsel
molily
molily
molily
Hallo erstmal; wie fange ich denn am besten an?
Also ich habe mich eine ganze Weile nicht mit aktuellen HTML-Entwicklungen befasst. Die letzten Jahre hatte ich recht wenig mit Webseiten zu tun und wenn, dann war ich eigentlich immer mit HTML4 in der strict-Variante zufrieden.
Dennoch habe ich mich die letzten Tage mal ein wenig in HTML5 eingelesen; man kann ja nicht immer auf altem Stand verweilen. Grundsätzlich war ich ja erstmal begeistert, als ich gelesen habe, dass es das Ziel sein sollte dem Web mehr Semantik zurück zu geben. Ich war eigentlich schon immer ein Freund der Idee des semantischen Markups. Wichtig ist nunmal der Inhalt, und nicht, wie dieser nun genau präsentiert wird.
Dennoch habe ich nach allem, was ich bisher über HTML5 so gelesen habe irgendwie den Eindruck, dass man die Umsetzung nicht richtig durchdacht hat. Genaugenommen erscheint mir alles viel zu „schwammig“, so als habe man einfach ein paar Tags erstellt und dann der Welt hingeworfen mit den Worten „hier, guckt mal ob ihr es /irgendwie/ gebrauchen könnt”, anstatt von vorneherein klare Definitionen zu treffen.
Das Sektionen aus Artikel und Artikel wiederum aus Sektionen bestehen können, sowie dass jeder Artikel/Sektion wieder eigene Header und Footer enthalten kann, ist ja nicht unsinnig, wenn man eine Weile darüber nachdenkt. Aber dadurch, dass irgendwie alles optional ist, wirkt es so nichtssagend.
Auch, dass durch diese Auszeichnungen jetzt endlich die Überschriften besser mit den Passagen gruppiert werden können, auf die sie sich eigentlich beziehen, ist eine Sache, die ich mir schon seit gefühlten Ewigkeiten wünsche. Aber die Umsetzung ist irgendwie auch nicht so toll finde ich.
Warum hat man denn zum Beispiel eine Konstruktion wie folgende erdacht:
<section>
<h1>Überschrift der Sektion</h1>
<p>…Text…</p>
<p>… und so weiter</p> …
</section>
Anstatt das man einfach festgelegt hätte, dass das Universalattribut title für section und article eben verflichtend wäre und von den Browsern eben entsprechend einer Überschrift angezeigt wird:
<section title="Überschrift der Sektion">
<p>…Text…</p>
<p>… und so weiter</p> …
</section>
Das wäre m.E. deutlich logischer gewesen, da der Titel (=die Überschrift) ja eigentlich ein Meta-Datum ist, welches sich auf die Sektion/ den Artikel als ganzes bezieht.
Aber das ist nur eine Kleinigkeit, bei der ich den Eindruck habe, man hätte sich bei der Semantik nicht genug Gedanken gemacht. So soll – wenn ich es richtig verstanden habe – das nav-Element für alle signifikanten Bestandteile verwendet werden, deren Hauptzweck es ist auf andere Seiten zu verzweigen. Das hieße ja praktisch, dass ein Inhaltsverzeichniss einer Webseite (also im Prinzip auch die Hauptseite der meisten Präsenzen) fast vollständig in ein nav gehören würde.
Auch scheint es Situationen zu geben, in denen mehrere Tags gleichzeitig angebracht wären, so wäre eine Kategorie „weiterführende Links” m.E. gleichermaßen mit aside, wie auch mit nav auszuzeichnen.
Also wie gesagt scheint mir das komplette Konzept von HTML5 viel zu unbestimmt zu sein. Eigentlich fand ich gerade die recht starren Definitionen voriger Varianten recht hilfreich, da man sich so m.E. viel mehr Gedanken um die tatsächliche Semantik machen musste („Ist das jetzt wirklich eine Liste und ist sie geordnet oder ungeordnet” o.ä.).
Ist das jetzt nur eine Art „Kulturschock” der Anfangsphase, der sich wieder legt, oder deckt sich eure Meinung (als erfahrenere Personen im Umgang mit HTML5) mit meinem Schwammigkeitsgefühl?
Ich habe mich mit html5 noch nicht so intensiv beschäftigt, daher nur so viel:
Auch, dass durch diese Auszeichnungen jetzt endlich die Überschriften besser mit den Passagen gruppiert werden können, auf die sie sich eigentlich beziehen, ist eine Sache, die ich mir schon seit gefühlten Ewigkeiten wünsche.
Eine Überschrift bezieht sich auf alles was unter ihr steht bis zu einer Übersschrift gleicher oder höherer Ordnung. Oder habe ich was verpaßt?
da der Titel (=die Überschrift)
I disagree.
da ... (=die Überschrift) ja eigentlich ein Meta-Datum ist
I disagree aber so was von.
Hi,
da ... (=die Überschrift) ja eigentlich ein Meta-Datum ist
I disagree aber so was von.
Kannst du das etwas näher ausführen?
Du schreibst doch selbst:
Eine Überschrift bezieht sich auf alles was unter ihr steht […]
Somit gehört alles, was darunter steht zu der jeweiligen Überschrift und die Überschrift gehört ihrerseits zu allem gleichermaßen.
Die Überschrift steht also so gesehen nicht nur lokal über dem jeweiligen Text, sondern auch logisch betrachtet.
da ... (=die Überschrift) ja eigentlich ein Meta-Datum ist
I disagree aber so was von.
Kannst du das etwas näher ausführen?
Du schreibst doch selbst:
Ich habe das Zitat schon mit Absicht so eingekürzt. Es ging mir an der Stelle nicht darum, wozu was wie gehört, sondern darum, daß eine Überschrift kein Meta-Datum ist. Nach dem andere darauf schon eingegangen sind, Überschriften sind Teil (Element) des Inhalts.
wozu was wie gehört:
Eine Überschrift bezieht sich auf alles was unter ihr steht […]
Somit gehört alles, was darunter steht zu der jeweiligen Überschrift und die Überschrift gehört ihrerseits zu allem gleichermaßen.
Die Überschrift steht also so gesehen nicht nur lokal über dem jeweiligen Text, sondern auch logisch betrachtet.
Und die Zuordnung ist eindeutig, auch ohne eine Auszeichnung. Auch wenn man in der Regel nicht mehr als drei Überschriften-Ordnungen benutzen sollte/muß, so kann die Anzahl der Überschriften dennoch sehr groß sein. Die mit einer Auszeichnung entstehende Verschachtelung wäre zwar konsequent, widerstrebt mir aber in ihrer Art und im Umfang. Es gibt aber durchaus Ausnahmen bei besonderen Anforderungen, dann ist <section> wohl ein gutes Mittel zum Zweck.
Hallo erstmal; wie fange ich denn am besten an?
„Ja, hallo erst mal! Ich weiß gar nicht, ob Sie’s wussten, aber …“ ;-)
Also ich könnte jetzt einen ganzen Roman als Antwort schreiben und wahrscheinlich käme ich dabei von Hölzchen auf Stöckchen ..., daher hier mal der Versuch es mit weit weniger Worten auszudrücken.
Dennoch habe ich nach allem, was ich bisher über HTML5 so gelesen habe irgendwie den Eindruck, dass man die Umsetzung nicht richtig durchdacht hat. Genaugenommen erscheint mir alles viel zu „schwammig“, so als habe man einfach ein paar Tags erstellt und dann der Welt hingeworfen mit den Worten „hier, guckt mal ob ihr es /irgendwie/ gebrauchen könnt”, anstatt von vorneherein klare Definitionen zu treffen.
Den Eindruck haben vermutlich viele Leute. Aber HTML wird imho immer "etwas schwammig" sein, denn welchen Umfang müsste es haben, wollte es das nicht (mehr) sein!?
Das Sektionen aus Artikel und Artikel wiederum aus Sektionen bestehen können, sowie dass jeder Artikel/Sektion wieder eigene Header und Footer enthalten kann, ist ja nicht unsinnig, wenn man eine Weile darüber nachdenkt. Aber dadurch, dass irgendwie alles optional ist, wirkt es so nichtssagend.
Imho muss man hier differenzieren. Meiner Meinung nach hat HTML5 im punkto Semantik so gut wie gar keine Änderungen oder gar Verbesserungen gebracht.
Dank HTML5 kann man Dokumente aber besser strukturieren!
Auch, dass durch diese Auszeichnungen jetzt endlich die Überschriften besser mit den Passagen gruppiert werden können, auf die sie sich eigentlich beziehen, ist eine Sache, die ich mir schon seit gefühlten Ewigkeiten wünsche. Aber die Umsetzung ist irgendwie auch nicht so toll finde ich.
Warum hat man denn zum Beispiel eine Konstruktion wie folgende erdacht:
<section>
<h1>Überschrift der Sektion</h1>
<p>…Text…</p>
<p>… und so weiter</p> …
</section>
> Anstatt das man einfach festgelegt hätte, dass das Universalattribut title für section und article eben verflichtend wäre und von den Browsern eben entsprechend einer Überschrift angezeigt wird:
> ~~~html
<section title="Überschrift der Sektion">
> <p>…Text…</p>
> <p>… und so weiter</p> …
> </section>
Das wäre m.E. deutlich logischer gewesen, da der Titel (=die Überschrift) ja eigentlich ein Meta-Datum ist, welches sich auf die Sektion/ den Artikel als ganzes bezieht.
Du meinst "Metadaten", oder?
Und da muss ich dir eindeutig widersprechen. Schon alleine aus der Tatsache heraus, dass eine Überschrift _immer_ eine Überschrift sein sollte und nicht der Inhalt irgendeines Attributs eines Container-Elements. Bei DIVs würdest du ja wahrscheinlich die Idee auch für nicht so gut halten, oder?
Es gibt aber noch eine ganze Reihe anderer Gründe, weshalb ich deine Idee für nicht "praktikabel" halte.
Aber das ist nur eine Kleinigkeit, bei der ich den Eindruck habe, man hätte sich bei der Semantik nicht genug Gedanken gemacht. So soll – wenn ich es richtig verstanden habe – das nav-Element für alle signifikanten Bestandteile verwendet werden, deren Hauptzweck es ist auf andere Seiten zu verzweigen. Das hieße ja praktisch, dass ein Inhaltsverzeichniss einer Webseite (also im Prinzip auch die Hauptseite der meisten Präsenzen) fast vollständig in ein nav gehören würde.
Letzteres würde ja von ihrem jeweiligen Inhalt abhängen.
Und ja, die Hauptnavigation einer Website, Breadcrumbs und TOCs darf man durchaus alle jeweils in ein Nav-Element stecken.
Auch scheint es Situationen zu geben, in denen mehrere Tags gleichzeitig angebracht wären, so wäre eine Kategorie „weiterführende Links” m.E. gleichermaßen mit aside, wie auch mit nav auszuzeichnen.
Nein, eben genau nicht! ;-)
Nicht _alle_Links gehören pauschal in ein Nav-Element.
Und hier sind wir auch wieder an dem Punkt "Semantik vs. Strukturierung". Die Semantik wird ja durch die Verwendung eines A-Elements ausgedrückt. Ein eventuelles (Container-)Nav-Element dient eher zur Strukturierung. Um ihm Semantik zu verleihen, musst du auf andere "Techniken", wie bspw. die WAI-ARIA Roles zurückgreifen.
Also wie gesagt scheint mir das komplette Konzept von HTML5 viel zu unbestimmt zu sein. Eigentlich fand ich gerade die recht starren Definitionen voriger Varianten recht hilfreich, da man sich so m.E. viel mehr Gedanken um die tatsächliche Semantik machen musste („Ist das jetzt wirklich eine Liste und ist sie geordnet oder ungeordnet” o.ä.).
Ist das nicht nach wie vor so ...!?
Ist das jetzt nur eine Art „Kulturschock” der Anfangsphase, der sich wieder legt, oder deckt sich eure Meinung (als erfahrenere Personen im Umgang mit HTML5) mit meinem Schwammigkeitsgefühl?
Ich will es mal so sagen:
HTML und seine Entwicklung erinnert mich stark an unseren neuen Hauptstadt Flughafen (BER) ...!
Von Hause aus eine gute Idee ...,
die erste Umsetzung begann vielversprechend, bis auffiel, dass entscheidende Dinge fehlten ...,
seitdem wird nachgebessert ohne jedoch wirkliche Verbesserungen zu erzielen ...,
Fertigstellung - nicht in Sicht (never)! ;-)
Einen Unterschied gibt es aber doch: HTML kann man wenigstens schon verwenden!
Gruß Gunther
Das wäre m.E. deutlich logischer gewesen, da der Titel (=die Überschrift) ja eigentlich ein Meta-Datum ist, welches sich auf die Sektion/ den Artikel als ganzes bezieht.
Du meinst "Metadaten", oder?
Ich denke er meint das:
"Gleichwohl ist „Datum“ der korrekte Singular zu „Daten“ und kann so auch Anwendung finden."
Quelle: http://de.wikipedia.org/wiki/Daten#Etymologie_und_Sprachgebrauch
Also fast, nur eben Einzahl.
Hallo,
Das Sektionen aus Artikel und Artikel wiederum aus Sektionen bestehen können, sowie dass jeder Artikel/Sektion wieder eigene Header und Footer enthalten kann, ist ja nicht unsinnig, wenn man eine Weile darüber nachdenkt. Aber dadurch, dass irgendwie alles optional ist, wirkt es so nichtssagend.
Vieles ist optional, weil HTML5 für Milliarden, wenn nicht für Billionen Dokumente da draußen gilt – sowohl für die neuen als auch für alle bestehenden! Die sind nun mal nicht alle gleich aufgebaut.
Anstatt das man einfach festgelegt hätte, dass das Universalattribut title für section und article eben verflichtend wäre und von den Browsern eben entsprechend einer Überschrift angezeigt wird:
<section title="Überschrift der Sektion">
In Attributen wird kein wichtiger Inhalt untergebracht, sondern höchstens zusätzlicher, vernachlässigbarer Inhalt. Essentiell wichtige Inhalte wie die Überschrift eines Abschnitts sollten nicht in einem Attribut untergebracht werden. Das ist eine Grundregel von allen SGML- und XML-basierten Markup-Sprachen.
Der wichtigere Grund, warum HTML5 nicht plötzlich bestehende Inhalte woanders untergebracht hat, ist die Abwärtskompatibilität. Siehe dazu /archiv/2014/3/t216791/#m1487567.
Das wäre m.E. deutlich logischer gewesen, da der Titel (=die Überschrift) ja eigentlich ein Meta-Datum ist, welches sich auf die Sektion/ den Artikel als ganzes bezieht.
Nein, es ist Teil des Inhalts, kein Metadatum, das in einem Attribut versteckt werden sollte.
So soll – wenn ich es richtig verstanden habe – das nav-Element für alle signifikanten Bestandteile verwendet werden, deren Hauptzweck es ist auf andere Seiten zu verzweigen.
Nein. Nicht alles, was eine Linkliste ist, gehört ins nav-Element.
Das hieße ja praktisch, dass ein Inhaltsverzeichniss einer Webseite (also im Prinzip auch die Hauptseite der meisten Präsenzen) fast vollständig in ein nav gehören würde.
Nein, das auf keinen Fall. nav soll die grundlegende, wiederkehrende Navigation auf einer Website beinhalten. Diese Hauptnavigation gibt über die Grundstruktur der Website Aufschluss – am besten auf oberster Ebene. Eine Startseite wie http://www.zeit.de/ etwa hat über 400 Links, aber nur eine Hauptnavigation, die die Grundstruktur der Website wiedergibt. Darin sind höchstens 10-20 Links, vielleicht noch verschachtelte Unterrubriken.
Auch scheint es Situationen zu geben, in denen mehrere Tags gleichzeitig angebracht wären, so wäre eine Kategorie „weiterführende Links” m.E. gleichermaßen mit aside, wie auch mit nav auszuzeichnen.
Nein, aside und nav widersprechen sich! Noch einmal, nur weil etwas eine Linkliste ist, ist es nicht mit nav auszuzeichnen. Siehe auch http://html5doctor.com/nav-element/.
Also wie gesagt scheint mir das komplette Konzept von HTML5 viel zu unbestimmt zu sein. Eigentlich fand ich gerade die recht starren Definitionen voriger Varianten recht hilfreich,
Die Definitionen in HTML 4.01 waren alles andere als starr, sondern leider sehr abstrakt und schwammig. HTML5 ist da viel konkreter und ausdifferenzierter. Hinreichend abstrakt muss das Markup immer noch sein, schließlich gibt es nicht bloß einen Typ von Dokumenten.
Ist das jetzt nur eine Art „Kulturschock” der Anfangsphase, der sich wieder legt, oder deckt sich eure Meinung (als erfahrenere Personen im Umgang mit HTML5) mit meinem Schwammigkeitsgefühl?
Zur Anwendung der HTML5-Sectioning äußert sich sowohl die HTML5-Spezifikation ziemlich konkret, als auch verschiedene Sekundärartikel, z.B. auf HTML5Doctor, Sitepoint oder Smashing Magazine. Eigentlich gibt es diesbezüglich keine großen Missverständnisse mehr, sondern es wurden schon Best Practices gefunden.
Grüße,
Mathias
Hallo!
Eigentlich gibt es diesbezüglich keine großen Missverständnisse mehr, sondern es wurden schon Best Practices gefunden.
Nein, das auf keinen Fall. nav soll die grundlegende, wiederkehrende Navigation auf einer Website beinhalten. Diese Hauptnavigation gibt über die Grundstruktur der Website Aufschluss – am besten auf oberster Ebene.
Das scheint mir ein "weit verbreiteter Irrtum" zu sein.
Denn wie ich bereits in meiner Antwort hier geschrieben habe, gehören Breadcrumbs und TOCs auf einer Seite ebenfalls zu den Elementen, die mittels eines Nav-Elements ausgezeichnet werden können/ sollten.
Gruß Gunther
Das scheint mir ein "weit verbreiteter Irrtum" zu sein.
Irrtum bestimmt nicht. Eine andere Meinung höchstens. Ich habe absichtlich ein Beispiel genannt, das meine Aussagen zu Hauptnavigation vs. andere Navigationen illustriert.
Denn wie ich bereits in meiner Antwort hier geschrieben habe, gehören Breadcrumbs und TOCs auf einer Seite ebenfalls zu den Elementen, die mittels eines Nav-Elements ausgezeichnet werden können/ sollten.
Ja, *können*. Es ist nicht ausgeschlossen. Es sind schließlich »major navigation blocks«. Generell gilt, dass das Element eher sparsam und nicht inflationär eingesetzt werden sollte. Wenn es zahlreiche navs in einem Dokument gibt, verliert das Element seine Nützlichkeit.
Wenn es eine Hauptnavigation gibt, so ist diese mit nav auszuzeichnen. Wenn es ein längeres Inhaltsverzeichnis gibt (mit Links zu Ankern nach unten im Dokument), dann ist nav ebenfalls angebracht. Bei einem Breadcrumb halte ich es für unnötig, aber falsch ist es nicht.
Was man nun mit nav auszeichnet und was nicht, muss man am konkreten Dokument entscheiden. Ich würde nicht fünf navs benutzen, nur weil es fünf »major navigation blocks« sind, sondern die wichtigen 1-2 identifizieren.
Mathias
Das scheint mir ein "weit verbreiteter Irrtum" zu sein.
Irrtum bestimmt nicht. Eine andere Meinung höchstens.
Doch Irrtum! Und zwar dahingehend, dass genau solche "Beispiele" und Formulierungen, wie du sie auch verwendet hast, von sehr vielen Usern dahingehend verstanden/ interpretiert werden, dass_ausschließlich_die Hauptnavigation einer Seite mittels Nav ausgezeichnet wird. Und das ist eben schlicht ein "Irrtum".
Ich habe absichtlich ein Beispiel genannt, das meine Aussagen zu Hauptnavigation vs. andere Navigationen illustriert.
Das tun eben viele, weil die Hauptnavigation zum einen sicherlich das wesentlichste Nav-Element auf einer Seite ist, und zum anderen genau die Abgrenzung zu "anderen Navigationen" eine häufige Fehlerursache ist.
Aber genau dadurch wird der eingangs beschriebene Eindruck hervorgerufen, bzw. verstärkt.
Denn wie ich bereits in meiner Antwort hier geschrieben habe, gehören Breadcrumbs und TOCs auf einer Seite ebenfalls zu den Elementen, die mittels eines Nav-Elements ausgezeichnet werden können/ sollten.
Ja, *können*. Es ist nicht ausgeschlossen. Es sind schließlich »major navigation blocks«. Generell gilt, dass das Element eher sparsam und nicht inflationär eingesetzt werden sollte. Wenn es zahlreiche navs in einem Dokument gibt, verliert das Element seine Nützlichkeit.
Das sehe ich nicht so. Seine "Nützlichkeit" erhält es sowieso erst dadurch, dass man zusätzliche Attribute verwendet (Stichwort "WAI-ARIA Role").
Ein Nav-Element alleine ist nicht "nützlicher", als bspw. ein <div id="navigation">.
Wenn es eine Hauptnavigation gibt, so ist diese mit nav auszuzeichnen. Wenn es ein längeres Inhaltsverzeichnis gibt (mit Links zu Ankern nach unten im Dokument), dann ist nav ebenfalls angebracht. Bei einem Breadcrumb halte ich es für unnötig, aber falsch ist es nicht.
Ein Breadcrumb(-Trail) ist für mich nichts anderes, als ein "Auszug" der (Haupt-)Navigation, der den konkreten Weg zur aktuellen Seite darstellt. Also warum nicht mit einem Nav-Element auszeichnen?
Was man nun mit nav auszeichnet und was nicht, muss man am konkreten Dokument entscheiden. Ich würde nicht fünf navs benutzen, nur weil es fünf »major navigation blocks« sind, sondern die wichtigen 1-2 identifizieren.
Ich halte diese Betrachtungsweise einer zahlenmäßigen Abhängigkeit für nicht sinnvoll. Denn die Frage, ob etwas als Nav-Element ausgezeichnet werden sollte oder nicht, ist doch nicht von der Häufigkeit abhängig, sondern schlicht vom Inhalt, oder?
Ob es angebracht ist, dass man mehr als 2 oder 3 »major navigation blocks« auf einer Seite hat, ist eine andere Frage.
Aber nochmal: Mir geht und ging es hauptsächlich darum, den Eindruck/ die Fehlinterpretation zu verhindern, dass_ausschließlich_die Hauptnavigation einer Seite mittels Nav ausgezeichnet wird.
Gruß Gunther
Doch Irrtum! Und zwar dahingehend, dass genau solche "Beispiele" und Formulierungen, wie du sie auch verwendet hast, von sehr vielen Usern dahingehend verstanden/ interpretiert werden, dass_ausschließlich_die Hauptnavigation einer Seite mittels Nav ausgezeichnet wird. Und das ist eben schlicht ein "Irrtum".
Ich habe keine Lust, auf einem solchen Niveau des Rechthabens wegen zu streiten.
Ich denke, inhaltlich ist meine Position völlig klar geworden.
Guten Tag.
Mathias
Hallo Mathias!
Doch Irrtum! Und zwar dahingehend, dass genau solche "Beispiele" und Formulierungen, wie du sie auch verwendet hast, von sehr vielen Usern dahingehend verstanden/ interpretiert werden, dass_ausschließlich_die Hauptnavigation einer Seite mittels Nav ausgezeichnet wird. Und das ist eben schlicht ein "Irrtum".
Ich habe keine Lust, auf einem solchen Niveau des Rechthabens wegen zu streiten.
Bist du heute mit dem falschen Fuß aufgestanden? :-P
Ich gehe eigentlich davon aus, dass wir uns hier im Forum zumindest schon lange genug "kennen", als dass deinerseits eine solche Interpretation meines Beitrags angebracht ist.
Und "Irrtum" bezieht/ bezog sich auf den Schluss, den viele User daraus ziehen (und nicht etwa darauf, dass du "irren" würdest - geht aber auch mehr als deutlich aus dem Geschriebenen hervor).
Von daher halte ich es nach wie vor für äußerst angebracht, explizit auf diese Tatsache hinzuweisen!
Gruß Gunther
Seine "Nützlichkeit" erhält [nav] sowieso erst dadurch, dass man zusätzliche Attribute verwendet (Stichwort "WAI-ARIA Role").
???
nav hat implizit die Landmark-Role navigation.
Ein Nav-Element alleine ist nicht "nützlicher", als bspw. ein <div id="navigation">.
Das ist falsch.
Mathias
Seine "Nützlichkeit" erhält [nav] sowieso erst dadurch, dass man zusätzliche Attribute verwendet (Stichwort "WAI-ARIA Role").
Ja, und seine "spezielle" Bedeutung erhält es dann bspw. durch "aria-label".
Deshalb schrieb ich ja auch "Attribute" (Plural), da das role-Attribut alleine auch immer noch nicht ausreichend ist.
Ein Nav-Element alleine ist nicht "nützlicher", als bspw. ein <div id="navigation">.
Das ist falsch.
Aha! ;-)
Und wo und/ oder wie macht das einen Unterschied?
Gruß Gunther
Hallo!
Und wo und/ oder wie macht das einen Unterschied?
Zu behaupten, ein div mit einer ID sei genauso nützlich wie ein nav-Element, ist so falsch wie die Behauptung, ein div mit einer ID/Klasse sei genauso nützlich wie ein h1. Mit dem Argument könnte man auch <span class="h1"> schreiben und es für gleich nützlich erklären.
Ein nav-Element markiert einen »major navigation block«. Ein nav ist ferner eine spezielle Section. – Ein div macht gar keine derartige Aussage über den Inhalt. – Ein User-Agent kann diese Bedeutung kommunizieren. Viele User-Agents tun es bereits. Noch mehr User-Agent werden das in Zukunft tun. Es ist kontraproduktiv, zu behaupten, ein nav wäre nicht nützlicher als ein div. Es ist falsch zu behaupten, dass ARIA-Attribute nötig sind, um ein nav von einem div abzugrenzen. Ein nav hat bereits eine inhärente Semantik. Ein aria-label halte ich für redundant, denn eine Section in HTML5 hat bereits einen Titel, angegeben durch das hX-Element darin.
Ich weiß nicht, wieso du Grundlagen der Textauszeichnung, die in den letzten 10 Jahren mühselig erarbeitet worden sind, infrage stellst. Solche Diskussionen um Semantik waren vor 10 Jahren sinnvoll, als noch <font> regierte und »div-Layouts« aufkamen. Heute gibt es Best Practices, hinter die man nicht zurückfallen sollte.
Mathias
Hallo Mathias!
Und wo und/ oder wie macht das einen Unterschied?
Zu behaupten, ein div mit einer ID sei genauso nützlich wie ein nav-Element, ist so falsch wie die Behauptung, ein div mit einer ID/Klasse sei genauso nützlich wie ein h1. Mit dem Argument könnte man auch <span class="h1"> schreiben und es für gleich nützlich erklären.
Das ist natürlich immer das Problem an etwas "überspitzten" Beispielen.
Ich wollte damit auch primär zum Ausdruck bringen, dass imho ein reines Nav-Element keinen zusätzlichen "Nutzen" gegenüber der vor HTML5 üblichen Auszeichnung mit sich bringt.
Dessen ungeachtet sollte man selbstverständlich das semantisch angebrachteste Element verwenden (so war mein Beispiel auch nicht zu verstehen).
Ein nav-Element markiert einen »major navigation block«. Ein nav ist ferner eine spezielle Section. – Ein div macht gar keine derartige Aussage über den Inhalt. –
ACK
Ein User-Agent kann diese Bedeutung kommunizieren. Viele User-Agents tun es bereits. Noch mehr User-Agent werden das in Zukunft tun.
Das ist der "springende Punkt", um den es mir geht/ ging.
Und meine Frage bezieht/ bezog sich darauf, inwiefern User-Agents dies tun?
Ich weiß nicht, wieso du Grundlagen der Textauszeichnung, die in den letzten 10 Jahren mühselig erarbeitet worden sind, infrage stellst.
Tue ich nicht - war zumindest nicht beabsichtigt.
Heute gibt es Best Practices, hinter die man nicht zurückfallen sollte.
Und die sehen im Bezug auf Breadcrumbs und TOCs wie aus?
Die Frage ist vollkommen ernst gemeint, denn ich habe bei meinen durchaus intensiven Recherchen im Netz eben genau keine "Best Practices" gefunden. Und eben auch nichts zu der Frage, ob und wie User-Agents die Bedeutung von Nav-Elementen "kommunizieren"!
Und ich stelle mir auch die Frage, wie sie das ("vernünftig") tun sollten, wenn ein Nav-Element außer der Hauptnavigation eben auch ein Breadcrumb-Trail oder TOC sein kann?
Ich bin viel eher der Meinung, dass es eben genau zusätzlicher "Techniken/ Auszeichnungen" bedarf, um dies zu erreichen. Unter anderem bringen mich die Bemühungen von Google & Co. im Bezug auf Schema.org zu dieser Meinung.
Vielleicht sollte man aber auch differenzieren zwischen "normalen" Browsern (visuelle/ grafische Darstellung) und anderen Ausgabemedien wie Screenreadern? Für Erstere ist eine "besondere" Bedeutung ja nicht unbedingt so dringend erforderlich, da sich diese zumeist aus der Darstellung und Positionierung der entsprechenden Elemente ergibt.
Gruß Gunther
Und meine Frage bezieht/ bezog sich darauf, inwiefern User-Agents dies tun?
http://www.maxability.co.in/tag/html-5-accessibility-2/:
»The <nav> tag of HTML 5 and the role=”navigation” of ARIA are used for the same purpose. The area of web page that contains A collection of navigational Elements (usually links) for navigating the document or related documents.
Screen Reader Support
HTML 5 NAV
ARIA ROLE="NAVIGATION"
JAWS 13 supports navigation (role) in all the 3 browsers.
NVDA 2012.3 supports navigation (role) in all the 3 browsers.
Talkback on Android supports the navigation role.«
http://html5accessibility.com/:
»IE: provides no semantic information via accessibility APIs
Chrome: exposes element with a section role in IA2
Firefox: exposes as ARIA landmark role="navigation" via IA2 object attribute, and as a section role in IA2 (Unsure about the correctness of this mapping). Refer to HTML5 Accessibility Chops: section elements«
Daher die allgemeine Empfehlung, vorübergehend
<nav role="navigation">
zu schreiben. Für main gilt ja dasselbe:
<main role="main">
Mathias
Hallo Mathias!
Vielen Dank - das meinte ich.
Und meine Frage bezieht/ bezog sich darauf, inwiefern User-Agents dies tun?
http://www.maxability.co.in/tag/html-5-accessibility-2/:
»The <nav> tag of HTML 5 and the role=”navigation” of ARIA are used for the same purpose. The area of web page that contains A collection of navigational Elements (usually links) for navigating the document or related documents.
Screen Reader Support
...
Also sprechen wir hier eben genau von anderen "Programmen", als dem "klassischen Browser".
Daher die allgemeine Empfehlung, vorübergehend
<nav role="navigation">zu schreiben. Für main gilt ja dasselbe:
<main role="main">
Und imho sind eben genau hier weder HTML5, noch die WAI-ARIA Roles präzise genug (weshalb ich persönlich zusätzlich eben noch ein "aria-label" Attribut verwende, zusätzlich zur Section-Heading).
Um dann auch mal wieder die Kurve zurück zum eigentlichen Thema dieses Threads zu kriegen:
Wenn man mal davon ausgeht, dass jedes Dokument nur jeweils über eine(n) einzige(n)
verfügt, bzw. verfügen sollte, dann ist doch die logische Konsequenz daraus, dass man sich fragen muss, warum gibt es nicht die Elemente
sondern stattdessen nur ein "generisches" Nav-Element?
Welches man noch dazu noch nicht einmal mittels des Role-Attributs näher spezifizieren kann!
Imho hat man hier eine gute Gelegenheit mehr Semantik ins HTML zu kriegen vertan. Und aufgrund der Abwärtskompatibilität wird man das auch in Zukunft nicht mehr "geradebiegen" können, da es dann schon Millionen von Websites gibt, die eben mehr als ein Nav-Element in einem Dokument verwenden.
Gruß Gunther
sondern stattdessen nur ein "generisches" Nav-Element?
Welches man noch dazu noch nicht einmal mittels des Role-Attributs näher spezifizieren kann!
Hmm? Ein nav-Element lässt sich einem eigenen role-Attribut ausstatten. role="navigation" ist implizit, was nicht heißt, dass es nicht überschrieben werden kann. Z.B. ist <nav role="search"> möglich.
Mathias
sondern stattdessen nur ein "generisches" Nav-Element?
Welches man noch dazu noch nicht einmal mittels des Role-Attributs näher spezifizieren kann!Hmm? Ein nav-Element lässt sich einem eigenen role-Attribut ausstatten. role="navigation" ist implizit, was nicht heißt, dass es nicht überschrieben werden kann. Z.B. ist <nav role="search"> möglich.
Ja, schon klar. Aber womit willst du es denn jeweils für
überschreiben? AFAIK gibt es kein "passenderes" Role-Attribut als "navigation", oder?
Und ob nav für ein Such-Eingabefeld das "passendste" Element ist, ist ja wieder eine ganz andere Frage (die uns aber jetzt nicht weiter beschäftigen sollte). ;-)
Gruß Gunther
Ja, *können*. Es ist nicht ausgeschlossen.
Euer kleiner „Streit” zeigt recht gut mein Empfinden der Schwammigkeit. ;-)
Es gibt m.E. zu viele „können”s und zu wenige „sollen” oder „müssen“ bei HTML5.
Eigentlich hätte man auch bei der Gelegenheit noch ein Tag definieren können, welches soviel aussagt wie „dieser Block hat keinerlei Inhaltliche Relevanz und dient ausschließlich dazu die Seite optisch aufzuhübschen”.
Om nah hoo pez nyeetz, TSO!
Eigentlich hätte man auch bei der Gelegenheit noch ein Tag definieren können, welches soviel aussagt wie „dieser Block hat keinerlei Inhaltliche Relevanz und dient ausschließlich dazu die Seite optisch aufzuhübschen”.
Gibt es. Div- resp. span-Elemente.
Matthias
Eigentlich hätte man auch bei der Gelegenheit noch ein Tag definieren können, welches soviel aussagt wie „dieser Block hat keinerlei Inhaltliche Relevanz und dient ausschließlich dazu die Seite optisch aufzuhübschen”.
Gibt es. Div- resp. span-Elemente.
Das ist schon ein bisschen was anderes.
Div, bzw. Span haben ja für sich genommen eben keinerlei semantische Bedeutung. Sie sagen überhaupt nichts darüber aus, welche Relevanz den ihnen enthaltenen Inhalten zukommt.
Was ich meinte wäre ein Element, welches eben durchaus eine Bedeutung hat, nämlich die, dass es explizit aussagt, dass die enthaltenen Elemente keine inhaltliche Relevanz haben.
Das ist in etwa so, wie der Vergleich einer leeren Menge, mit einer Menge, die das Element 0 enthält.
Om nah hoo pez nyeetz, TSO!
Was ich meinte wäre ein Element, welches eben durchaus eine Bedeutung hat, nämlich die, dass es explizit aussagt, dass die enthaltenen Elemente keine inhaltliche Relevanz haben.
Das gibts auch: s.
Das ist in etwa so, wie der Vergleich einer leeren Menge, mit einer Menge, die das Element 0 enthält.
Oder der Vergleich von {} mit {∅} bzw. ∅ mit {∅}.
Matthias
Meine Herren!
Was ich meinte wäre ein Element, welches eben durchaus eine Bedeutung hat, nämlich die, dass es explizit aussagt, dass die enthaltenen Elemente keine inhaltliche Relevanz haben.
Auch sowas gibt es:
WAI-ARIA ist kein integrativer Bestandteil von HTML, sondern eine Erweiterung, die die accessibility verbessern möchte.
ein Element, [das] explizit aussagt, dass die enthaltenen Elemente keine inhaltliche Relevanz haben.
Was sollte ein User-Agent mit solchen Elementen tun? Ignorieren? (Warum sollten sie im Dokument stehen, wenn sie keine Relevanz haben?)
Es gibt in HTML5 bereits das hidden-Attribut und es ist bei allen Elementen erlaubt. Ein User-Agent soll diese Inhalte komplett ignorieren, zumindest bis ein Script o.ä. das Attribut entfernt.
Mathias
ein Element, [das] explizit aussagt, dass die enthaltenen Elemente keine inhaltliche Relevanz haben.
Was sollte ein User-Agent mit solchen Elementen tun? Ignorieren? (Warum sollten sie im Dokument stehen, wenn sie keine Relevanz haben?)
Nunja, es gibt heutzutage ja auf sehr vielen Seiten unzählige Elemente, die absolut keine /inhaltliche/ Relevanz haben, sondern nur der optischen Repräsentation dienen.
Ein User-Agent sollte daher meiner Meinung nach folgendermaßen damit verfahren: Wird die Seite so angezeigt, wie der Designer es geplant hat, sollte das Element natürlich angezeigt werden.
Wird hingegen eine andersartige Repräsentation gewählt (also User-Stylesheet, gar kein Style, Braille-Ausgabe, Vorlese-Funktion, o.ä.) sollte das Element in der Tat komplett ignoriert werden.
Ich finde es jedenfalls immer recht störend, wenn ich in meinem Browser die Seiten-Stylesheets abschalte und mich dann dennoch durch unzählige Grafiken und Texte kämpfen muss, die mit dem Seiteninhalt nichts zu tun haben.
Hi!
ein Element, [das] explizit aussagt, dass die enthaltenen Elemente keine inhaltliche Relevanz haben.
Was sollte ein User-Agent mit solchen Elementen tun? Ignorieren? (Warum sollten sie im Dokument stehen, wenn sie keine Relevanz haben?)
Nunja, es gibt heutzutage ja auf sehr vielen Seiten unzählige Elemente, die absolut keine /inhaltliche/ Relevanz haben, sondern nur der optischen Repräsentation dienen.
Ein User-Agent sollte daher meiner Meinung nach folgendermaßen damit verfahren: Wird die Seite so angezeigt, wie der Designer es geplant hat, sollte das Element natürlich angezeigt werden.
Wird hingegen eine andersartige Repräsentation gewählt (also User-Stylesheet, gar kein Style, Braille-Ausgabe, Vorlese-Funktion, o.ä.) sollte das Element in der Tat komplett ignoriert werden.
Dieser "Logik" kann ich nicht folgen!
Damit überhaupt irgendeine Art von "Repräsentation" möglich ist, muss doch dazu ein Element im Dokument vorhanden sein.
Und die Option "Ignorieren" macht imho keinen Sinn, denn ein solches Element wäre ja schlicht überflüssig im HTML Code.
Ich finde es jedenfalls immer recht störend, wenn ich in meinem Browser die Seiten-Stylesheets abschalte und mich dann dennoch durch unzählige Grafiken und Texte kämpfen muss, die mit dem Seiteninhalt nichts zu tun haben.
Das sind jetzt aber Äpfel & Birnen wild durcheinander geworfen ...! ;-)
Wenn ein Autor sein Dokument per HTML5 korrekt ausgezeichnet hat, dann könnte ggf. ein User-Stylesheet à la:
* {display: none}
main,
main *,
nav,
nav * {display: block}
aside {display: none}
zum gewünschten Resultat führen.
Gruß Gunther
Nunja, es gibt heutzutage ja auf sehr vielen Seiten unzählige Elemente, die absolut keine /inhaltliche/ Relevanz haben, sondern nur der optischen Repräsentation dienen.
Solche Elemente sind möglichst zu vermeiden. Es wird sowohl in HTML als auch CSS viel dafür getan. Deshalb wird HTML5 kein Element dafür bereitstellen, weil es nicht erwünscht ist.
Solche Elemente *können* auch meist vermieden werden. Boxen lassen sich mit CSS einfügen (::after, ::before, content). Mit Rahmen, Hintergrundbildern und Verläufen kann man visuelle Effekte erzielen, für die früher ein HTML-Element nötig war (man denke z.B. an abgerundete Ecken).
Ich finde es jedenfalls immer recht störend, wenn ich in meinem Browser die Seiten-Stylesheets abschalte und mich dann dennoch durch unzählige Grafiken und Texte kämpfen muss, die mit dem Seiteninhalt nichts zu tun haben.
Warum liegen sie denn im Dokument? Wenn sie später irgendwann mit JavaScript angezeigt werden, dann ist das hidden-Attribut genau richtig.
Und schließlich sollte das Dokument so strukturiert sein, dass solche Inhalte an geeigneter Stelle stehen und geeignet ausgezeichnet sind. Z.B. als Sections, die man gut überspringen kann.
Mathias
Es gibt m.E. zu viele „können”s und zu wenige „sollen” oder „müssen“ bei HTML5.
Noch einmal, HTML5 ist das Format, in dem weltweit wahrscheinlich am meisten Dokumente vorliegen. Eine strenge Grammatik, die genau festlegt, wo welche Elemente zu stehen haben, kann man nur definieren, wenn die Anwendungszwecke sehr begrenzt sind. Alle Sprachen machen einen derartigen Spagat zwischen Strenge und Offenheit bzw. breiter Einsetzbarkeit.
Je breiter der Anwendungsbereich ist, je vielfältiger die Anforderungen an die Sprache sind, desto schwieriger wird es, verbindliche Regeln aufzustellen. Die Komplexität der Sprache tut ihr übriges: HTML5 lässt sich nicht vollständig, sondern nur teilweise in den verbreiteten Schema-Sprachen ausdrücken (XML-DTD, XML Schema, RelaxNG, Schematron…).
Abwärtskompatibilität habe ich ebenfalls angesprochen: Es ist der Anspruch von HTML5, dass die vorherigen HTML- und XHTML-Versionen als HTML5 verarbeitet und z.T. validiert werden können. Unter dieser Voraussetzung ist es nicht möglich, plötzlich eine neue normative Dokumentstruktur zu erfinden.
Ein technischer Standard beschreibt erst einmal, was technisch erlaubt und valide ist. Es ist kein umfassendes Anwenderhandbuch. Er bedarf einer Auslegung und Anwendung durch Sekundärquellen. In einer Grammatik für die deutsche Sprache, die nüchtern und deskriptiv Syntaxregeln beschreibt, lässt sich auch nicht finden, was gute Sprache ausmacht.
Mathias
Meine Herren!
Ich war eigentlich schon immer ein Freund der Idee des semantischen Markups. Wichtig ist nunmal der Inhalt, und nicht, wie dieser nun genau präsentiert wird.
Das hast du unglücklich formuliert. Die Präsentation spielt auch weiterhin eine große Rolle, nur ist sie im CSS besser aufgehoben als im HTML.
Genaugenommen erscheint mir alles viel zu „schwammig“, so als habe man einfach ein paar Tags erstellt und dann der Welt hingeworfen mit den Worten „hier, guckt mal ob ihr es /irgendwie/ gebrauchen könnt”, anstatt von vorneherein klare Definitionen zu treffen.
Die Wahl der Elemente basiert soweit ich weiß (teilweise) auf empirischen Methoden, man hat Stichproben genommen geschaut, welche IDs und Klassennamen sind beliebt und dann diskutiert, ob die Elemente gut mit den gesetzten HTML5-Zielen harmonisieren.
Das Sektionen aus Artikel und Artikel wiederum aus Sektionen bestehen können, sowie dass jeder Artikel/Sektion wieder eigene Header und Footer enthalten kann, ist ja nicht unsinnig, wenn man eine Weile darüber nachdenkt. Aber dadurch, dass irgendwie alles optional ist, wirkt es so nichtssagend.
Naja, man muss ja nicht alles machen, was technisch möglich ist. artcile-Elemente ineinander zu verschachteln ist wohl in den seltensten Fällen zweckdienlich, aber für die wenigen Fälle, wo es dann doch angebracht ist, ist es gut, dass uns das nicht von HTML5 als Restriktion auferlegt wurde. Es schadet immerhin nicht.
Wirklich fragwürdig finde ich den Entschluss, dass man einige präsentationsbezogene Elemente (z.B. <i> oder <b>) mitschleift und dass man versucht hat für eben diese eine Semantik mit der Brechstange herbei zu führen, anstatt sie aussterben zu lassen. Da hat der Wunsch nach Abwärtskompatibilität eine zu große Rolle beigemessen bekommen.
Warum hat man denn zum Beispiel eine Konstruktion wie folgende erdacht:
<section>
<h1>Überschrift der Sektion</h1>
<p>…Text…</p>
<p>… und so weiter</p> …
</section>
> Anstatt das man einfach festgelegt hätte, dass das Universalattribut title für section und article eben verflichtend wäre und von den Browsern eben entsprechend einer Überschrift angezeigt wird:
> ~~~html
<section title="Überschrift der Sektion">
> <p>…Text…</p>
> <p>… und so weiter</p> …
> </section>
Das wäre m.E. deutlich logischer gewesen, da der Titel (=die Überschrift) ja eigentlich ein Meta-Datum ist, welches sich auf die Sektion/ den Artikel als ganzes bezieht.
Dadurch, dass man ein eigenes Element für Überschriften verwendet, kann deren Inhalt wiederum durch Markup ausgezeichnet werden, bei Attributen geht das nicht. Man sehe sich dazu die Diskussion um das alt-Attribut bei Bildern an.
Die Rückbesinnung auf Semantik ist meiner Meinung nach ein geglücktes Ziel, weitere Stärken liegen zudem noch in der Öffnung des Standards für Erweiterungen (siehe WAI-ARIA oder WebComponents) und in der Trennung von einem dtd-basierten Format.