Elementy strukturalne HTML — artykuł, sekcja, nav i aside — są na pierwszy rzut oka jednymi z najłatwiejszych do zrozumienia i zaimplementowania części specyfikacji HTML5. Jednak w rzeczywistości są jednymi z najgorzej określonych, najgorzej zrozumianych i najgorzej zaimplementowanych części HTML5.
Są tworzone arbitralnie; stanowią próbę wprowadzenia zupełnie nowego sposobu strukturyzacji stron internetowych; naruszają zasady projektowania języka HTML; szkodzą dostępności dla niektórych użytkowników; nie należy ich używać.
Tak, ostro krytykuję tę konkretną część HTML5, ale proszę nie zakładać, że jestem „anty-HTML5”. Napisałem książkę o HTML5Uwielbiam otwartą sieć, uwielbiam Dobry standardy sieciowe i uwielbiam fakt, że po dekadzie stagnacji, innowacje w technologiach sieciowych następują teraz z absolutnie zawrotną prędkością. To jednak nie oznacza, że musimy akceptować wszystko, co nam dają. Nie musimy jeść wszystkiego, co jest na talerzu HTML5, nawet jeśli uważamy, że niektóre części dania są naprawdę smaczne. Niektóre części prawdopodobnie trzeba odesłać szefowi kuchni.
Istnieją dobre i złe części tej całkiem ogromnej specyfikacji HTML5, a my pomyślimy krytycznie o jednej bardzo konkretnej części specyfikacji: sekcjach lub elementach „strukturalnych”, które wprowadza HTML5. Załóżmy więc nasze kapelusze detektywów i przyjrzyjmy się, skąd naprawdę wzięły się te nowe elementy, jak mają być używane i jak my, społeczność projektantów stron internetowych, fundamentalnie je źle zrozumieliśmy, zasadniczo rozwidlając specyfikację. Zakwestionujemy samą podstawę tych elementów i po drodze obalimy kilka mitów na ich temat.
Skąd wzięły się elementy strukturalne HTML5?
Rozprawmy się z jednym mitem, który powtarzano do znudzenia na temat tych elementów: ideą, że opierają się one na badaniach nad tym, jak my, społeczność internetowa, oznaczaliśmy nasze dokumenty. To mit powtarzany w książkach, blogach i na wykładach od lat i po prostu nie jest prawdą. Skąd wiem? Zapytałem.
Kiedy badałem pochodzenie tych elementów, postanowiłem zapytać redaktora specyfikacji HTML5, Iana Hicksona, skąd się wzięły te elementy. Odpowiedział:
Przyjrzyjmy się temu bliżej: po pierwsze, Hickson i członkowie WHATWG dodali następujące elementy zanim przeprowadzono jakiekolwiek badania. Możesz zanurzyć się w archiwach listy mailingowej WHATWG (na szczęście publicznej) i odkryć wczesne dyskusje na temat tych elementów. Na przykład możesz zobaczyć Hicksona omawiającego je w listopadzie 2004 r., z komentarzami takimi jak: ten:
Wygląda na to, że tak właśnie powstała strukturalna semantyka HTML5: jeden człowiek, jedna tablica i pewne uwagi od innych członków WHATWG. (Grupa robocza WHATWG, czyli Web Hypertext Application Technology Working Group, została utworzona przez przedstawicieli przeglądarek w odpowiedzi na porzucenie HTML przez W3C na rzecz utopijnego ideału XHTML 2.0).
Elementy używane w milionach dokumentów, które omawialiśmy i debatowaliśmy, zostały, jak się wydaje, stworzone arbitralnie, na kaprys edytora HTML5 w 2004 roku. (I spotkały się z wnikliwa krytyka i niestety trafne przewidywania prawie natychmiast.)
Kolektywne tyłki
To prowadzi nas do drugiego punktu. W grudniu 2005 r. — mniej więcej rok temu Po wymyślając te nowe elementy — Hickson (pracownik Google) przeprowadził pewne badania nad tym, jak tworzone są dokumenty, korzystając z ogromnej bazy danych dokumentów Google. Badania te były „analizą próbki nieco ponad miliarda dokumentów, wyodrębniając informacje o popularnych nazwach klas, elementach, atrybutach i powiązanych metadanych”. Identyfikatory nie zostały uwzględnione w badaniach. Wyniki zostały opublikowane przez Google jako Statystyki tworzenia stron internetowych (2005).
Krytyczną częścią badań, jeśli chodzi o elementy strukturalne HTML, były wyniki zajęćktóry, mimo że wykorzystał próbkę, w której około 900 milionów z miliarda dokumentów najwyraźniej nie zawierało żadnych klas, zawierał kilka powszechnych klas, których na pewno używaliśmy już w naszych projektach: stopka, menu, tytuł, mały, tekst, zawartość, nagłówek, nawigacja, prawa autorskie, przycisk, główny i tak dalej.
Następnie Hickson przedstawia swoją interpretację danych, sugerując, że klasy te „w rzeczywistości [map] bardzo dobrze do elementów, które są proponowane w HTML5 i zawiera tabelę porównującą wyniki badań i nowe elementy w HTML5: stopka klasa jest w badaniach, stopka element jest w HTML5; nagłówek klasa jest w badaniach, nagłówek element jest w HTML5; klasy tekst, treść, główny, ciało są w trakcie badań i, eee… artykuł jest w HTML5, co, jak zaraz zobaczymy, w ogóle nie pasuje; Sekcja nie występuje wcale, co również jest warte odnotowania.
Biorąc to za dobrą monetę, to wszystko jest wystarczająco rozsądne. Ja używam stopki, ty używasz stopki, stopka jest w HTML5. Jaki jest problem?
Problem polega na tym, że jeśli przeczytasz faktyczną wersję Specyfikacja HTML5elementy w HTML5 są zdefiniowane w sposób, który niewiele ma wspólnego z tym, jak tradycyjnie ich używaliśmy.
Z jednej strony Hickson wprowadził zupełnie nową koncepcję strukturyzowania strony internetowej w HTML5, elementy sekcyjneZ drugiej strony Hickson porównuje swoje elementy sekcji HTML5 do klas używanych w praktyce, nie rozumiejąc, do czego te klasy są faktycznie używane. Klasycznym przykładem jest „header”, którego większość z nas użyłaby dla obszaru na górze strony, ale specyfikacja HTML5 sugeruje, że można go użyć dla nagłówek z każdy komentarz na stronieNaprawdę. To, że klasy w badaniach i elementy w HTML5 mają tę samą nazwę, nie oznacza, że ich zastosowania są takie same.
Teraz, gdyby jasno zakomunikowano, że nowe elementy zostały wprowadzone z nowym celem i jasnym uzasadnieniem, to nie byłoby tak źle. Ale nie to nam powiedziano.
Oto Hickson w 2009 rokuodpowiadając na pytanie o cel sekcji, nawigacji, artykułu, na marginesie i innych:
Niestety, wydaje się, że jest to przypadek, w którym edytor HTML5, pomimo całej swojej dobrej pracy przy układaniu specyfikacji, zapomniał (bądźmy hojni) dlaczego dodał te elementy do tego, co w istocie jest jego specyfikacją. Być może to różnica czasu między 2009 a 2004 rokiem, kto wie. Ale wiemy jedno: elementy sekcji HTML5 nie zostały dodane, aby wypełnić „najczęściej występujące prośby programistów stron internetowych”. Skąd to wiemy? Możemy po prostu spojrzeć na listę i zobaczyć, że najbardziej podstawowe dodane elementy, takie jak element sekcji (oraz powiązane elementy artykułu i aside), w ogóle nie pojawiają się w badaniu wspólnych atrybutów klas.
Choć Hickson mógł zapomnieć, po co dodano te elementy, na szczęście nadal możemy przeczytać specyfikację dokumentującą ich przeznaczenie.
Ale co się stanie, gdy powiesz projektantom stron internetowych i programistom, żeby się nie martwili, że te elementy po prostu zastąpią to, co już robisz, a następnie określisz te elementy w sposób, który jest jak najbardziej pewny? nie co robili projektanci i programiści stron internetowych? Wysłałeś ich w podróż w jedną stronę do miasta zamieszania.
To najgorszy rodzaj badań: leniwa interpretacja danych, która ma uzasadnić decyzje, które już zostały podjęte. Często powtarzaną zasadą projektowania HTML5 jest „wybrukować ścieżki dla krów‘, czyli ‘Jeśli jakaś praktyka jest już szeroko rozpowszechniona wśród autorów, rozważ jej przyjęcie, zamiast jej zabraniać lub wymyślać coś nowego.’ I tak samo wygląda sprawa z tymi nowymi elementami strukturalnymi: sekcją, artykułem, nawigacją i na uboczu (oraz nagłówkiem i stopką) — czyż nie jest to po prostu ‘brukowanie ścieżek dla krów’?
Takie wrażenie odniosło wielu z nas, bo tak nam powiedziano.
W rzeczywistości, prawie pięć lat temu, kiedy po raz pierwszy otrzymaliśmy podgląd HTML5wyglądało na to, że te elementy mogłyby po prostu zastąpić „niesemantyczne” divy, których byliśmy przyzwyczajeni używać. Co było div id=”nagłówek” na górze strony może teraz stać się nagłówek; div id=”stopka” teraz może po prostu stać się stopkaa nasz div mógłby być po prostu artykułem. Proste, prawda?
Rozdzieliliśmy specyfikację
Niestety, pomimo zrobienia tego, co nam powiedziano (tj. po prostu zamieniliśmy jeden na drugi), w rzeczywistości zaimplementowaliśmy te elementy w sposób, który nie jest odzwierciedlony w specyfikacji HTML5. To znaczy, jeśli chodzi o strukturę HTML5, to w zasadzie rozwidliliśmy specyfikację. Obecnie istnieją dwie metody struktury HTML5 — interpretacja społecznościowa, która jest odzwierciedlona w artykule A List Apart z 2007 r. (i niezliczonych innych); oraz faktyczna specyfikacja HTML5, która wprowadza zupełnie nowy sposób strukturyzacji strony internetowej zwany obrysem.
To jest sprzeczność w sercu strukturalnej semantyki HTML. Z jednej strony mamy edytora, który mówi nam, że nowe elementy są oparte na badaniach dotyczących tego, co już robiliśmy, a zatem mają na celu jedynie ułatwienie tworzenia; z drugiej strony mamy to, co edytor faktycznie stworzył w specyfikacji HTML5, czyli nowy sposób strukturyzacji strony internetowej w sposób, który generuje zarys dokumentu za pomocą elementy sekcyjne.
Trzeba było dokonać jasnego wyboru. Zerwać z zasadami projektowania HTML5 i wprowadzić coś nowego, czy po prostu postępować zgodnie z prawdziwymi praktykami autorskimi i określić elementy w sposób odzwierciedlający praktykę projektowania stron internetowych. Hickson próbował zrobić to pierwsze i nazwać to drugim, a teraz mamy jeden wielki bałagan na rękach.
Głodny więcej? Część druga tego artykułu jest już dostępna, a książka Luke’a „The Truth About HTML5” jest dostępna przez ograniczony czas na naszej siostrzanej stronie Potężne Dealerzy ze zniżką 50%.
Czy pracujesz ze strukturalnymi elementami HTML5? Czy uważasz je za pomocne, czy za przeszkodę? Daj nam znać w komentarzach.
Wyróżniony obraz/miniaturka, zastosowania obraz struktury poprzez Shutterstock.
