Život s krvelačným X

V tomto článku se zaměřím na praktické problémy, které by přineslo XHTML, kdyby se bylo bývalo prosadilo. Pojmem „XHTML“ myslím normální XHTML, zvané též někdy „skutečné XHTML“ nebo „opravdové XHTML“. Stránky posílané s MIME typem text/html jsou imunní, takže patříte-li k těm „zpátečníkům“, co na XHTML nepřešli, berte následující text jako sci-fi povídku.

Křeč robustnosti

Před dávnými a dávnými časy trpěl jazyk HTML, jeden z hlavních pilířů World Wide Webu, vážnou chorobou. Infekce vzešla z neúcty k Postelovu zákonu (zvanému též „princip robustnosti“):

„Buď konzervativní v tom, co nabízíš, a liberální k tomu, co přijímáš.“

Jeho aplikace v praxi fungovala jen napůl. Prohlížeče bývaly liberální k tomu, co přijímaly, ale autoři dokumentů se nedrželi při zemi a na toleranci prohlížečů často spoléhali. Tato nerovnováha v době velkého rozmachu webdesignu nahrávala velkým rybám, podle jejich parserů se utvářel de facto standard. Nezodpovědnost webmasterů týrala malé ryby.

Dnes již po této době zůstala jen jizva. Svět se změnil:

• Autoři dokumentů se naučili sebekázni, již chápou, že konzervativnost je v jejich zájmu.
• De facto standard má už díky myriádám stránek stálou podobu, se kterou nehne ani velryba. Dnešní prohlížeče se v dostatečné míře shodují, co se špatným HTML kódem dělat.

Na existující odolnost prohlížečů proti chybám sice někteří webmasteři nadávají, ale na druhou stranu na ni bezmála všichni spoléhají a World Wide Web spolehlivě funguje.

Při vývoji XML v letech 1996 až 1998 ještě byly ony dávné a dávné časy. Lidé z konsorcia si moc dobře uvědomovali, jaké škody na interoperabilitě způsobuje nedefinovaný stav ve spojení s neukázněným dokumentem. Věci, které jednoznačně nerozhodne specifikace, rozhodnou (chtě nechtě) velké ryby. Proto v doporučení XML 1.0 najdete jen velice málo nedefinovaných stavů. Nepochybně dobrý záměr.

Konkrétní realizace onoho záměru je ovšem nezvykle krutá. Celý princip robustnosti surově zavrhuje. XML procesor nesmí být liberální k tomu, co přijímá. Chybové stavy má trestat smrtí.

"Smrtelná chyba (fatální error)

Chyba, kterou vyhovující XML procesor musí odhalit a nahlásit aplikaci. Po setkání s fatální chybou smí procesor pokračovat ve zpracování za účelem nalezení dalších chyb a smí tyto chyby nahlásit aplikaci. Kvůli podpoře opravení chyb smí procesor nezpracovaná data zpřístupnit aplikaci. Nicméně jakmile je odhalena fatální chyba, procesor nesmí pokračovat v normálním zpracování."

Zdroj: Doporučení XML 1.0

Logika stojící za touto černobílou definicí byla prostá: kdyby měl chybný dokument z definice nějakou užitkovou hodnotu, nebyl by jeho autor (= ten nezodpovědný neřád z roku 1996) dostatečně motivován k nápravě. To je fakt. Proč by opravoval něco, co stejně musí všude fungovat? V mysli autora činí chybu chybou zjevný a nevyhnutelný trest, v tomto případě znehodnocení. Tak praví písmo svaté.

Podotýkám, že není rozhodující validita proti DTD. Nevalidní správně sestavený XML dokument musí být dobře rozebrán, význam validity je v XML oproti SGML/HTML záměrně degradován.

Stinná stránka drakonismu

Jazyk XHTML je aplikací XML. Lépe řečeno, je to jmenný prostor užívaný ve stromové struktuře XML dokumentu. Drakonická pravidla XML specifikace se proto vztahují i na něj. Zpracuje-li prohlížeč normálním způsobem XHTML dokument, který není správně sestavený (mluvou specifikace well-formed), dopustí se vážné chyby. Musí selhat. Musí webmastera potrestat. Dnešní prohlížeče skutečně na vadném dokumentu selhávají:

Takže pozor. Vše, co jde do prohlížeče, musíte mít neprůstřelně ošetřené. Spojujete-li dokument z více souborů, stačí jedna vadná součástka a vše je v tahu. Píšete-li kód ručně, stačí překlep. A nezapomeňte návštěvníka poučit, aby nikdy nemačkal v prohlížeči tlačítko Stop – nedotažený dokument také skončí v nenávratnu, obsahuje-li neuzavřené elementy.

Jak poznáte, že je z vaší strany vše v pořádku? Bafnete libovolný XHTML prohlížeč, nalistujete v něm svoji stránku a uvidíte, jestli vás nechá žít, či popraví. Jak prosté, jak průzračné. Žádné složité validování, žádné ověřování v osmi prohlížečích jako za dávných a dávných časů. Požehnáno buď písmo svaté.

Ále. Neříkejte, že jste tak naivní, abyste téhle utopii věřili. Bezchybné prohlížeče neexistují a XML z nich andílky neudělá. Nevyhnutelně vzniknou dva typy problematických situací:

• Váš testovací prohlížeč neselže na vadném dokumentu. Předpokládáte, že je vše v pořádku, a nevědomky si odfiltrujete nevinnou část cílové skupiny.
• Prohlížeč návštěvníka selže i na bezchybném dokumentu. Opět odfiltrujete část cílové skupiny.

V obou případech máte problém. Chcete, aby vaše stránka alespoň nějak fungovala všude, ne? Pak je pro vás každá nekompatibilita prohlížečů na úrovni XML procesoru extrémně nebezpečná.

Podívejte na následující zdroják „nachcípaného“ dokumentu:

ďťż <?xml version="1.0"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Nemocen :-(</title>
</head>
<body>
&amplamp;
</body>
</html>

Trpí mnoha nešvary. Můžeme mu rovnou vystavit parte. Jaké jsou možné příčiny úmrtí?

• BOM – písmenka ďťż (či  ve windows-1250) oznamují XML procesoru užití UTF-8. Selhat na něm nikdy nesmí, neboť minimálně UTF-8 a UTF-16 musí vyhovující prohlížeč podporovat. Všechny slušné editory BOM nezobrazují, část z nich ho automaticky vkládá, proto je tato pseudochyba tak populární. W3C validátor kvůli BOMu zobrazuje varování, že špatně napsané XML procesory mohou selhat, a CSS validátor na něm při rozebírání XHTML selže.
• Bílý znak před XML deklarací – mezera či prázdný řádek před XML deklarací je smrtelná chyba, prohlížeč musí selhat vždy. Internet Explorer neselže, starší Opera neselže, W3C validátor neselže, Amaya neselže.
• Neplatná adresa DTD – prohlížeč nečtoucí DTD na ní nesmí selhat, prohlížeč čtoucí DTD na ní může selhat. DTD čtou Internet Explorer a W3C validátor, první zmíněný selže (= v pořádku), druhý ne (= v pořádku), Mozilla a Opera neselžou (= v pořádku). Uvedený <!DOCTYPE> s relativní adresou je vykopírovaný z prvního vydání XHTML 1.0, takže ho obsahují tisíce webů.
• Nedefinovaná obecná entita – překlep &amplamp; nesmí dokument zabít. Zabije ho ve starší Mozille, v Opeře i Internet Exploreru.

Doporučení XML 1.0 obsahuje řadu pikantních pravidel, která může špatně vstřebat nejen autor dokumentu, ale i autor prohlížeče. Vyjmenované drobnosti jsou jen zlomek. Při využití reálných možností modularizace a jmenných prostorů třecích ploch neubývá, naopak. Nespolehlivé je pojetí parametrických entit, externích rozebíraných entit, selhávání na sekvenci znaků ]]> (někde je povinné, někde zakázané), užívání dvojtečky v procesních instrukcích a tak dále. Dva nejznámější XHTML prohlížeče také projevují mimořádnou toleranci k obecným entitám: překládají  , © a další na znaky, aniž by četly odkázanou DTD.

Při každém pokusu o využití schopností XML, které HTML 4 postrádá, se dokument vystavuje reálnému riziku, že mu některý z prohlížečů zlomí vaz. Nezbývá, než vzít osm nejpoužívanějších kousků a ladit, ladit, ladit. Pochopit a dodržet specifikaci nestačí.

V XHTML se prohlížeč stává soudcem i katem a trestán je především jeho uživatel (což nemusí být webmaster). Cena za justiční omyl je značná. Můžete si být jisti funkčností dokumentu, když se ve svých rozsudcích neshodnou ani tři nejznámější prohlížeče?

Ukrajování z rozšiřitelnosti

S rozšiřitelností XHTML souvisí dva pojmy: modularizace a jmenné prostory. První z nich je skvělý bubák na začátečníky, proto je často užíván i v souvislostech, v nichž nedává smysl.

„XML dokument můžete transformovat (XSLT), modularizovat anebo jej jednoduše přetvořit pro WAP (angl. Wireless Aplication Protocol).“

Zdroj: Vít Dlouhý, Bezproblémový přechod na XHTML.

Fakt je, že kolem XHTML Modularizace 1.0 panuje trochu zmatek. Ta specifikace touží řešit dvě věci současně: chtěla by plně objímat sortiment elementů a atributů jmenného prostoru „ http://www.w3.org/1999/xhtml“ a zároveň umožnit komukoliv, kdo si chce vyrobit vlastní jazyk příslušející do rodiny XHTML, aby si utvořil formální předpis (DTD, XML Schéma), proti němuž může být dokument validován. Plní roli jakési líhně.

Supermazaný supertvůrce superchytrého digitálního nočníčku si tedy může snadno utvořit DTD ze všech modulů vyjma target modulu. Vy jako autoři stránek na jeho DTD vůbec nemusíte brát ohledy. Váš <!DOCTYPE> ho nezajímá. On si dokument stáhne, zvaliduje jej proti své představě o ideálním dokumentu a nějak s ním naloží. Za chyby proti té své představě vás ale nemůže nijak trestat, porušil by příslušnou kapitolku specifikace. Nočníček bude atribut target jen ignorovat, tentokrát žádné zabíjení :-(.

V reálu se oproti HTML 4 téměř nic nezměnilo, jen se ta již dávno provozovaná praxe hodila na papír a co nejobecněji (rozuměj co nejnesrozumitel­něji) popsala. HTML prohlížeče odjakživa vnímaly vždy jen jednu verzi HTML a neznámé věci ignorovaly. Modularizace rozšiřitelného HTML nakonec slouží hlavně jako omluvenka pro jeho zužování. Díky ní si může i velmi „blbý“ prohlížeč vlepit na hřbet razítko Conforming W3C® XHTML™ Family User Agent.

Má to však mouchy. Konsorcium vzkřísilo dávný problém: prohlížeč, který neimplementuje skriptovací modul, musí obsah elementu <script> sdělit uživateli. Pak také v klikacích mapách je jedna otravná nekompatibilita mezi XHTML 1.0 a modularizací (z níž vzešlo XHTML 1.1), kterou konsorcium vytrvale odmítá řešit, takže si prohlížeč musí vybírat, kterou ze specifikací poruší, a webmaster musí hádat, jak si asi prohlížeč vybere.

Bezohlednost ve jménu jmenných prostorů

Skutečnou rozšiřitelnost přináší až jmenné prostory. Jdou mimo modularizaci, mimo DTD, mimo normativní definici validity v XML. Samozřejmě si můžete z modulů poskládat DTD pro libovolný dokument užívající mnoho jmenných prostorů, ale byla by to samoúčelná práce nenavyšující kvalitu či spolehlivost výsledku. Celé to snažení o zelenou hlášku validátoru ztrácí smysl, když většinu úsilí věnujete ladění DTD.

V následujícím dokumentu jsem smísil XHTML a MathML:

<?xml version="1.0"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Kvadratická rovnice</title>
</head>
<body>
<p>
Za jedenaosmdesáti horami žila byla jedna kvadratická
rovnice a ta měla dva překrásné kořeny:
</p>
<math xmlns="http://www.w3.org/1998/Math/MathML">
<apply>
<eq/>
<ci>x</ci>
<apply>
<divide/>
<apply>
<csymbol>±</csymbol>
<apply>
<minus/>
<ci>b</ci>
</apply>
<apply>
<root/>
<degree><cn>2</cn></degree>
<apply>
<minus/>
<apply>
<power/>
<ci>b</ci>
<cn>2</cn>
</apply>
<apply>
<times/>
<cn>4</cn>
<ci>a</ci>
<ci>c</ci>
</apply>
</apply>
</apply>
</apply>
<apply>
<times/>
<cn>2</cn>
<ci>a</ci>
</apply>
</apply>
</apply>
</math>
</body> </html>

Vzorec by šel zapsat i trochu jednodušeji. MathML disponuje širokou škálou elementů, které vyznačují spíše vizáž zápisu než jeho význam. I zde s sebou nese sémanticky čistší zápis nezávislost na způsobu prezentace, navíc jej mohou pochopit i všelijaké matematické programy.

Co se asi stane, nezná-li prohlížeč jmenný prostor http://www.w3.org/1998/Math/MathML? Dodrží W3C doporučení a obsahy neznámých elementů zobrazí. Pochopí návštěvník, jak pomocí „x ± b 2 b 2 4 a c 2 a“ určí kořeny kvadratické rovnice? Asi ne. Můžeme mu nabídnout nějakou alternativu? Třeba obrázek? Bohužel nemůžeme. MathML nijak nezohledňuje XHTML prohlížeče, které jej neznají.

Totožný problém trápí většinu jazyků, které je možné zapustit do XHTML:

• XForms: Milý návštěvníku, vyplň prosím všechny kolonky s atributem required, které tu možná nejsou, a pak klikni na tlačítko Odeslat, které možná nekliká.
• XLink: Jen si na mě klikni, neboj se, možná se někam dostaneš, možná ne.
• SVG: Níže uvedený obrázek můžeš libovolně zvětšovat, pokud vůbec nějaký vidíš.

Zatímco se celý svět svědomitě piplá s maximálně přístupnými všude-funkčními HTML dokumenty, které jsou slušně použitelné nezávisle na podpoře obrázků, stylopisů a JavaScriptů, konsorcium chrlí jazyky, jejichž použití uvnitř XHTML dokumentu bezohledně omezuje univerzální přístup. Je sice osvěžující, že máme rozšiřitelnost (konečně) standardizovanou, ale reálná využitelnost v praxi je v důsledku absence alternativ minimální.

Zřejmě jedinou výjimkou je XInclude 1.0. Ten pro případ problému s vkládáním externího zdroje definuje element <fallback>, jehož obsah je jinak ignorován. Škoda, že má mezi prohlížeči tak slabou podporu.

Technologie SVG a spol. přesto na široširém webu použitelné jsou — načítané z externího zdroje pomocí elementu <object>. Přesně stejně jako v HTML 4.

Budoucí vývoj?

Každá správná učebnice XHTML 1 říká, že vývoj HTML byl již ukončen, že nikdy žádná další verze nebude a že se vyvíjí už jen XHTML. Žádná už neupozorňuje, že sama reformulace nesymbolizuje elixír života a že smysluplný vývoj XHTML 1 rovněž skončil v roce 1999. Vše od té doby už je jen jiný pohled na totéž. Už sedm let sdílí HTML 4 a XHTML 1 společnou rakev.

Jednou ročně sice vyjde nový pracovní návrh XHTML 2, ten však nikoho „nevzrušuje“, neboť to je úplně jiný jazyk. Konsorcium veřejně přiznává, že není zpětně kompatibilní s prvním XHTML. Umíte si tu nekompatibilitu představit? Lidé neznalí jmenných prostorů často doufají, že když vhodně užijí podmnožinu XHTML 2, že si výsledek prohlédnou i starší prohlížeče. Omyl. Musíte opět připravit velký oltář a nelítostně obětovat vše, co XHTML 2 nezná. Ámen.

Spousta lidí si již všimla, že takto narýsovaná budoucnost je poněkud ponurá. Od roku 2004 jsou čím dál více slyšet skeptické hlasy výrobců prohlížečů. Nadace Mozilla, Opera Software a Apple stvořili uskupení WHAT WG, jehož posláním měl být kontinuální vývoj zatuchlých značkovacích jazyků. Skutečně plodí pracovní návrhy. Specifikace „Web Applications 1.0“ bývá často přezdívána (X)HTML 5 a definuje rozšíření objektového modelu dokumentu, HTML 4 a XHTML 1 (čímž bezostyšně porušuje XHTML modularizaci).

I konsorcium v listopadu 2006 nečekaně couvlo. Byl to krok zajisté bolestivý, ale odvážný: vznikla nová HTML Working Group. Jazyk, který byl sedm let „mrtvý“, opět oficiálně žije. Lépe řečeno: oba „mrtvé“ jazyky žijí. Uvidíme, co z toho všeho vzejde.