Každý správný standard by měl být jednoznačný a podrobný úměrně své důležitosti. Čím větší ambice má, tím více bolí každá jeho nejasnost. Kolik bolesti způsobilo HTML doporučení od konsorcia?
Pohleďte na následující kód:
Jak už to bývá ve světě webdesignu zvykem, opět stojíte před otázkou, jakou barvu bude mít křeček. Bude královsky modrý? Kodéra, který ví, jak funguje HTML, určitě nepřekvapí, že křeček zůstane neobarvený.
Jenže proč to ten kodér ví? Jak se to vlastně dozvěděl? Možná tak, že četl výše odkázaný článek Lukáše Havrlanta. Odkud se to dozvěděl Lukáš? Asi četl mé výjevy na diskusi Jak psát web, hrál si s validátorem a prohlížeči. Odkud jsem se to dozvěděl já? Od Iana Hicksona, validátoru a prohlížečů. Kde se to dozvěděl guru Hickson? Nevím.
Myslíte si, že máme všichni pravdu? Že se prohlížeče nepletou? Nebo že se snad validátory nepletou? Proč by tohle nemohl být jen krásně naleštěný omyl? Informace ze čtvrté ruky podpořená určitou praktickou zkušeností ještě přeci nemusí být správná z hlediska teoretického. Zpochybněte ji! Skutečný svět se pod tíhou kritického myšlení nezboří.
Pochybnosti zajisté vyvrátí všemocný a vševědoucí standardizátor. Definice z první ruky hovoří jasně:
Prohlížeč musí zajistit, aby interpretace dokumentu při přítomnosti či nepřítomnosti počátečních a ukončovacích značek, které HTML DTD prohlašuje za volitelné, byla neměnná.
— Doporučení HTML 4.01, definice prohlížeče
Hovoří zcela jasně. Ale plácá nesmysly. Volitená značka má totiž samozřejmě v mnoha případech výrazný vliv na strukturu dokumentu:
Skutečně musí prohlížeč zajistit, aby se oba uvedené kousky kódu interpretovaly stejně? Opravdu se může každá volitelná značka vždy vynechávat? Je-li tomu tak, je naše osvětové know-how prachobyčejný drb a prohlížeče i validátor postupují zcela špatně.
Konsorcium otázku volitelných značek opravdu nijak dál nerozvíjí, takže i sebepozornější čtenář specifikace nakonec prohlásí, že královský křeček bude modrý, a pomyslí si cosi o nejednoznačnosti HTML.
Parser XML už jsem psal několikrát, ale do HTML by se mi nechtělo ani ve snu. Tipovat si pravděpodobné konce neuzavřených tagů, rozpoznávat několikerý možný zápis téhož, domýšlet si jednotky atd... No fuj.
— Petr Staníček, komentář k článku Soumrak nad moderním X, 27. února 2007
Na druhou stranu ovšem pořád platí, že HTML je aplikací SGML — W3C nijak to, že se o SGML opírá, nepopírá. A ISO standard SGML (jakožto základ HTML
Rozpor mezi definicemi v HTML a v SGML jde ovšem vykládat více způsoby:
Poslední zdůvodnění je nejpravděpodobnější. Je na vás, na mně, na Lukáši Havrlantovi, na Ianu Hicksonovi a na výrobcích všech prohlížečů i robotů, abychom uhodli, že se konsorcium seklo. Chytrý drb zvítězí nad hloupou definicí. Stejně by vám nikdo nevěřil, že jste na Webylonu viděli královsky modrého křečka.
Každý začátečník asi ví, jak se v HTML značí komentář. Může vypadat třeba takhle:
Ve standardním režimu některých verzí některých prohlížečů (zejména Mozilly) ovšem při nalistování stránky s uvedeným kódem žádnou malinkou blechu neuvidíte. Čím to? Že by byla v prohlížečích chyba? V HTML 4.01 se jasně píše:
Častou chybou je zahrnutí řetězce pomlček („
---“) do komentáře. Autoři by se měli vyhnout vkládání dvou či více navazujících pomlček dovnitř komentářů.— Doporučení HTML 4.01, Komentáře
Pokud je chybou zahrnutí pomlček, proč na ni neupozorňuje validátor? Pokud to skutečně je chyba, proč je za ni takový prapodivný trest? Čím si zrovna malinká blecha zasloužila, že není vidět?
Blecha se ve skutečnosti mazaně schovala do komentáře sestaveného podle platných SGML definic, které se bohužel nikdo nenamáhal přepsat do HTML specifikací. Pohleďte na příklad, jak vypadá trojice komentářů uvnitř jedné komentářové deklarace:
Tato prastará vědomost zůstala tvůrcům stránek i prohlížečů po mnoho let dobře utajena. Dokud ji Ian Hickson nevyšťoural před deseti lety ze SGML učebnic, všichni žili v naivním snu o jednoduchých komentářích. Jelikož byl Hixie ve své osvětové činnosti dost aktivní, proputoval kolem všech známých HTML parserů vyjma exploreřího a podílel se i na testu Acid 2, nezůstalo laxní vyjadřování konsorcia bez následků.
Po sedmi letech změnil názor a rozhodl se probojovat jednoduchou syntaxi komentářů do HTML 5.
V HTML 4.01 můžete tvořit kotvy pomocí elementu <a name> nebo pomocí atributu id. Jeden z rozdílů mezi oběma postupy je prý tento:
Díky specifikaci v HTML DTD smí atribut
nameobsahovat entity. Proto je hodnotaDürstplatnou hodnotouname, stejně jakoDürst. Na druhou stranu atributidentity obsahovat nesmí.— Doporučení HTML 4.01, Odkazy v HTML dokumentu
V DTD lze určit typ atributu, id je typu ID (= má omezenu škálu dovolených znaků a požadavek unikátnosti), name je typu CDATA (= smí obsahovat cokoliv). Určitě moc dobře víte, že se v CDATA atributech entity překládají — jinak by & zapsaný jako & v hrefech odkazů nefungoval dle očekávání.
Jak je to u atributů jiných typů? Konsorcium vám neochvějně tvrdí, že v atributech typu ID k překladu entit nedochází a že ampersand do jeho zápisu nikdy nepatří. Má pravdu? Domnívám se, že nemá.
Jméno Dürst samozřejmě nemůže být v id nikoliv kvůli přítomnosti entity, ale kvůli znaku ü (tedy U+00FC). Vyměníte-li entitu ü za u, vytratí se nejen diakritika nad u, ale i chyba hlášená validátorem. Proč validátory založené na SGML/XML neřvou, že je v ID atributech entita? Proč ani prohlížečům entita nevadí? Mýlí se drtivá většina programů zpracovávajících HTML?
Nebo si pánové z konsorcia špatně nastudovali standard?
Všeobecně se ví a říká, že v HTML nezáleží na velikosti písmen. Zamyslíte-li se nad tím, kde a kdy to přesně platí, najdete řadu dobře známých výjimek. Nejjasnější výjimkou jsou odkazy — změníte-li v atributu href velikost písmen, můžete se po prokliku dostat úplně jinam, protože u adres na velikosti záleží. Ve všech atributech typu CDATA se rozdíl ve velikosti písmen nestírá.
Výjimku mají též jmenné entity. Ze zápisů ω a Ω vylezou pochopitelně dva různé znaky, malá a velká omega.
Výše uvedená pravidla stanovuje standard SGML. Respektive SGML definuje širší soubor pravidel, které se upřesňují v tzv. SGML deklaraci. Fixní SGML deklarace pro všechny HTML jazyky doslova říká, že u všech názvů nezáleží na velikosti písmen (NAMECASE NO), vyjma názvů entit (ENTITIES YES). Vyhovující HTML parser musí všechny názvy (vyjma entit) normalizovat — převést je na velká písmena.
Dle standardu spadají do množiny názvů nejen názvy elementů, názvy atributů a názvy deklarací (třeba <!doctype>), ale také hodnoty atributů typu ID. Vyhovující parser musí na původní velikost písmen již při načítání zapomenout, z id="griZZly" udělat ID="GRIZZLY".
Bude sněžný medvěd sněhově bílý? Podle SGML by nepochybně měl být. Podle starších prohlížečů bude. Podle současných nikoliv.
Specifikace HTML 4.01 totiž také mluví do toho, u kterých atributů záleží na velikosti a u kterých ne. Její autoři si usmysleli, že u id by na velikosti záležet mělo. Záměrně? Omylem? Těžko říct. Každopádně na tento rozpor nikdy nikdo moc neupozorňoval. Žádný výrobce prohlížeče neprokouknul chybičku a postupně všichni podřídili standardní režim svých výtvorů vůli konsorcia.
Paradoxně se techničtí evangelizátoři začátkem tisíciletí postarali o to, aby celý svět porušoval jedno z elementárních pravidel SGML.
Vazba mezi HTML a SGML — jakkoliv je normativně pevná — nikdy nebyla moc průhledná ani pro běžné lidi, ani pro programátory, a dokonce ani pro standardizátory. Kvůli tomu vznikaly mezi prohlížeči nekompatibility a mezi kodéry pověry.
A proto bude HTML 5 tlusté.