Poradnik krytyka HTML 5

Table of contents

Poradnik krytyka HTML 5

Poradnik może wyglądać na bitwę HTML z XHTML, którą HTML 5 nie jest, ale to nie ja wymyśliłem te bzdury, ja je tylko prostuję.

Ilość osób mających opinię o HTML 5 jest niestety znacznie większa od ilości osób, które mają przynajmniej podstawową wiedzę na ten temat.

Oto krótki poradnik dla początkujących krytyków HTML 5.

HTML 5 a zabijanie XHTML 1.x

Przeczytaj podtytuł specyfikacji.

XHTML 1.x nadal żyje jako XHTML 5, który jest częścią HTML 5.

Specyfikacja HTML 5 pomaga w migracji z HTML do XML.

Składnia HTML (text/html) dopuszcza konstrukcje zalecane w dodatku C specyfikacji XHTML 1.0.
Elementy HTML w DOM używają przestrzeni nazw XHTML, dzięki czemu XPath i XSLT działają tak samo z HTML i XHTML.
W trybie XML wolno używać innerHTML, który do tej pory działał tylko w trybie text/html.

Zabijanie XHTML 2

XHTML 2 był martwy bez pomocy HTML 5. Sam twórca WWW przyznał, że przestawienie Sieci na XML nie udało się. XHTML 2 nie oferował aż tak rewolucyjnych możliwości, żeby było warto dla niego zerwać kompatybilność ze wszystkimi przeglądarkami i narzędziami HTML/XHTML 1.x.

Ponieważ strategia XHTML 2 była skazana na porażkę, powodowała przepychanki wewnątrz konsorcjum i konflikt z twórcami przeglądarek HTML, W3C postanowiło zakończyć prace nad XHTML 2.

XHTML a wymuszanie poprawnej struktury

Sprawdzanie HTML 4 i XHTML 1.x bazuje na przestarzałym DTD, który przepuszcza wiele błędów (składnia XML w tym przypadku nic nie pomaga).

HTML 5 ma więcej wymogów co do poprawności dokumentów i są one sprawdzane dokładniej.

XHTML a wymuszanie poprawnej składni

Większość stron z DOCTYPE XHTML działa tylko i wyłącznie dzięki temu, że ta deklaracja jest niewystarczająca i przeglądarki interpretują te dokumenty jako HTML z błędami, a nie XML.

Gdy nie pozwoli się przeglądarkom traktować XHTML jako HTML, to rzekomo XHTMLowy digg.com nie otwiera się w ogóle. Tak samo engadget.com, wired.com, wykop.pl. Prawie każda duża strona z DOCTYPE XHTML tak na prawdę działa tylko jako HTML. Nawet validator.w3.org ma problemy z trybem XML.

Specyfikacja HTML 5 likwiduje to zamieszanie. Używa tylko jednego DOCTYPE i nie pozwala wysyłać XHTML jako text/html.

HTML a poprawna składnia

Specyfikacja HTML 5 dokładnie opisuje, jak wczytać każdy nieprawidłowy dokument text/html, ponieważ w praktyce jest to niezbędne do wczytywania większości dokumentów używanych w sieci (m.in. wspomnianych stron, które miały być XHTML, ale im nie wyszło).

Opis interpretacji błędów nie jest zezwoleniem na robienie ich. HTML 5 nakazuje autorom stron trzymania się ściśle określonej składni, a parsery HTML 5 mają prawo odrzucać błędne dokumenty.

W trybie text/html niektóre tagi są opcjonalne i atrybuty nie zawsze muszą mieć wartość w cudzysłowie, ale to jest dozwolone tylko tam, gdzie nie powoduje żadnych niejasności.

Dla tych, którzy preferują estetykę XML, HTML 5 pozwala w trybie text/html używać składni prawie identycznej ze składnią XML.

Ale gdyby wszyscy używali XML…

To nigdy się nie stanie. Ścisła składnia jest przykładem dylematu więźnia — wymaga od autorów stron i twórców przeglądarek współpracy bez „oszukiwania”. Niestety w dylemacie więźnia „oszukiwanie” jest racjonalnym wyjściem i stanem równowagi (ekwilibrium).

Nawet, gdyby wszyscy używali XML, to sieć powróciła by do stanu równowagi, gdzie twórcy przeglądarek wyłamują się ze ścisłego traktowania XML, aby nie cierpieć konsekwencji zepsutego kodu. A zepsuty kod zawsze się znajdzie, np. wsród 180 tysięcy plików XML publicznie dostępnych w Internecie aż 14% jest błędnych i tylko 9% przechodzi walidację.

Semantyczność

Konkurs: Znajdź w specyfikacji XHTML 1.0 opis semantyki choćby jednego elementu, np. <cite>.

XHTML 1.0 jest tylko alternatywną składnią HTML 4.01 i nie zmienia jego semantyki w ogóle.

HTML 5 zawiera wszystkie najważniejsze semantyczne elementy HTML 4/XHTML 1, rozszerza je o niektóre elementy XHTML 2 lub ich odpowiedniki (<section>, <nav>, <hgroup>) oraz nowe niedostępne w innych wersjach HTML (<header>, <footer>, <aside>, <figure>, <mark>, <details>, <article>).

HTML 5 znacznie rozwija i precyzuje semantykę istniejących wcześniej elementów HTML. Cały opis <img> w HTML 4 (XHTML 1) to zaledwie kilkanaście zdań i 3 przykłady. Jeszcze mniej w XHTML 2. W HTML 5 to 14 podrozdziałów z 45 przykładami.

Rozszerzalność

DTD nie obsługuje przestrzeni nazw. Z tego powodu specyfikacja XHTML 1.0 nie pozwala wykorzystywać przestrzeni nazw XML w ogóle (przestrzenie nazw nie walidują się). Dla XHTML 1.1 W3C opublikowało specjalne DTD, które pozwala używać tylko SVG, MathML i RDF. Nie da się użyć dowolnej przestrzeni nazw w XHTML 1.x bez czynienia dokumentu nieprawidłowym.

HTML 5 ma wsparcie dla SVG, MathML i rozszerzalnej semantyki nawet w text/html. Nie jest ograniczony przez DTD, więc w trybie application/xhtml+xml pozwala w pełni wykorzystać dowolne przestrzenie nazw.

HTML 5 pozwala dodawać własne prywatne atrybuty data-* do każdego elementu.

Straszenie tabelkami

XHTML 1.0 Transitional pozwala używać <font>, <center>, <table bgcolor>, itp. Natomiast HTML 5 na to nie pozwala.

HTML 5 wymaga używania CSS do kontroli wyglądu strony. Zabrania używania przestarzałych i prezentacyjnych elementów. Nie pozwala na używanie tabel do układu strony. Nie pozwala używać <frameset>.

Spójność i elegancja

Przeglądarki, nawet głosowe, nie odróżniają <abbr> od <acronym>, a przykłady w specyfikacji HTML 4 nie są do końca zgodne ze słownikową definicją. HTML 5 usuwa zbędny <acronym> i z nim niepotrzebne debaty na temat skrótów i skrótowców.

<!DOCTYPE html>
<meta charset="UTF-8">
<title>HTML 5</title>
<h1>Czy jest elegancki?</h1>

<!DOCTYPE html PUBLIC "–//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1—strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title>Kto to spamięta?</title>
</head>
<body>
<h1>To ma być język bez śmieci?</h1>
</body>
</html>

Który język jest przestarzały

Specyfikacja XHTML 1.0 została opublikowana w 1999 roku. XHTML 2 powstał ponad 10 lat temu.

Pierwsze wersje Web Forms powstały w 2004 roku na bazie XForms. W3C rozpoczynało prace nad HTML 5, gdy XHTML obchodził swoje 10—lecie. W przeciwieństwie do XHTML 1 i 2, HTML 5 jest cały czas rozwijany.

XHTML 1 i 2 zostały zaprojektowane przed upowszechnieniem się aplikacji webowych i eksplozją wideo w sieci. Wtedy nikomu nie śniło się, że ktoś będzie chciał używać HTML do czytania e-maili off-line.

HTML powstał jako język dla dokumentów, ale mimo tego dziś jest używany do aplikacji webowych i nie tylko. To nie zmieni się w najbliższej przyszłości, dlatego zamiast pielęgnować stare ograniczenia, specyfikacja HTML 5 dostosowuje HTML do jego nowej roli.

2022!

Ten rok padł jako górna granica, gdy conajmniej dwie przeglądarki będą miały pełną implementację całego języka bez bugów. HTML 4 czeka na to samo od 14 lat i jeszcze się nie doczekał, więc 13-letni plan dla HTML 5 jest optymistyczny.

Nie oznacza to, że nie będzie można użyć HTML 5 wcześniej. Różne części specyfikacji są na różnym etapie. Wszystkie podstawowe części są już ukończone.

WHATWG kompletnie zrezygnowało z wyznaczania sobie terminów i traktuje HTML jako „żywą specyfikację”, która jest non-stop uaktualniana. Gotowe jest tyle, ile dziś działa w przeglądarkach (bardzo dużo).

Wsparcie przez IE

Internet Explorer 6 jest w stanie poprawnie wczytać dokumenty HTML 5 i obsługuje sporą część specyfikacji. Składnia HTML 5 powstała przez analizę zachowań IE, a wiele z nowych elementów HTML bazuje na dotychczas niestandardowych rozszerzeniach IE. Pozostałe elementy są projektowane tak, żeby dało się je emulować za pomocą JavaScript lub by przynajmniej nie przeszkadzały IE.

Internet Explorer zaczął wspierać XHTML dopiero w wersji 10. Wcześniejsze wersje w najlepszym przypadku traktują XHTML jako HTML 5.

Wsparcie przez przeglądarki

Żaden z producentów liczących się przeglądarek nie planował wsparcia dla XHTML 2.

Opera, Mozilla, Apple, Google i nawet Microsoft aktywnie pracują nad implementowaniem HTML 5.

Wideo

Elementy <video>/<audio> są nadal w specyfikacji i nie zostaną usunięte.

Potrzebne są, by oferować API JavaScript umożliwiające zrobienie pełnego własnego odtwarzacza a'la YouTube i last.fm. <object> nie da się kontrolować w standardowy sposób i jako element ogólnego zastosowania nie powinien mieć API audio/wideo.

Da się to obejść serwując oba formaty i hack dla IE.

Specyfikacja nie wymaga obsługi żadnego konkretnego formatu wideo, ponieważ twórcy przeglądarek nie zgodzili się na wspólny format z powodu patentów. Wymuszenie jakiekokolwiek formatu w specyfikacji spowoduje tylko, że producenci zignorują tę część specyfikacji.

Mozilla i Opera wspierają WebM i nie będą wspierały H.264 z powodów ideologicznych i licencyjnych/finansowych.
Apple i Microsoft czerpią zysk ze swoich patentów na H.264 i odmawiają użycia WebM z powodu „niejasnej sytuacji patentowej” bez poparcia tego żadnymi dowodami. Sprzęt iPhone odtwarza tylko H.264.

Google obiecało porzucić wsparcie dla H.264 i wspierać tylko WebM, ale ta obietnica nie została dotrzymana.

Wideo WebM da się dekodować za pomocą JavaScript.

Kto tu rządzi

Ty → przeglądarki → W3C.

Twórcy przeglądarek robią to, czego domagają się od nich użytkownicy i odmawiają implementacji rzeczy, które spowodowały by porzucenie przeglądarki przez użytkowników (to na życzenie Mozilli i Opery HTML 5 zawiera tyle rozszerzeń IE — te przeglądarki potrzebują tego, żeby ich użytkownicy nie wracali do IE, w którym strony “działają” “poprawnie”).

HTML WG nie ma zamiaru wypuszczać kolejnej specyfikacji, która będzie science-fiction. Rzeczy, które nie mają realnej szansy na implementację w przeglądarkach są zmieniane bądź usuwane ze specyfikacji.

W3C nie ma mocy prawnej, by zmusić twórców przeglądarek do implementacji czegokolwiek.

Prędkość i trudność parsowania

HTML 5 text/html nie jest nowym formatem. To jest tylko sformalizowanie de-facto składni używanej przez większość stron w Internecie.

W przeszłości parsowanie błędnego HTML było bardzo trudne, bo nie było żadnej dokumentacji opisującej jak należy traktować błędy. HTML 5 naprawił ten błąd.

Prędkość parsowania HTML 5 jest podobna do prędkości parsowania XML bez DTD. Zasadniczy sposób parsowania jest identyczny. Automatyczne zamykanie tagów ma koszt taki sam, jak sprawdzanie, czy wszystkie tagi zostały zamknięte. Parsowanie XML ma też swoje utrudnienia, np. mapowanie prefiksów i przestrzeni nazw.

Parsowanie XML z obsługą DTD (potrzebne by   działało w XHTML) jest wolniejsze i trudniejsze od parsowania HTML 5, ponieważ poza parserem XML wymaga także napisania/użycia parsera DTD do wczytania informacji o encjach. Parser musi być w stanie ściągnąć pliki z w3.org (robiąc DDoS) lub obsługiwać katalog DTD.