Strukturelle Elemente von HTML - Artikel, Abschnitt, nav und beiseite - sind auf den ersten Blick einige der einfachsten Teile der HTML5-Spezifikation zu verstehen und zu implementieren. Sie sind jedoch einige der am schlechtesten spezifizierten, schlecht verstandenen und schlecht implementierten Teile von HTML5.
Willkürlich erstellt; sie versuchen, eine völlig neue Art der Strukturierung von Webseiten einzuführen; Sie verletzen die eigenen Designprinzipien von HTML; sie beeinträchtigen die Zugänglichkeit für einige Benutzer; und du solltest sie nicht benutzen.
Ja, ich komme gegen diesen speziellen Teil von HTML5, aber bitte gehen Sie nicht davon aus, dass ich "Anti-HTML5" bin. Ich habe ein Buch über HTML5 geschrieben Ich liebe das offene Web, ich liebe gute Webstandards, und ich liebe die Tatsache, dass nach einer Dekade der Stagnation die Innovation in Webtechnologien jetzt in einer rasenden Geschwindigkeit stattfindet. Das bedeutet jedoch nicht, dass wir alles akzeptieren müssen, was wir bekommen. Wir müssen nicht alles auf dem HTML5-Teller essen, auch wenn wir Teile des Gerichts eher schmackhaft finden. Einige Teile müssen wahrscheinlich an den Koch zurück geschickt werden.
Es gibt gute und schlechte Teile der recht umfangreichen HTML5-Spezifikation, und wir werden uns kritisch mit einem sehr spezifischen Teil der Spezifikation befassen: mit den Schnitt- oder Strukturelementen, die HTML5 einführt. Lassen Sie uns also unsere Detektivhüte aufsetzen und schauen, woher diese neuen Elemente wirklich kommen, wie sie verwendet werden sollen und wie wir, die Webdesign-Community, sie grundlegend falsch verstanden haben, im Wesentlichen auf die Spezifikation zu verzichten. Wir werden die Basis für diese Elemente in Frage stellen und einige Mythen darüber auf den Weg bringen.
Lassen Sie uns einen Mythos aufbrechen, der sich über diese Elemente im Nachhinein wiederholt hat: die Idee, dass sie auf der Erforschung basieren, wie wir, die Web-Community, unsere Dokumente markiert haben. Es ist ein Mythos, der seit Jahren in Büchern, Blogs und Vorträgen wiederholt wird, und das ist einfach nicht wahr. Wie soll ich wissen? Ich fragte.
Als ich die Ursprünge dieser Elemente erforschte, entschied ich mich, den Herausgeber der HTML5-Spezifikation, Ian Hickson, zu fragen, woher diese Elemente kamen. Er antwortete:
Ich und andere WHATWG-Mitwirkende [hinzugefügt], [in] 2004ish, weil sie offensichtliche Elemente waren, die hinzugefügt werden mussten, nachdem man gesehen hatte, wie Autoren HTML4 verwendeten. Wir haben später (Ende 2005, Anfang 2006) objektive Nachforschungen angestellt, um herauszufinden, was die Top-Ten-HTML-Klassen waren, und es stellte sich heraus, dass sie genau den Elementen entsprachen, die wir hinzugefügt hatten, was praktisch war.
Lassen Sie uns das aufschlüsseln: Zuerst fügten Hickson und die WHATWG-Mitglieder diese Elemente hinzu, bevor irgendwelche Untersuchungen durchgeführt wurden . Sie können in die (hoffentlich öffentlichen) WHATWG-Mailinglisten-Archive eintauchen und frühe Diskussionen über diese Elemente für sich entdecken. Zum Beispiel können Sie sehen, Hickson diskutieren sie im November 2004 mit Kommentaren wie dieses :
Ja, ich beabsichtige, Dinge wie [semantische Elemente] in Web Apps zu integrieren. Das Whiteboard in meinem Büro hat derzeit eine Liste von Elementen unter der Überschrift "HTML5 BLOCK LEVEL ELEMENTS", und ich versuche herauszufinden, wie man sie gut arbeiten lässt (die betreffenden Elemente werden derzeit im Entwurf erwähnt, aber der Entwurf behandelt Header überhaupt nicht gut). Ich habe noch kein Inline-Markup angeschaut, aber das ist auch auf den Karten.
Das ist, wie es scheint, wie die HTML5-Struktur-Semantik entstanden ist: ein Mann, ein Whiteboard und etwas Input von anderen WHATWG-Mitgliedern. (Die Arbeitsgruppe WHATWG oder Web Hypertext Application Technology wurde von Vertretern des Browsers als Reaktion auf die Aufgabe von HTML für das utopische Ideal von XHTML 2.0 von W3C gegründet).
Die Elemente, die von Millionen von Dokumenten verwendet werden, die wir diskutiert und diskutiert haben, wurden scheinbar willkürlich aus dem HTML5-Editor von 2004 erstellt. (Und wurden mit einem scharfsinnige Kritik und einige sehr genaue Vorhersagen fast sofort.)
Tantekek hat schon lange darauf bestanden, neue Formate im Mikroformat-Kontext zu erforschen und zu spezifizieren, und schließlich werden auch die WHATWG-Spezifikationen mit tatsächlichen Daten gestaltet, anstatt dass wir aus unseren kollektiven Hintergründen etwas herausholen. - Ian Hickson
Das bringt uns zum zweiten Punkt. Im Dezember 2005 - etwa ein Jahr nach der Einführung dieser neuen Elemente - hat Hickson (ein Google-Mitarbeiter) untersucht, wie Dokumente mithilfe der umfangreichen Google-Datenbank erstellt wurden. Die Forschung bestand aus einer Analyse einer Stichprobe von etwas über einer Milliarde Dokumenten, die Informationen über beliebte Klassennamen, Elemente, Attribute und zugehörige Metadaten extrahierte. IDs wurden nicht in die Untersuchung einbezogen. Die Ergebnisse wurden von Google als veröffentlicht Web Authoring Statistik (2005) .
Der kritische Teil der Forschung, soweit es die strukturellen Elemente von HTML betraf, waren die Klassenergebnisse , die trotz der Verwendung einer Stichprobe, in der ~ 900 Millionen der 1 Milliarde Dokumente anscheinend überhaupt keine Klassen hatten, einige gemeinsame Klassen enthielten, die wir sicher schon alle in unseren Projekten verwendet haben: Fußzeile, Menü, Titel, klein, Text , Inhalt, Header, Nav, Copyright, Button, Haupt, und so weiter.
Hickson liefert dann einen Spin zu den Daten, was darauf hindeutet, dass diese Klassen tatsächlich sehr gut mit den Elementen übereinstimmen, die in HTML5 vorgeschlagen werden, und bietet eine Tabelle, die die Ergebnisse der Forschung und die neuen Elemente in HTML5 vergleicht: eine Fußzeile Klasse ist in der Forschung, ein Fußzeilenelement ist in HTML5; eine Header- Klasse ist in der Forschung, ein Header- Element ist in HTML5; Die Klassen Text , Inhalt , Haupt , Körper sind in der Forschung, und, äh ... Artikel ist in HTML5, die, wie wir sehen werden, überhaupt nicht zusammenpassen; Abschnitt ist überhaupt nicht zu finden, was auch erwähnenswert ist.
Auf den Nennwert genommen, ist das alles vernünftig genug. Ich benutze Fußzeile, Sie verwenden Fußzeile, Fußzeile ist in HTML5. Was ist das Problem?
Das Problem ist, wenn Sie das tatsächliche lesen HTML5-Spezifikation Die Elemente in HTML5 sind so definiert, dass sie wenig mit der traditionellen Verwendung von Elementen zu tun haben.
Auf der einen Seite hat Hickson ein völlig neues Konzept zur Strukturierung einer Webseite in HTML5 mit Schnittelementen eingeführt . Auf der anderen Seite vergleicht Hickson seine HTML5-Schnittelemente mit Klassen, die in der Wildnis verwendet werden, ohne zu wissen, wofür diese Klassen tatsächlich verwendet wurden. Ein klassisches Beispiel ist "header", das die meisten von uns für den Bereich oben auf der Seite verwenden würden, aber die HTML5-Spezifikation schlägt vor, dass Sie sie als Überschrift für jeden Kommentar auf einer Seite verwenden können . Ja wirklich. Nur weil Klassen in der Forschung und Elemente in HTML5 den gleichen Namen haben, heißt das nicht, dass ihre Verwendung die gleiche ist.
Wenn nun klar kommuniziert wird, dass neue Elemente mit einem neuen Zweck und einer klaren Begründung eingeführt werden, dann wäre das nicht so schlimm. Aber das wurde uns nicht gesagt.
Hier ist Hickson im Jahr 2009 , auf eine Frage über den Zweck von Abschnitt, nav, Artikel, beiseite und andere antworten:
Sie füllen mehr oder weniger die häufigsten Anfragen von Webentwicklern basierend auf den am häufigsten verwendeten Attributwerten der Klasse = "". Ihr Hauptzweck ist es, Authoring und Styling zu vereinfachen.
Leider scheint dies ein Fall zu sein, in dem der HTML5-Editor, trotz all seiner guten Arbeit beim Zusammenstellen der Spezifikation, vergessen hat (warum sollte er großzügig sein), warum er diese Elemente zu dem hinzufügt, was im Wesentlichen seine Spezifikation ist. Vielleicht ist es der Zeitunterschied zwischen 2009 und 2004, wer weiß. Aber wir wissen das: Die HTML5-Schnittelemente wurden nicht hinzugefügt, um die häufigsten Anfragen von Webentwicklern überhaupt zu erfüllen. Woher wissen wir? Wir können uns einfach die Liste anschauen und sehen, dass die elementarsten Elemente wie das Element section (und die verwandten Artikel und side-Elemente) nicht in der allgemeinen Klassenattribut-Suche erscheinen.
Obwohl Hickson vielleicht vergessen hat, warum diese Elemente hinzugefügt wurden, können wir immer noch dankbar die Spezifikation lesen, die ihren Zweck dokumentiert.
Aber was passiert, wenn Sie Webdesignern und Entwicklern sagen, dass sie sich keine Sorgen machen müssen, diese Elemente ersetzen nur das, was Sie bereits tun, und dann spezifizieren Sie diese Elemente auf eine Art und Weise, die Webdesigner und -Entwickler wirklich nicht machen. Du legst sie auf eine Reise in die verwirrende Stadt.
Dies ist die schlimmste Art von Forschung: eine faule Interpretation von Daten, die zur Begründung bereits getroffener Entscheidungen verwendet werden. Ein oft wiederholtes Designprinzip von HTML5 ist ' pflastern Sie die Kuhpfade "Das heißt" Wenn eine Praxis unter Autoren bereits weit verbreitet ist, sollten Sie sie übernehmen, anstatt sie zu verbieten oder etwas Neues zu erfinden. Und so scheint es mit diesen neuen strukturellen Elementen: Abschnitt, Artikel, nav und beiseite (und Kopf- und Fußzeile) - sicher sind diese nur "Pflasterung der Kuhwege"?
Das ist der Eindruck, den viele von uns haben, denn das wurde uns gesagt.
In der Tat, vor fast fünf Jahren, als wir zum ersten Mal ein Vorschau von HTML5 Es sah so aus, als könnten diese Elemente einfach die 'unsemantischen' Divs ersetzen, die wir gewohnt waren. Was div id = "header" am Anfang der Seite war, könnte nun einfach header werden ; div id = "footer" könnte jetzt Fußzeile werden , und unser div könnte nur Artikel sein. Einfach, oder?
Leider haben wir, obwohl wir das getan haben, was uns gesagt wurde (dh tausche einfach eines gegen das andere aus), diese Elemente auf eine Weise implementiert, die sich nicht in der HTML5-Spezifikation widerspiegelt. Das heißt, wenn es um HTML5-Struktur geht, haben wir im Wesentlichen die Spezifikation gegabelt. Es gibt derzeit zwei Methoden der HTML5-Struktur - die Community-Interpretation, die sich im Artikel A List Apart 2007 (und unzähligen anderen) widerspiegelt; und die eigentliche HTML5-Spezifikation, die eine ganz neue Art der Strukturierung einer Webseite namens Outlining einführt.
Dies ist der Widerspruch im Kern der strukturellen Semantik von HTML. Auf der einen Seite haben wir den Herausgeber, der uns erzählt, dass die neuen Elemente auf der Forschung über das, was wir bereits getan haben, basieren, und sollen daher das Authoring ein bisschen leichter machen; und auf der anderen Seite haben wir, was der Editor tatsächlich in der HTML5-Spezifikation erstellt hat, was eine neue Art ist, eine Webseite so zu strukturieren, dass eine Dokumentengliederung mit Hilfe von Schnittelementen erzeugt wird .
Es gab eine klare Entscheidung, die hier getroffen werden sollte. Brechen Sie mit den HTML5-Designprinzipien auf und führen Sie etwas Neues ein, oder folgen Sie einfach den Authoring-Praktiken und spezifizieren Sie Elemente auf eine Weise, die die Webdesign-Praxis widerspiegelt. Hickson hat versucht, das erstere zu tun und es das letzte zu nennen, und wir haben jetzt ein großes Durcheinander in unseren Händen.
Hungrig auf mehr? Teil zwei 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%.
Arbeitest du mit HTML5 Strukturelementen? Finden Sie sie hilfreich oder ein Hindernis? Lassen Sie es uns in den Kommentaren wissen.
Vorgestelltes Bild / Thumbnail, verwendet Strukturbild über Shutterstock.