Im der erste Teil dieser Serie Wir haben die Fehler, die zu den strukturellen Elementen von HTML5 geführt haben, behandelt. In diesem zweiten Teil werden wir uns eingehend mit den Konsequenzen dieser Fehler befassen.
Ich habe mehrmals gesagt, dass HTML5 eine neue Methode zum Strukturieren einer Webseite einführt, und Sie fragen sich wahrscheinlich, was das eigentlich ist. Es ist genau dort in der Spezifikation, die führt das Konzept des "Teilens von Inhalten" ein ': Das Teilen von Inhalten ist Inhalt, der den Umfang von Überschriften und Fußzeilen definiert. Jedes abschneidende Inhaltselement hat möglicherweise eine Überschrift und eine Gliederung.
Die Spezifikation dokumentiert ihren Ansatz zu Überschriften, Abschnitte und Umrisse um das Konzept zu verdeutlichen. Nun, klar für diejenigen, die die Funktionalität in Browsern implementieren müssen. Damit wir die Strukturelemente von HTML (Abschnitt, Artikel, nav, side und die zugehörigen Elemente header und footer) und dieses obskure Konzept des "sectioning content" oder "outlining" verstehen können, müssen wir eine kleine Reise durch die HTML-Geschichte machen.
Das in HTML5 eingeführte Konzept des Outlining kann bis 1991 zurückverfolgt werden und wurde in die unglückselige, dead-end XHTML 2.0-Spezifikation aufgenommen und schließlich in HTML5 ans Tageslicht gebracht ... nur um so schlecht kommuniziert zu werden, dass die Idee dahintersteckt ist ziemlich tot bei der Ankunft.
Vor HTML5 wurde die hierarchische Struktur einer Seite durch die Überschriftenelemente bestimmt - unsere alten Freunde h1 bis h6. Wir könnten eine Seite strukturieren, indem wir sagen, dass der Seitentitel h1 ist, die Artikelüberschrift h2 sein kann und vielleicht Unterüberschriften in dem Artikel h3 und h4 sein könnten, und so weiter.
Dies ist in Ordnung für ein einfaches Dokument, aber die Verwendung von Überschriften-Tags zum Erstellen einer logischen Hierarchie oder "Dokumentenumriss" für eine komplexe, moderne Webseite ist sehr schwierig. Ein Teil des Problems ist das Fehlen einer Möglichkeit zu bestimmen, wo ein Seitenabschnitt beginnt und endet. Nehmen wir zum Beispiel an, wir hätten unser vorheriges Dokument mit h1 für den Seitentitel, h2 für den Artikeltitel, h3 für die Unterüberschriften, wollten dann aber auch den Titel für unsere Seitenleistenabschnitte mit h3-Überschriften markieren.
Das Dokument, das eine solche Struktur erstellen würde, würde ungefähr so aussehen:
My Old Blog
My Latest Blog Post
My Blog Post Sub Heading
My Blog Post Sub Heading
About Me
Archives
Social Links
Hier sind die h3-Elemente dem h2 über ihnen "gehört", auch wenn es nicht viel Sinn macht. Natürlich würden wir dies mit etwas wie div für den Artikel und div für die Seitenleiste auflösen, aber diese werden von Benutzeragenten (wie Screenreadern) ignoriert, die den Seitenumriß allein durch die Überschriftenstruktur bestimmen.
Indem wir die Seitenhierarchie direkt mit den häufig darstellenden Überschriftsebenen verknüpfen, haben wir nur begrenzte Möglichkeiten, wie wir eine Seite strukturieren können.
Bei dem Versuch, dieses Problem zu lösen, führt HTML5 das Konzept der "Gliederungselemente" ein, dh spezielle Elemente, die die Seite in - Sie haben es erraten - Abschnitte aufteilen, und diese Abschnitte bestimmen die Verschachtelungsebene von Überschriften und tatsächlich die Hierarchie oder "Umriss" der Seite.
Das heißt, die Hierarchie der Seite wird von den Überschriftenelementen abgekoppelt, und stattdessen bestimmen diese neuen Unterteilungselemente, auf welcher Ebene ein Überschriftenelement tatsächlich ist.
Im ersten Entwurf XHTML 2.0-Spezifikation Schnitt mit einem Abschnittselement und einem generischen Headerelement h. Beim Schreiben von HTML würden wir dann nicht angeben, welche Ebene der Überschrift wir verwenden wollten, wir sollten einfach den Grad der Verschachtelung für eine bestimmte Überschrift bestimmen lassen. Wir könnten Abschnittselemente 99 Ebenen tief verschachteln, und ein h-Element auf der 99. Ebene wäre äquivalent zu einem h99-Element. Auf diese Weise können wir unsere Dokumente logisch strukturieren, ohne uns darum kümmern zu müssen, wie wir die limitierten h1-h6-Elemente nutzen können.
(Diese Idee stammt übrigens aus dem Jahr 1991, als: Jeremy Keith wies darauf hin, dass Tim Berners-Lee die Idee eines Abschnitts und h Elements aufstellte, um eine Seite am Ende zu strukturieren Diese E-Mail vom Oktober 1991 .)
Hickson versuchte, dasselbe Konzept in HTML5 einzuführen, aber mit einem zusätzlichen Schwierigkeitsgrad: Er wollte die Abwärtskompatibilität beibehalten und eine neue Semantik einführen, um das Authoring zu vereinfachen. Anstatt also nur ein Abschnittselement in HTML5 zu haben, haben wir auch ein Artikel-, Navigations- und Seitenelement, die alle dasselbe tun wie Abschnitt, aber mit unterschiedlichen Namen, die auf unterschiedliche Weise verwendet werden können.
Was sagt die Spezifikation über diese Elemente aus? Ich ermutige Sie dazu Lesen Sie die Spezifikation für sich , aber hier ist ein Geschmack:
Das section-Element ist die Grundlage für das Erstellen von Dokumentenkonturen.
Das Abschnittselement repräsentiert einen generischen Abschnitt eines Dokuments oder einer Anwendung. Ein Abschnitt ist in diesem Zusammenhang eine thematische Gruppierung von Inhalten, typischerweise mit einer Überschrift.
Beispiele für Abschnitte sind Kapitel, die verschiedenen Registerseiten in einem Dialogfeld mit Registerkarten oder die nummerierten Abschnitte einer Dissertation. Die Homepage einer Website kann in Abschnitte für eine Einführung, Nachrichten und Kontaktinformationen unterteilt werden.
Eine Notiz in der Spezifikation besagt, dass das Element nicht für reine Styling-Zwecke verwendet werden sollte - ein Div wäre dort besser und verständlicher, da Abschnitte, die in Willy-Nilly zum Stylen geworfen werden, einen sehr defekten Dokumentenumriss erzeugen würden.
Der Hinweis sagt weiter: "Eine allgemeine Regel ist, dass das Element section nur dann geeignet ist, wenn der Inhalt des Elements explizit in der Gliederung des Dokuments aufgeführt würde", und das ist die klarste Aussage über das Element section in der Spezifikation.
Wenn wir das Konzept des Teilens und Umreißens verstehen, macht die Einbeziehung des Abschnittselements Sinn. Es erschien nicht in der allgemeinen Klassenwerteforschung, aber es tauchte in XHTML 2.0 auf und geht konzeptionell auf 1991 zurück.
Die anderen strukturellen Elemente, die HTML5 einführt - diejenigen, die sich angeblich in der Forschung widerspiegeln sollten - tun genau dasselbe wie das Abschnittselement, was die Dokumentengliederung betrifft. Sie erstellen auch die Hierarchie der Seite und damit die Dokumentgliederung.
Nehmen Sie zum Beispiel das Artikelelement. Viele Leute nehmen an, dass es nur für Artikel wie diesen ist. Aber das ist es überhaupt nicht. Es ist "Artikel" im Sinne von "ein Kleidungsstück". Es ist besser als "Gegenstand" wie in "ein Kleidungsstück" gedacht, da seine Definition so breit ist.
Wenn Artikelelemente verschachtelt sind, repräsentieren die inneren Artikelelemente Artikel, die im Prinzip mit dem Inhalt des äußeren Artikels verwandt sind. Beispielsweise kann ein Blogeintrag auf einer Website, der von Benutzern übermittelte Kommentare akzeptiert, die Kommentare als Artikelelemente darstellen, die im Artikelelement für den Blogeintrag verschachtelt sind.
In HTML5 sind Benutzerkommentare, der eigentliche Artikel, Forenbeiträge und sogar interaktive Widgets und Gadgets alle Artikel. Die Definition ist so weit gefasst, dass sie nutzlos ist - Semantiken sollen Bedeutung verleihen, aber die Verwendung eines Sammelbegriffs für eine so große Vielfalt von Elementen macht das Element bedeutungslos.
Dies ist ein Beispiel, in dem wir die Spezifikation gegabelt haben - ein paar Leute folgen der Spezifikation korrekt und machen fast alles zu einem Artikel (Blog-Post-Zusammenfassungen, Blog-Posts, Kommentare, Widgets, Forumsbeiträge, etc.), während andere ihn nur behalten für den Hauptartikel auf einer Seite, der nur ein Teil seiner breiten Definition ist. Sie können denken, dass es egal ist, und zu einem großen Teil haben Sie recht. Aber denken Sie an all diese Lesedienste, die nur den Hauptinhalt der Seite parsen sollen. Welcher Implementierung der Spezifikation sollten sie folgen? Sollten sie dem folgen, was die Spezifikation eigentlich sagt, oder sollten sie der allgemeinen Community-Implementierung folgen, wo es normalerweise nur einen kanonischen "Artikel" auf einer Seite gibt?
Dies ist eine verpasste Gelegenheit, und was passiert, wenn die Spezifikation nicht spezifiziert wird , und der Editor und, um fair zu sein, die Gemeinschaft, kommuniziert nicht, was die Spezifikation tatsächlich sagt.
Stellen Sie sich vor, der Artikel wurde nicht auch für Kommentare verwendet. Stellen Sie sich vor, wenn Kommentare zum Beispiel ihr eigenes Element bekommen und die Adoption weit verbreitet ist. Browser-Hersteller könnten eine "Stumm-Kommentar" -Funktion hinzufügen, die Kommentare auf Webseiten leicht verstecken (oder anderweitig parsen) könnte. Aber Hickson hat ausdrücklich eine Anfrage nach einem Kommentarelement abgelehnt . In HTML5 sind die Artikel ganz unten.
Nebenbei ist ein anderes Element, das nirgendwo in Hicksons Klassennamenforschung erscheint und eine sehr merkwürdige Definition bekommt:
Das side-Element stellt einen Abschnitt einer Seite dar, der aus Inhalt besteht, der tangential mit dem Inhalt um das Element side verknüpft ist und der getrennt von diesem Inhalt betrachtet werden kann. Solche Abschnitte werden oft als Seitenleisten in gedruckter Typografie dargestellt.
Das Element kann für typografische Effekte wie Pull-Anführungszeichen oder Seitenleisten, für Werbung, für Gruppen von Navigationselementen und für andere Inhalte verwendet werden, die vom Hauptinhalt der Seite getrennt betrachtet werden.
Wer weiß, warum sollte neben Pull-Anführungszeichen, Sidebars, Werbung und Gruppen von Navigationselementen auch neue Abschnitte in der Dokumentgliederung erstellt werden. Dies bedeutet, dass Pull-Anführungszeichen ihren eigenen Aufzählungszeichen in der Dokumentumrisslinie erhalten, was, sagen wir mal, "ungerade" aussieht. Wiederum hat und wird seine willkürliche Verwendung durch gut gemeinte Webdesigner viele defekte Dokumentumrisse erzeugen.
Das Nav-Element scheint das selbsterklärendste der Schnittelemente zu sein, und glücklicherweise ist die Definition nicht über das Brechen hinaus ausgedehnt worden.
Das Element nav stellt einen Abschnitt einer Seite dar, die mit anderen Seiten oder Teilen der Seite verknüpft ist: ein Abschnitt mit Navigationslinks.
Das ist in Ordnung und könnte theoretische Erreichbarkeitsvorteile haben (ein Benutzeragent könnte die Nav-Links überspringen oder überspringen - sie tun es nicht, aber sie könnten es tun).
Das Problem ist, dass wir im Sinne von "Vereinfachung des Authoring" und Ersetzen von div durch das nav-Element das Navigations-Styling für eine andere Untergruppe von Nutzern in die Luft jagen. Benutzer von IE6-8 mit deaktiviertem JavaScript (Yahoo Forschung schlägt vor 1-2% aller Nutzer haben JavaScript deaktiviert ) sind Opfer dieses Problems. Wenn JavaScript deaktiviert ist, funktioniert das JavaScript-basierte HTML5-Shim, das dem IE6-8 hilft, HTML5-Elemente zu verstehen, nicht, sodass der Browser keine HTML5-Elemente formatiert. Dies betrifft möglicherweise nur eine kleine Anzahl von Benutzern, aber warum sind sie überhaupt betroffen?
Die Kopf- und Fußzeilenelemente sind ein klassischer Fall, in dem allgemeine Begriffe verwendet werden und sie sehr unterschiedlich verwendet werden.
Die Spezifikation besagt, dass keines dieser Elemente neue Abschnitte in der Gliederung des Dokuments erstellt, obwohl sie oft als gleichwertig mit Abschnitt, Navigation, Artikel und auf der Seite dargestellt werden. Tatsächlich tun sie überhaupt nichts. Sie sind nur enthalten, um Bereiche eines bestimmten Abschnitts in der Dokumentgliederung abzugrenzen.
Hier ist, was die Spezifikation über Header sagt: Das Header-Element repräsentiert eine Gruppe von Einführungs-oder Navigationshilfen.
Hinweis: Ein Header-Element soll normalerweise die Überschrift des Abschnitts enthalten (ein h1-h6-Element oder ein hgroup-Element), dies ist jedoch nicht erforderlich. Das Kopfzeilenelement kann auch verwendet werden, um das Inhaltsverzeichnis eines Abschnitts, ein Suchformular oder andere relevante Logos zu umbrechen.
und Fußzeile: Das Fußzeilenelement stellt eine Fußzeile für den nächsten Vorfahrabschnitt dar, der den Inhalt oder das Schnittwurzelelement abschneidet. Eine Fußzeile enthält typischerweise Informationen über ihren Abschnitt, z. B. wer sie geschrieben hat, Links zu verwandten Dokumenten, Copyright-Daten und dergleichen.
In HTML5 ist das body-Element tatsächlich das root-Abschnittselement, also soll eine übergreifende Kopf- und Fußzeile den root-body-Abschnitt beschreiben. Jeder Abschnitt kann einen Header und / oder eine Fußzeile haben - sie sind nicht nur für Gesamtkopf- und Fußzeilen gedacht, wie wir vielleicht angenommen haben. Einzelne Kommentare können beispielsweise jeweils eine Kopf- und Fußzeile haben. Wie bereits erwähnt, gibt die Spezifikation tatsächlich ein Beispiel für eine Fußzeile, die in einem Kommentar über dem tatsächlichen Kommentarinhalt verwendet wird. Das ist richtig, in HTML5-Kommentaren sind Artikel, und sie können eine Fußzeile für eine Kopfzeile haben, und das ist in der tatsächlichen Spezifikation. Möchtest du ein Fußzeilenelement für die Kopfzeile deiner Kommentare? Nein? Nun, du hast einen.
Auch hier verwendet HTML5 häufig verwendete Begriffe und verwendet sie auf eine Weise, die für den gewöhnlichen Webautor nicht erkennbar ist.
Aber es gibt etwas, das wir in der HTML-Implementierung der Sektionierung nicht untersucht haben. Hast du es entdeckt? Wir haben die Schnittelemente, aber wir haben kein generisches h-Element. Keine Sorge, die Lösung ist in der Spezifikation :
Abschnitte können Überschriften mit beliebigem Rang enthalten, aber Autoren wird dringend empfohlen, entweder nur h1-Elemente zu verwenden oder Elemente mit dem entsprechenden Rang für die Verschachtelungsebene des Abschnitts zu verwenden.
HTML5 möchte rückwärtskompatibel sein, daher entschied sich die WHATWG, kein h-Element einzuführen (trotz der Einführung einer Menge neuer Schnittelemente) und stattdessen das h1-Element als generisches h-Element zu verwenden. Verwenden Sie h1 überall und lassen Sie den HTML5-Gliederungsalgorithmus sein wahres Niveau bestimmen ... so lautet die Theorie.
Dies ist eine schreckliche Idee aus mehreren Gründen, die beiden wichtigsten sind Zugänglichkeit und Styling.
Die Verwendung von h1 überall ist sehr schlecht für die Zugänglichkeit. Blinde Nutzer verlassen sich stark auf die Überschriftenstruktur einer Website. Es ist wichtig, dass wir alle daran erinnert werden, wie wichtig die Struktur der Überschrift für die Zugänglichkeit ist. Zum Beispiel, ein Dezember 2008 Umfrage unter über 1000 Screenreader-Nutzern durchgeführt von WebAIM festgestellt, dass 76% der blinden und sehbehinderten Nutzer "immer oder oft" nach Rubriken navigierten, wenn sie verfügbar waren. Und eine Umfrage vom Mai 2012 ergab, dass 82,1% der Überschriften "sehr nützlich" oder "etwas nützlich" beim Navigieren auf einer Webseite waren. (Das ist gut, praktische Forschung, also nehmen Sie zur Kenntnis.)
Mit h1s überall werden Websites für blinde Nutzer schwieriger zu navigieren sein. Theoretisch würden Screenreader stattdessen den HTML-Gliederungsalgorithmus verwenden und anhand der Dokumentgliederung navigieren, aber angesichts der Art und Weise, auf die Autoren angewiesen wurden, Schnittelemente zu implementieren, sind Umrisse ein Durcheinander und der Versuch, Dokumentumrisse zu navigieren, die nicht berücksichtigt wurden für blinde Nutzer noch schlimmer.
Die HTML5-Spezifikation bietet einen Ausweg: Halten Sie die entsprechenden h1-h6-Stufen ein, um die Rückwärtskompatibilität aufrechtzuerhalten. Aber jetzt behalten wir zwei Dokumentumrisse in dem einen Dokument bei, und angesichts der Probleme, die die Autoren hatten, wenn sie überhaupt die Dokumentenumriß betrachteten, die Wahrscheinlichkeit, daß jemand sowohl eine logische h1-h6-Gliederung als auch eine logische richtig beibehält HTML5-Gliederung scheint im besten Fall entfernt zu sein.
Aber es wird schlimmer. Nehmen wir an, wir wollen mit einem reinen HTML5-Umriss arbeiten, und wir verwenden h1s überall. Denken Sie daran, dass in der HTML5-Spezifikation das h1 nur ein generisches h-Element ist; Sein tatsächliches Niveau wird dadurch bestimmt, wie tief es in Schnittelemente verschachtelt ist.
Wie gestalten wir es? Nun, wir könnten allen h1-Elementen Klassennamen hinzufügen, damit wir sie herausgreifen können, aber das widerspricht dem erklärten HTML5-Ziel, das Authoring zu vereinfachen; und wir können auch bei h1-h6 bleiben (die alle als generische h-Elemente in einer HTML5-Gliederung behandelt werden).
Wir könnten versuchen, sie durch die Kaskade zu stylen, aber das wird schnell absurd Nicole Sullivan hat darauf hingewiesen . Tatsächlich beginnt "absurd" es nur zu beschreiben. Wenn Sie die möglichen Kombinationen von Abschnitt, Artikel, nav und beiseite betrachten, und Sie möchten einen generischen Stil für eine Überschrift erstellen, die beispielsweise fünf Ebenen tief ist (dh das Äquivalent von h5), müssten Sie Stile für alle schreiben mögliche Kombinationen, die bekommen absolut lächerlich . Hier ist der generische Stil für ein h3-Element:
article aside nav h1, article aside section h1,article nav aside h1, article nav section h1,article section aside h1, article section nav h1, article section section h1,aside article nav h1, aside article section h1,aside nav article h1, aside nav section h1,aside section article h1, aside section nav h1, aside section section h1,nav article aside h1, nav article section h1,nav aside article h1, nav aside section h1,nav section article h1, nav section aside h1, nav section section h1,section article aside h1, section article nav h1, section article section h1,section aside article h1, section aside nav h1, section aside section h1,section nav article h1, section nav aside h1, section nav section h1,section section article h1, section section aside h1, section section nav h1, section section section h1 {font-size: 1.00em;}Das ist es, was uns die Strukturelemente von HTML geben. Was für ein Chaos.
Hungrig auf mehr? Teil drei dieses Artikels ist jetzt verfügbar und Lukes Buch "Die Wahrheit über HTML5" ist für eine begrenzte Zeit über unsere Schwesterseite verfügbar MightyDeals.com zu einem unglaublichen Preis von 50%.
Verwenden Sie Artikelelemente mehrfach in einem Dokument? Sind Abschnitte nützlich oder sollten wir bei divs bleiben? Lass uns deine Gedanken in den Kommentaren wissen.
Vorgestelltes Bild / Thumbnail, verwendet Strukturbild über Shutterstock.