W pierwsza część tej serii omówiliśmy braki, które prowadzą do elementów strukturalnych HTML5, w tej drugiej części przyjrzymy się szczegółowo konsekwencjom tych błędów.
Wielokrotnie mówiłem, że HTML5 wprowadza nową metodę strukturyzacji strony internetowej i prawdopodobnie zastanawiasz się, co to właściwie jest. Jest tam w specyfikacji, która wprowadza pojęcie "dzielenia treści" ": sekcja treści jest treścią, która określa zakres nagłówków i stopek. Każdy element treści sekcji może mieć nagłówek i kontur.
Spec dokumentuje swoje podejście do nagłówki, sekcje i kontury aby wyjaśnić tę koncepcję. Dla tych, którzy muszą wdrożyć funkcjonalność w przeglądarkach. Abyśmy mogli zrozumieć elementy strukturalne HTML (sekcja, artykuł, nawigacja, i powiązane z nimi elementy nagłówka i stopki) oraz tę niejasną koncepcję "dzielenia treści" lub "konturowania", musimy odbyć małą podróż przez historię HTML.
Koncepcja zarysów wprowadzona w HTML5 może sięgać aż do 1991 roku i została włączona do niefortunnej, ślepej wersji specyfikacji XHTML 2.0, a wreszcie widzi światło dnia w HTML5 ... tylko tak słabo skomunikowane, że idea jest prawie martwy w dniu przyjazdu.
Przed HTML5 hierarchiczna struktura strony została określona przez elementy nagłówka - naszych starych znajomych h1 do h6. Moglibyśmy ustrukturyzować stronę, mówiąc, że tytuł strony to h1, nagłówek artykułu może być h2, a być może podpozycje w tym artykule mogą być h3 i h4, i tak dalej.
Jest to w porządku dla prostego dokumentu, ale używanie znaczników nagłówków do tworzenia logicznej hierarchii lub "konspektu dokumentu", w przypadku skomplikowanej, nowoczesnej strony internetowej jest bardzo trudne. Częścią problemu jest brak możliwości określenia miejsca, w którym rozpoczyna się i kończy sekcja strony. Na przykład, powiedzmy, że mieliśmy wcześniej wspomniany dokument z h1 dla tytułu strony, h2 dla tytułu artykułu, h3 dla podpozycji, ale następnie chcieliśmy oznaczyć tytuł dla sekcji na pasku bocznym nagłówkami h3.
Zarys dokumentu, który utworzyłby taką strukturę, wyglądałby mniej więcej tak:
My Old Blog
My Latest Blog Post
My Blog Post Sub Heading
My Blog Post Sub Heading
About Me
Archives
Social Links
Tutaj elementy h3 są "własnością" h2 nad nimi, nawet jeśli nie ma to większego sensu. Oczywiście, podzielilibyśmy je czymś takim jak div dla artykułu i div dla paska bocznego, ale są one ignorowane przez programy użytkownika (takie jak czytniki ekranu), które określają kontur strony według samej struktury nagłówka.
Przywiązując hierarchię stron bezpośrednio do często prezentacyjnych poziomów nagłówków, ograniczamy się do tego, jak możemy zorganizować stronę.
Próbując rozwiązać ten problem, HTML5 wprowadza pojęcie "elementów przekroju", czyli specjalnych elementów, które dzielą stronę na - zgadłeś - sekcje, a te sekcje określają poziom zagnieżdżenia nagłówków, a nawet hierarchię lub "zarys" strony.
To znaczy, że hierarchia strony jest oddzielona od elementów nagłówka, a zamiast tego te nowe elementy cięcia określają poziom, na którym faktycznie znajduje się element nagłówka.
W pierwszym projekcie Specyfikacja XHTML 2.0 , cięcie działało z elementem przekroju i ogólnym elementem nagłówka h. Pisząc HTML, nie określilibyśmy, jakiego poziomu nagłówków chcieliśmy użyć, więc pozwolilibyśmy przeglądarce określić poziom zagnieżdżenia dla danego nagłówka. Moglibyśmy zagnieździć elementy sekcji na 99 poziomach, a element h na 99 poziomie byłby równoważny elementowi h99. W ten sposób możemy logicznie strukturować nasze dokumenty, nie martwiąc się, w jaki sposób możemy wykorzystać ograniczone elementy h1-h6.
(Ten pomysł naprawdę sięga roku 1991, nawiasem mówiąc: jak Jeremy Keith zauważył, Tim Berners-Lee rozważył pomysł elementu sekcji i h do struktury strony na końcu ten e-mail z października 1991 roku .)
Hickson próbował wprowadzić tę samą koncepcję do HTML5, ale z dodatkowym stopniem trudności: chciał zachować kompatybilność wsteczną i wprowadzić kilka nowych semantyki, aby "uprościć tworzenie". Dlatego zamiast mieć element section w HTML5, mamy również element article, nav i aide all, który wszystkie robią to samo co sekcja, ale o różnych nazwach, do wykorzystania na różne sposoby.
Co spec mówi na temat tych elementów? Zachęcam do tego przeczytaj specyfikację dla siebie , ale oto smak:
Element section jest podstawą cięcia w celu utworzenia zarysu dokumentu.
Element section reprezentuje ogólną sekcję dokumentu lub aplikacji. Sekcja w tym kontekście to tematyczne grupowanie treści, zazwyczaj z nagłówkiem.
Przykładami sekcji mogą być rozdziały, różne strony z kartami w oknie dialogowym z kartami lub numerowane sekcje pracy. Strona główna witryny internetowej może zostać podzielona na sekcje w celu wprowadzenia, artykułów informacyjnych i informacji kontaktowych.
Notatka w specyfikacji mówi, że element nie powinien być używany do celów czysto stylizacyjnych - div byłby tam lepszy, i zrozumiale, ponieważ sekcje rzucane nieumiejętnie na stylizację stworzyłyby bardzo zepsuty zarys dokumentu.
Nota brzmi: "Ogólna zasada jest taka, że element section jest odpowiedni tylko wtedy, gdy zawartość elementu będzie wyraźnie wyszczególniona w zarysie dokumentu" i jest to najjaśniejsze stwierdzenie na temat elementu section w specyfikacji.
Kiedy rozumiemy pojęcie dzielenia i konturowania, włączenie elementu przekroju ma sens. Nie pojawił się w badaniach wspólnych wartości klasowych, ale pojawił się w XHTML 2.0, a jego koncepcje sięgają 1991 roku.
Inne elementy strukturalne, które wprowadza HTML5 - te, które rzekomo znalazły odzwierciedlenie w badaniach - robią dokładnie to samo, co element sekcji, jeśli chodzi o zarys dokumentu. Tworzą także hierarchię strony, a tym samym zarys dokumentu.
Weź element artykułu na przykład. Wiele osób zakłada, że jest to po prostu artykuły takie jak ten. Ale to w ogóle nie jest. To "artykuł" w znaczeniu "artykułu z ubrań". Jest lepiej postrzegany jako "przedmiot" niż "przedmiot ubrań", ponieważ jego definicja jest szeroka.
Gdy elementy artykułu są zagnieżdżone, wewnętrzne elementy artykułu reprezentują artykuły, które są w zasadzie związane z treścią zewnętrznego artykułu. Na przykład wpis w blogu w witrynie akceptującej komentarze przesłane przez użytkowników może reprezentować komentarze jako elementy artykułów zagnieżdżone w elemencie artykułu dla wpisu blogu.
W HTML5, komentarze użytkowników, właściwy artykuł, posty na forum, a nawet "interaktywne widżety i gadżety" to wszystkie artykuły. Definicja jest tak szeroka, że bezużyteczna - semantyka ma nadawać znaczenie, ale użycie zbiorowego określenia dla tak szerokiej gamy przedmiotów czyni element bez znaczenia.
Jest to jeden z przykładów, w którym rozwidliśmy specyfikację - kilka osób postępuje zgodnie ze specyfikacją i tworzy niemal wszystko jako artykuł (podsumowania wpisów na blogu, posty na blogu, komentarze, widżety, posty na forum itp.), Podczas gdy inni zachowują go tylko dla głównego artykułu na stronie, który jest tylko częścią szerokiej definicji. Możesz myśleć, że to nie ma znaczenia w żaden sposób i w dużej mierze masz rację. Ale pomyśl o tych wszystkich usługach do czytania, które mają na celu przeanalizowanie głównej zawartości strony. Którą implementację specyfikacji powinni przestrzegać? Czy powinni postępować zgodnie z tym, co mówi spec, czy też powinni postępować zgodnie z ogólną implementacją społeczności, gdzie zwykle na stronie jest tylko jeden kanoniczny "artykuł"?
Jest to utracona szansa, a co się dzieje, gdy specyfikacja nie jest określona , a redaktor i, aby być uczciwym, społeczność, nie przekazuje informacji o tym, co mówi spec.
Wyobraź sobie, że artykuł nie był również używany do komentowania. Wyobraź sobie, że jeśli komentarze mają swój własny element, adopcja stała się powszechna. Twórcy przeglądarki mogliby dodać funkcję "wyciszenia komentarzy", która mogłaby z łatwością ukrywać (lub analizować w inny sposób) komentarze na stronach internetowych. Ale Hickson wyraźnie odrzucił prośbę o komentarz . W HTML5 artykuły są całkowicie niedostępne.
Poza tym jest inny element, który nie pojawia się nigdzie w badaniach nad nazwami klasy Hicksona i otrzymuje bardzo osobliwą definicję do uruchomienia:
Element boczny reprezentuje sekcję strony, która składa się z treści, która jest stycznie powiązana z treścią wokół elementu bocznego i która może być uważana za oddzielną od tej treści. Takie sekcje są często przedstawiane jako paski boczne w drukowanej typografii.
Tego elementu można używać do wywoływania efektów typograficznych, takich jak cytaty z ciągnięcia lub paski boczne, reklam, grup elementów nawigacyjnych i innych treści, które są uważane za oddzielne od głównej treści strony.
Kto wie, dlaczego powinno to dotyczyć zarówno cytatów, pasków bocznych, reklam i grup elementów nawigacyjnych, ale także tworzy nowe sekcje w zarysie dokumentu. Oznacza to, że cytaty z ciągnięciem mają własny punkt punktowy w zarysie dokumentu, który wydaje się, powiedzmy, "dziwny". Ponownie, jego przypadkowe użycie przez projektantów stron o dobrych intencjach ma i stworzy wiele zepsutych zarysów dokumentów.
Element nav wydaje się najbardziej zrozumiały dla elementów cięcia, i na szczęście definicja nie została rozciągnięta poza złamanie.
Element nav reprezentuje sekcję strony, która łączy się z innymi stronami lub częściami strony: sekcją z linkami nawigacyjnymi.
Co jest w porządku, i może mieć teoretyczne korzyści z dostępności (agent użytkownika może pominąć lub przejść do linków nawigacyjnych - nie, ale mogą).
Problem polega na tym, że w duchu "upraszczania tworzenia treści" i zastępowania elementu div elementem nav, wysadzamy stylizację nawigacji dla innego podzbioru użytkowników. Użytkownicy IE6-8 z wyłączonym JavaScript (Badania Yahoo sugerują 1-2% wszystkich użytkowników ma wyłączoną obsługę języka JavaScript ) są ofiarami tego problemu. Po wyłączeniu JavaScript, podkład HTML5 HTML5, który pomaga IE6-8 zrozumieć elementy HTML5, nie działa, więc przeglądarka nie tworzy elementów HTML5. Może to dotyczyć tylko niewielkiej liczby użytkowników, ale dlaczego w ogóle mieć na nie wpływ?
Elementy nagłówka i stopki są klasycznym przypadkiem wspólnego używania terminów i mają bardzo różne zastosowania.
Spec stwierdza, że żaden z tych elementów nie tworzy nowych sekcji w zarysie dokumentu, mimo że są one często przedstawiane jako na równi z sekcją, nawigacją, artykułem i na bok. W rzeczywistości nic nie robią. Są one po prostu uwzględniane w celu rozgraniczenia obszarów określonej sekcji w zarysie dokumentu.
Oto, co spec mówi o nagłówku: element nagłówka reprezentuje grupę pomocników wprowadzających lub nawigacyjnych.
Uwaga: Element nagłówka zwykle zawiera nagłówek sekcji (element h1-h6 lub element hgroup), ale nie jest to wymagane. Element nagłówka może również służyć do zawijania spisu treści sekcji, formularza wyszukiwania lub dowolnego odpowiedniego logo.
i stopka: element stopki reprezentuje stopkę dla jej najbliższego przodka wycinającego treść lub dzielący element główny. Stopka zwykle zawiera informacje o jej sekcji, takie jak kto ją napisał, linki do powiązanych dokumentów, dane o prawach autorskich i tym podobne.
W HTML5 element body jest w rzeczywistości elementem sekcji głównej, więc ogólny nagłówek i stopka jest przeznaczony do opisania sekcji głównej. Każda sekcja może mieć nagłówek i / lub stopkę - nie są one przeznaczone tylko dla ogólnych nagłówków i stopek, jak moglibyśmy przypuszczać. Poszczególne komentarze mogą mieć na przykład nagłówek i stopkę. W rzeczywistości, jak już wspomnieliśmy wcześniej, specyfikacja faktycznie podaje przykład stopki używanej w komentarzu nad treścią komentarza. Zgadza się, w komentarzach HTML5 są artykuły i mogą mieć stopkę dla nagłówka, i to w rzeczywistej specyfikacji. Czy chciałbyś wstawić element stopki do nagłówka swoich komentarzy? Nie? Cóż, masz jedną.
Ponownie, w tym miejscu HTML5 przyjmuje wspólne terminy i używa ich w sposób nierozpoznawalny dla wspólnego autora sieci.
Ale jest coś, o co nie patrzyliśmy w implementacji cięcia w HTML. Zauważyłeś to? Mamy elementy podziału, ale nie mamy generycznego elementu h. Nie martw się, rozwiązaniem jest w specyfikacji :
Sekcje mogą zawierać nagłówki dowolnej rangi, ale autorzy są zdecydowanie zachęcani do używania tylko elementów h1 lub do używania elementów odpowiedniej rangi dla poziomu zagnieżdżenia sekcji.
HTML5 chce być kompatybilny wstecz, więc WHATWG postanowiło nie wprowadzać elementu h (pomimo wprowadzenia kilku nowych elementów cięcia), a zamiast tego chce zmienić przeznaczenie elementu h1 na ogólny element h. Używaj h1 wszędzie i pozwól, aby algorytm wyznaczania HTML5 ustalił jego prawdziwy poziom ... lub tak się dzieje.
To okropny pomysł z kilku powodów, z których dwa główne to dostępność i stylizacja.
Używanie h1 wszędzie jest bardzo złe dla dostępności. Niewidomi użytkownicy w znacznym stopniu polegają na strukturze nagłówków witryny. Ważne jest, abyśmy wszyscy przypomnieli sobie, jak ważna jest struktura nagłówków dla celów związanych z dostępnością. Na przykład w grudniu Przegląd 2008 ponad 1000 użytkowników czytników ekranu przeprowadzone przez WebAIM stwierdzili, że 76% użytkowników niewidomych i niedowidzących "zawsze lub często" nawigowało po nagłówkach, gdy byli dostępni. Z badania przeprowadzonego w maju 2012 r. Wynika, że 82,1% poziomów kursu było "bardzo użytecznych" lub "nieco użytecznych" podczas nawigacji po stronie internetowej. (To jest dobre, praktyczne badanie, więc zwróć uwagę.)
Posiadanie h1s wszędzie spowoduje, że strony będą trudniejsze w nawigacji dla niewidomych użytkowników. Teoretycznie czytniki ekranu użyłyby zamiast tego algorytmu nakreślenia HTML i nawigowałyby przy użyciu konturu dokumentu, ale biorąc pod uwagę sposób, w jaki autorom powiedziano, aby wdrażały elementy przekrojowe, zarysowanie jest bałaganem i próba nawigacji w obrysie dokumentów, które nie zostały w żaden sposób przemyślane. być jeszcze gorszym dla niewidomych użytkowników.
Specyfikacja HTML5 oferuje wyjście: używaj odpowiednich poziomów h1-h6, aby zachować kompatybilność wsteczną. Ale teraz zachowujemy dwa zarysy dokumentu w jednym dokumencie i biorąc pod uwagę problemy, które autorzy mieli nawet z uwzględnieniem zarysu dokumentu, prawdopodobieństwo, że ktokolwiek zachowa zarówno logiczny zarys h1-h6, jak i logiczny, właściwie -konstruowany konspekt HTML5 wydaje się w najlepszym razie zdalny.
Ale robi się gorzej. Powiedzmy, że chcemy uruchomić z czystym kontem HTML5 i wszędzie używamy h1. Pamiętaj, że w specyfikacji HTML5 h1 jest po prostu ogólnym elementem h; jego rzeczywisty poziom jest określony przez głębokość jego zagnieżdżonych w sekcjach elementów.
Jak go stylizować? Możemy dodać nazwy klas do wszystkich elementów h1, abyśmy mogli je wybrać, ale jest to sprzeczne ze stwierdzonym celem HTML5 uproszczenia tworzenia treści; i równie dobrze możemy trzymać się h1-h6 (z których wszystkie są traktowane jako ogólne elementy h w zarysie HTML5).
Moglibyśmy spróbować je wypróbować przez kaskadę, ale to szybko staje się absurdem, jak Nicole Sullivan zwróciła uwagę . W rzeczywistości "absurd" tylko zaczyna go opisywać. Kiedy rozważasz możliwe kombinacje sekcji, artykułu, nawigacji i na bok, i chcesz stworzyć ogólny styl nagłówka, który ma na przykład pięć poziomów głębokości (tj. Odpowiednik h5), musisz napisać style dla wszystkich możliwe kombinacje, które dostaje absolutnie niedorzeczne . Oto ogólny styl dla elementu h3:
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;}Ale właśnie to dają nam elementy strukturalne HTML. Co za bałagan.
Chcesz więcej? Część trzecia 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 używasz wielu elementów artykułów w dokumencie? Czy sekcje są przydatne, czy powinniśmy trzymać się elementów div? Daj nam znać swoje myśli w komentarzach.
Wyróżniony obraz / miniatura, używa obraz struktury przez Shutterstock.