W pierwsza część tej serii przyjrzeliśmy się błędom prowadzącym do elementów strukturalnych, które nie pojawiły się w HTML5; w druga część serii szczegółowo przyjrzeliśmy się konsekwencjom tych niedociągnięć; w tej końcowej części będziemy szukać drogi do przodu i wyciągniemy pewne wnioski na temat obecnego stanu gry.
To nie jest abstrakcyjny problem: ludzie muszą uczyć tych rzeczy. Następna generacja projektantów stron internetowych i programistów będzie nauczana z wykorzystaniem HTML5 jako punktu wyjścia. Żal mi tego, kto musi próbować wytłumaczyć zarys i podział aktualnego i przyszłego plonu studentów. Być może mądrze będą trzymać się prostego formatu, jaki mamy, który wciąż działa dobrze: używaj elementów div z identyfikatorem lub klasą / klasami.
Rozsądnie jest zasugerować, że być może agenty użytkownika w przyszłości, takie jak przeglądarki i czytniki ekranu, zrobią więcej dzięki elementom strukturalnym HTML5, a to uczyni je bardziej smacznymi dla nas jako autorów.
Bruce Lawson z Opery zasugerował właśnie to na Lista dyskusyjna WHATWG w 2009 :
W końcu nie znam żadnych programów użytkowych, które mogą korzystać z czasu, sekcji, stopki, datagridu itp., Ale zazwyczaj spodziewamy się, że niedługo nastąpi.
I oto, co Hickson, redaktor HTML5, powiedział w odpowiedzi:
Ja nie. Większość nowych elementów ma po prostu ułatwić stylizację, abyśmy nie musieli używać klas.
Wszystko to, a edytor nie widzi programów użytkowych, które kiedykolwiek używały tych elementów. Są tam, mówi, aby nas uratować od używania klas. Innymi słowy, twórca tych elementów nie jest pewien, dlaczego są one nawet w specyfikacji, z wyjątkiem "ułatwiania stylizacji".
Istnieje szkoła myślenia, która mówi, że potrzebujemy tylko garstki nowych semantyków. W końcu specyfikacja byłaby nadęta, gdyby dodawano dziesiątki lub setki nowych słów.
Z jednej strony, zgadzam się. Jeśli chodzi o tworzenie struktury strony podstawowej, powiedziałabym, że lepiej byłoby, gdybyśmy nie mieli żadnych elementów przekroju HTML. To, co kiedyś było prostym ćwiczeniem w posługiwaniu się divami, stało się skomplikowanym bałaganem w HTML5 bez żadnego zysku netto.
Jednakże, jeśli chodzi o ogólnie semantykę, są przypadki, w których można dodać więcej znaczeń nad strukturą naszej strony internetowej (np. HTML4, 5 lub cokolwiek innego), używając dodatkowych atrybutów w naszych istniejących elementach.
Jedną z najprostszych rzeczy do wdrożenia na istniejącej lub nowej stronie są punkty orientacyjne ARIA. (ARIA oznacza Accessible Rich Internet Applications i jest specyfikacją definiującą sposób zwiększania dostępności aplikacji internetowych i stron internetowych).
Znaki ARIA są podzbiorem ogólnej specyfikacji ARIA i prostym rodzajem metadanych, które umożliwiają niewidomym i niedowidzącym użytkownikom z czytnikami ekranu przeskakiwanie do znaczących części strony, np. "Punktów orientacyjnych". Dodajemy po prostu rolę = "landmark-name" do istniejącego elementu, w ten sam sposób, w jaki dodajemy class = "class-name" do elementu. Punkty orientacyjne AIRA są omówione w porównaniu do HTML5 tutaj .
Znaki ARIA znacznie lepiej pasują do tego, co obecnie robimy. Nazewnictwo jest trochę nieciekawy, ale przynajmniej odzwierciedlają rzeczywistą praktykę tworzenia stron internetowych. Na przykład możemy użyć:
(Pamiętaj, że baner, informacje główne i informacje o treściach powinny być używane tylko raz na dokument).
Znaki ARIA to proste rozwiązanie, które poprawia opcje nawigacji dla użytkowników czytników ekranu, bez wchodzenia w mętne terytorium dokumentów HTML. Są szybkie i łatwe do wdrożenia i naprawdę powinny być częścią podstawowego szablonu projektu HTML.
Mamy więc więcej semantyki w zakresie dostępności, ale mamy także więcej semantyki dostępnej dla wyszukiwarek.
Po pierwsze, pozwól mi być całkowicie jasne, że elementy HTML5 nie mają żadnych korzyści dla SEO. To mit i musimy go położyć do łóżka. Używanie tagu artykułu nie pomoże tobie ani twojemu klientowi w rankingu wyższym niż następny facet. Możesz ufać, że Google zorientował się, jak znaleźć i ocenić zawartość.
Jednak wyszukiwarki chcą zrozumieć, jak najlepiej wyświetlać (notować: nie rangować ) treści internetowe w bardziej uporządkowany sposób.
W związku z tym główne wyszukiwarki przez lata opracowywały lub przyjmowały istniejące standardowe sposoby znakowania danych strukturalnych na stronie internetowej, aby mogły uzyskać odpowiednie informacje. Na przykład podczas wyszukiwania opinii zauważyłeś, że oceny gwiazdkowe pojawiają się w najlepszych wynikach Google. Jest to przypadek, w którym wyszukiwarki mogą wyodrębnić wynik przeglądu w znormalizowany sposób i poprawić wyświetlanie swoich wyników. Przepisy są kolejnym przykładem, gdzie czas gotowania jest wymieniony dla każdego wyniku. Chociaż takie dane nie poprawiają pozycji witryny, bardziej szczegółowy wynik może zachęcić więcej użytkowników do kliknięcia, więc istnieje pewna potencjalna korzyść dla witryny i często jest to konieczne w przypadku wyścigu zbrojeń, w którym wszyscy konkurenci to robią. tak czy inaczej.
Podczas gdy tego rodzaju bogate dane były już od jakiegoś czasu w różnych postaciach, to w zeszłym roku główne wyszukiwarki uruchomiona nowy szeroki zestaw standardów dla tego rodzaju danych strukturalnych. Nazywają je "schematami" i są w nich przechowywane Schema.org . Używają standardu mikrodanych HTML i zostały już zaimplementowane przez eBay, IMDB, Rotten Tomatoes i inne.
Jest to największy skok w stronę bardziej semantycznej sieci od lat, a jednak odbywa się za zamkniętymi drzwiami, z niewielką liczbą fanfarów i bez żadnych standardów. Został nam rzucony bez ostrzeżenia, a od tego czasu przeważnie latał pod radarem internetowej społeczności projektantów. Jest też wiele nakładających się na semantykę HTML5, na przykład istnieją schematy dla artykuły , sieć strony i sieć elementy strony , wśród wielu innych schematów, które obejmują wszystko Epizody telewizyjne do warunki medyczne . To także zalecany sposób opisywania filmów w Internecie.
Po całej debacie na temat semantyki HTML (i jej braku), wyszukiwarki dały jasno do zrozumienia, że chcą znacznie więcej danych semantycznych w naszym znaczniku, ale będą się pojawiały na istniejących strukturach, a nie na nowych elementach.
Ale dla nas, jako społeczności interesującej się semantyką i standardami sieci, nie jest ani ograniczone, wadliwe podejście HTML do semantyki, ani zamknięte, odrzucane przez nikogo podejście głównych wyszukiwarek, to najlepsza ścieżka do przodu.
W pewnym sensie koń semantyczny HTML5 skręcał; od nas zależy tylko na tym, aby zadać obrażenia. Jeśli chodzi o schema.org, jest to zupełnie nowy świat, który powinniśmy dokładnie badać, lub inna mała grupa będzie decydować o tym, co jest w naszym - i w Internecie - dla nas najlepszymi. Tak naprawdę mogło już się wydarzyć.
Uzupełnijmy niektóre wnioski.
W specyfikacji HTML5 jest wiele dobrych części, od nowych funkcji formularzy do interfejsu History API i implementacji Canvas. W rzeczywistości bez WHATWG, który byłby siłą napędową HTML5, nadal utknęlibyśmy w HTML4 / XHTML 1.0, podczas gdy czekaliśmy, aż W3C zacznie działać razem. Niemniej jednak, ponieważ HTML5 i cała związana z nim technologia są nowe i ekscytujące, nie oznacza to, że musimy zaakceptować wszystko, co nam dane.
Czasami warto zobaczyć, jak powstaje kiełbasa HTML, więc wiemy, co jemy. W przypadku strukturalnej semantyki HTML wolałbym przejść.
Chcesz więcej? 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żywałeś punktów orientacyjnych ARIA lub Schema.org? Czy widzisz przyszłość dla elementów strukturalnych HTML5? Daj nam znać w komentarzach.
Wyróżniony obraz / miniatura, używa obraz struktury przez Shutterstock.