Elementy konstrukcyjne HTML - artykuł, sekcja, nawigacja i na bok - to na pierwszy rzut oka niektóre z najłatwiejszych części specyfikacji HTML5 do zrozumienia i implementacji. Jednak w rzeczywistości są to jedne z najsłabiej sprecyzowanych, źle zrozumianych i źle zaimplementowanych części HTML5.
Utworzony arbitralnie; próbują wprowadzić zupełnie nowy sposób konstruowania stron internetowych; naruszają własne zasady projektowania HTML; zakłócają dostęp dla niektórych użytkowników; i nie powinieneś ich używać.
Tak, wychodzę z bronią przeciwko tej konkretnej części HTML5, ale proszę nie zakładaj, że jestem "anty-HTML5". Napisałem książkę o HTML5 , Uwielbiam otwartą sieć, uwielbiam dobre standardy sieciowe i uwielbiam fakt, że po dziesięciu latach stagnacji innowacje w technologiach internetowych zachodzą teraz z niesamowitą prędkością. To jednak nie oznacza, że musimy zaakceptować wszystko, co nam dane. Nie musimy jeść wszystkiego na talerzu HTML5, nawet jeśli uważamy, że części potrawy są naprawdę smaczne. Niektóre części prawdopodobnie muszą zostać odesłane do szefa kuchni.
Istnieją dobre i złe strony do całkiem olbrzymiej specyfikacji HTML5 i będziemy krytycznie myśleć o jednej bardzo specyficznej części specyfikacji: elementach podziału lub elementach strukturalnych, które wprowadza HTML5. Załóżmy więc nasze czapki detektywistyczne i zobaczmy, skąd pochodzą te nowe elementy, jak powinny one być używane i jak my, społeczność projektantów stron internetowych, zasadniczo ich błędnie zrozumieliśmy, zasadniczo poszerzając specyfikację. Podejmiemy podwaliny pod te elementy i po drodze rozwiążemy kilka mitów na ich temat.
Zrzućmy jeden mit, który został powtórzony na temat tych elementów: pomysł, że są one oparte na badaniach nad tym, w jaki sposób my, społeczność internetowa, oznaczamy nasze dokumenty. To mit, który od lat powtarzany jest w książkach, blogach i rozmowach, a to po prostu nieprawda. Skąd mam wiedzieć? Zapytałam.
Kiedy badałem pochodzenie tych elementów, postanowiłem zapytać redaktora specyfikacji HTML5, Iana Hicksona, skąd pochodzą te elementy. Odpowiedział:
Ja i inni współpracownicy WHATWG [dodaliśmy ich], [w] 2004 r., Ponieważ byli oczywistymi elementami do dodania po zobaczeniu, w jaki sposób autorzy używali HTML4. Później (koniec 2005 r. Na początku 2006 r.) Przeprowadziliśmy obiektywne badania, aby dowiedzieć się, jakie są najlepsze dziesięć klas HTML i okazało się, że w zasadzie dokładnie pasują do elementów, które dodaliśmy, co było wygodne.
Złam to: najpierw Hickson i członkowie WHATWG dodali te elementy, zanim jakiekolwiek badania zostały wykonane . Możesz zagłębić się w archiwach listy mailingowej WHATWG (na szczęście publiczne) i samemu odkryć wczesne dyskusje na temat tych elementów. Na przykład Hickson może je omawiać w listopadzie 2004 r. Z komentarzami takimi jak ten :
Tak, zamierzam uwzględnić rzeczy takie jak [elementy semantyczne] w aplikacjach internetowych. Tablica w moim biurze ma obecnie listę elementów pod nagłówkiem "ELEMENTY POZIOMU BLOKÓW HTML5" i staram się opracować, jak sprawić, by działały dobrze (omawiane elementy są obecnie wspomniane w projekcie, ale projekt w ogóle nie radzi sobie z nagłówkami). Nie patrzyłem jeszcze na markery wbudowane, ale to także na kartach.
Tak się składa, jak wyglądała strukturalna semantyka HTML5: jeden człowiek, jedna tablica i inne dane od innych członków WHATWG. (Grupa robocza WHATWG lub Web Hypertext Application Technology została utworzona przez przedstawicieli przeglądarki w odpowiedzi na porzucenie przez W3C HTML do utopijnego ideału XHTML 2.0).
Elementy używane przez miliony dokumentów, które omawialiśmy i debatowaliśmy, były, jak się wydaje, tworzone arbitralnie według kaprysu edytora HTML5 w 2004 roku. (Spotkaliśmy się z przenikliwa krytyka i niektóre niestety dokładne prognozy prawie natychmiast.)
Tantek przez długi czas nalegał na badania przed określeniem nowych formatów w kontekście mikroformatów, a ostatecznie specyfikacje WHATWG będą podobnie projektowane z rzeczywistymi danymi, zamiast wyciągać z naszych zbiorowych rzeczy. - Ian Hickson
To prowadzi nas do drugiego punktu. W grudniu 2005 r. - około roku po pojawieniu się nowych elementów - Hickson (pracownik Google'a) przeprowadził badania nad tworzeniem dokumentów za pomocą ogromnej bazy dokumentów Google. Badanie było "analizą próbki o wartości nieco ponad miliarda dokumentów, pobierającej informacje o popularnych nazwach klas, elementach, atrybutach i powiązanych metadanych". Identyfikatory nie zostały uwzględnione w badaniu. Wyniki zostały opublikowane przez Google jako Statystyki tworzenia sieci (2005) .
Najważniejszą częścią badań, jeśli chodzi o elementy strukturalne HTML, były: wyniki zajęć , które pomimo użycia próbki, na której ~ 900 milionów z 1 miliarda dokumentów najwyraźniej nie miało żadnych zajęć, zawierało pewne wspólne klasy, z których wszyscy już wcześniej korzystaliśmy w naszych projektach: stopka, menu, tytuł, małe, tekst , zawartość, nagłówek, nawigacja, prawa autorskie, przycisk, główne i tak dalej.
Hickson następnie podaje swoje spostrzeżenia na dane, sugerując, że te klasy "faktycznie [mapa] bardzo dobrze do elementów, które są proponowane w HTML5" i zapewnia tabelę porównującą wyniki badań oraz nowe elementy w HTML5: stopka klasa jest w badaniach, element stopki jest w HTML5; klasa nagłówkowa jest w badaniu, element nagłówka jest w HTML5; tekst zajęć, zawartość , treść , treść są w badaniach, a err ... artykuł jest w HTML5, który, jak zobaczymy, nie pasuje do wszystkich; sekcja nie znajduje się w ogóle, co również warto zauważyć.
Biorąc pod uwagę wartość nominalną, wszystko to jest wystarczająco rozsądne. Używam stopki, korzystasz ze stopki, stopka jest w HTML5. Jaki jest problem?
Problem polega na tym, że jeśli czytasz faktyczne Specyfikacja HTML5 , elementy w HTML5 są zdefiniowane w sposób, który ma niewiele wspólnego z tym, w jaki sposób tradycyjnie z nich korzystaliśmy.
Z jednej strony, Hickson wprowadził zupełnie nową koncepcję strukturyzacji strony w HTML5 z elementami cięcia . Z drugiej strony Hickson porównuje swoje elementy dzielące HTML5 z klasami używanymi w środowisku naturalnym, nie mając pojęcia, do czego te klasy były faktycznie używane. Klasycznym przykładem jest "nagłówek", który większość z nas użyłaby do obszaru u góry strony, ale specyfikacja HTML5 sugeruje, że można go użyć do nagłówka każdego komentarza na stronie . Naprawdę. Tylko dlatego, że zajęcia w badaniu i elementy w HTML5 mają taką samą nazwę, nie oznacza to, że ich zastosowania są takie same.
Teraz, gdyby zostało jasno przekazane, że nowe elementy zostały wprowadzone w nowym celu i jasne uzasadnienie, to nie byłoby tak źle. Ale to nie jest to, co nam powiedziano.
Oto jest Hickson w 2009 roku , odpowiadając na pytanie dotyczące celu sekcji, nawigacja, artykuł, na bok i inne:
Są mniej lub więcej, wypełniają najczęstsze żądania od twórców stron internetowych w oparciu o najczęstsze wartości atrybutów class = "". Ich głównym celem jest uproszczenie tworzenia i stylizacji.
Niestety, wydaje się, że jest to przypadek, w którym edytor HTML5, pomimo całej swojej dobrej pracy przy tworzeniu specyfikacji, ma (niech będzie hojny) zapomnieć, dlaczego dodał te elementy do swojej specyfikacji. Być może to różnica czasu między rokiem 2009 a 2004, kto wie. Ale wiemy to: elementy dzielące HTML5 nie zostały dodane, aby wypełnić "najczęstsze żądania od twórców stron internetowych". Skąd wiemy? Możemy po prostu spojrzeć na listę i zobaczyć najbardziej podstawowe elementy dodane, takie jak element sekcji (oraz powiązany artykuł i elementy dodatkowe), nie pojawiają się we wspólnych badaniach atrybutów klasowych.
Chociaż Hickson mógł zapomnieć, dlaczego te elementy zostały dodane, możemy wciąż z wdzięcznością przeczytać specyfikację, która dokumentuje ich cel.
Ale co się stanie, gdy powiesz projektantom stron internetowych i programistom, że nie martwią się, że te elementy po prostu zastąpią to, co już robisz, a następnie określasz te elementy w sposób, który z pewnością nie jest robiony przez projektantów i programistów sieci? Położyłeś je na jednokierunkowej podróży do miasta zamieszania.
To najgorszy rodzaj badań: leniwa interpretacja danych w celu usprawiedliwienia już podjętych decyzji. Często powtarzaną zasadą HTML5 jest " brukować krowę ", to znaczy" Kiedy praktyka jest już rozpowszechniona wśród autorów, rozważ przyjęcie jej zamiast zabraniać jej lub wymyślać coś nowego ". I tak mogłoby się wydawać z tymi nowymi elementami strukturalnymi: sekcja, artykuł, nawigacja i na bok (i nagłówek i stopka) - z pewnością są to po prostu "brukowanie krów"?
Takie wrażenie zrobiło wielu z nas, bo tak nam powiedziano.
Prawie pięć lat temu, kiedy po raz pierwszy dostaliśmy podgląd HTML5 wyglądało na to, że te elementy mogłyby po prostu zastąpić "nieidentycznych" divów, których używaliśmy. To, co było div id = "header" u góry strony, mogło stać się właśnie nagłówkiem ; div id = "footer" może teraz stać się stopką , a nasz div może być tylko artykułem. Proste, prawda?
Niestety, pomimo zrobienia tego, co nam powiedziano (tj. Po prostu zamiany jednego na drugiego), faktycznie zaimplementowaliśmy te elementy w sposób, który nie jest odzwierciedlony w specyfikacji HTML5. Oznacza to, że jeśli chodzi o strukturę HTML5, zasadniczo rozwidliśmy specyfikację. Obecnie istnieją dwie metody struktury HTML5 - interpretacja społeczności, która znajduje odzwierciedlenie w artykule z 2007 A List Apart (i niezliczonych innych); oraz rzeczywistą specyfikację HTML5, która wprowadza zupełnie nowy sposób strukturyzacji strony internetowej o nazwie konspektu.
Jest to sprzeczność w sercu strukturalnej semantyki HTML. Z jednej strony edytor mówi nam, że nowe elementy opierają się na badaniach dotyczących tego, co już robimy, a zatem mają na celu tylko ułatwienie tworzenia treści; az drugiej strony mamy to, co redaktor faktycznie stworzył w specyfikacji HTML5, co jest nowym sposobem strukturyzacji strony internetowej w sposób, który generuje zarys dokumentu za pomocą elementów przekrojowych .
Dokonano tutaj wyraźnego wyboru. Łamiąc zasady projektowania HTML5 i wprowadzając coś nowego, lub po prostu postępuj zgodnie z rzeczywistymi praktykami autorskimi i określ 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 naszych rękach.
Chcesz 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 MightyDeals.com w niesamowitym 50% zniżki.
Czy pracujesz z elementami strukturalnymi HTML5? Czy uważasz ich za pomocne, czy przeszkodę? Daj nam znać w komentarzach.
Wyróżniony obraz / miniatura, używa obraz struktury przez Shutterstock.