Validita nade vše

8. září 2008

•

Webové prohlížeče se zarputile odmítají podřídit standardům, standardizátorům se zase ne vždy dařilo tvořit smysluplné a použitelné standardy. Co z toho plyne pro validující maniaky? Asi to, že dříve či později narazí na těžké dilema. Na jedné straně se budou chtít zalíbit validátoru, na druhé straně zjistí, že validní řešení určitých situací neexistuje.

O validátoru

Validátor je zařízení, které ověřuje validitu (X)HTML dokumentů, tedy zkoumá, zda jsou v souladu s příslušnou DTD. Někteří pokládají validitu za jeden ze SEO faktorů, což je pochopitelně hloupost. Je těžké si představit, že by vyhledávače opravdu prováděly validaci a bez slitování by znevýhodňovaly stránky, kde by se například vyskytoval nestandardní element či atribut nebo špatně zapsaná entita. Validita nic nevypovídá o kvalitě obsahu webových stránek, a proto není pro vyhledávače podstatná.

Kdo používá validátor, setkává se pravděpodobně s chybovými hláškami, jež se týkají převážně syntaktických prohřešků, které nemají s validitou nic společného. Nabízí se otázka, proč tedy validátor označuje kód se syntaktickými chybami za nevalidní. Musíme si uvědomit, že doposud žádná norma nestanovuje, jak interpretovat syntaktické nedostatky (snaží se o to až HTML 5). Pokud tedy validátor narazí na syntaktickou chybu, nedokáže už z dokumentu odvodit jeho přesnou strukturu, což se projeví nejen plejádou nesmyslných chybových hlášek, které obvykle zmizí, jakmile odstraníme první chybu, ale zejména tím, že dokument neprojde procesem validace.

Kterak přelstít validátor

Uvážliví čtenáři se asi budou užasle ptát, k čemu je dobré snažit se přechytračit užitečného pomocníka, ovšem my skuteční odborníci žádného takového pomocníka nepotřebujeme, neboť všechno víme nejlíp a validátor nás jenom omezuje.

Detekce klienta

Nejlepším způsobem, jak přimět validátor k poslušnosti, je podsouvat mu speciální kód, který nemusí být dlouhý, zato však musí být bez chyb. Je jedno, co přesně bude daný kód obsahovat, protože jej budeme předkládat pouze validátoru. Webovým prohlížečům naservírujeme to, co skutečně hodláme prezentovat – tedy kód s různými báječnými prvky (marquee, bgsound apod.), ze kterých jsou uživatelé štěstím bez sebe, obohacený syntaktickými „perličkami“. Rozhodně nesmí chybět ikonka hlásající „HTML valid“, ať všichni umřou závistí.

Jak však rozlišit, co je validátor a co webový prohlížeč? Vždy, když si chce nějaké zařízení ze serveru stáhnout webovou stránku, odešle příslušnému serveru HTTP požadavek. Ten obvykle obsahuje mimo jiné identifikaci daného zařízení. V PHP je tato identifikace uložena v proměnné $_SERVER[HTTP_USER_AGENT]. My jen potřebujeme zjistit, zda patří validátoru, či nikoliv. Jestliže ano, pošleme jako odpověď validní kód. V opačném případě zašleme své „vychytané“ pseudoHTML.

<?php if (stristr($_SERVER[HTTP_USER_AGENT],"W3C_Validator")) echo(/* obyčejný validní HTML kód */); else echo (/* invalidní ale geniální výtvor */); ?>

Údaje v HTTP požadavcích se samozřejmě dají podvrhnout, ovšem validátor nemá důvod uchylovat se k takovým podlým trikům, neboť jeho účelem není validitu účinně vymáhat, nýbrž pomáhat kodérům kontrolovat jejich výtvory.

JavaScript raději ne

Pravděpodobně nejhorší možnost, jak validátor zkrotit, je vkládat problematický úsek kódu do stránky JavaScriptem.

... <body> <script type="text/javascript">  </script> ...

Poznámka: Předchozí příklad se nepodaří uplatnit v XHTML. Hlavně proto, že na XHTML dokument nelze užít metody write() (ani writeln()). Daný úsek kódu by se tedy do XHTML dokumentu musel vpravit až po sestavení dokumentu například prostřednictvím vlastnosti innerHTML.

Validátor neprovádí příkazy skriptu, tudíž se k onomu problematickému úseku vůbec nedostane (resp. bude jej vnímat jako obyčejný komentář) a validita bude zachráněna, žel na úkor přístupnosti. K obsahu vkládanému pomocí JavaScriptu se nedostanou vyhledávače ani někteří uživatelé.

Podmíněné komentáře

Pryč od skriptů. Jiným hezkým způsobem, jak přivést validátor k rozumu, je využití podmíněných komentářů. Podmíněný komentář je vlastně regulérní (X)HTML komentář, do nějž je v jistém tvaru vložena podmínka, která zjišťuje, zda je použitým prohlížečem IE, potažmo jaká jeho verze. Jestliže je podmíka splněna, obsah komentáře je v IE zobrazen. Díky tomu lze, jakkoliv se to zdá paradoxní, validně uplatnit zcela nevalidní konstrukce. V IE se to zobrazí, a validátor to bude brát jako komentář (znaky <, >, " se v komentářích vyskytovat mohou).

To, že podmíněné komentáře fungují pouze v IE, by se mohlo zdát jako omezení odsuzující předložené řešení k nepoužitelnosti. Jenže opak je pravdou. V řadě případů jsou totiž kodéři nuceni uchylovat se k různým obezličkám a nestandardním postupům jenom kvůli IE. Podmíněné komentáře umožňují skrývat nevalidní konstrukce nejen před validátorem, ale také před alternativními prohlížeči. Vše perfektně dokumentoval David Grundl.

Když DTD od W3C není po chuti

Som z princípu proti W3C, môjmu pohľadu je odporné čokoľvek z dielne W3C, toto konsorcium je centralistická, demagógická, komerčná, karieristická, neznalá banda hlupákov, ide im len o moc, slávu, peniaze, bolia ma z nich oči. Nedokázal by som zniesť DTD od takéhoto zriadenia, akým je W3C.

Ano, to je nápad! Podsunout validátoru vlastní DTD, aby validoval proti ní. Něco takového je ovšem možné jen u XHTML, kde je parser povinen rozebírat interní podsadu DTD.

Odlišným, i když v zásadě stejným postupem lze validátor donutit, aby dokument parsoval jako prosté XML. Jde to snadno, protože W3C Validátor se narozdíl od prohlížečů neřídí MIME typem (dříve to dělal). Prohlížeče a jiná relevantní zařízení zase při MIME typu text/html použijí svůj HTML parser, tedy pokud se tomu dá říkat HTML parser, co něco takového zpracuje. Odkazovaná stránka navíc zneužívá syntaxi procesních instrukcí (<? ?>) pro skrytí určitých úseků kódu před validátorem, což by v něm jako (X)HTML neprošlo.

K čemu je to dobré?

Prakticky k ničemu, ale některým na validitě prostě záleží do té míry, že pro zelenou hlášku spáchají cokoliv. Nicméně abychom si nějaké důvody přece jen uvedli:

Jak už bylo zmíněno v úvodu, v některých případech, např. když je potřeba u formulářového políčka vypnout nabízení dříve doplněných údajů (autocomplete="off"), validní řešení vymyslet nejde, což může být problém, pokud jedním z požadavků zadavatele je validita, vyřešitelný pouze cestou kvazivalidity.
Často se předpokládá, pomiňme, zda oprávněně, že profesionál, který za něco stojí, musí mít svůj web, jakožto svou vizitku, výstavně validní. A běda, jestli ne, hned by se na něj snesla vlna ostré kritiky od nás skutečných odborníků. Jak se této kritice vyhnout a přitom mít kód vylepšený třeba tagem <wbr> (volitelné zalomení řádku)? Opět s pomocí výše popsaných triků.
Existují i tací, kteří si nechcou zadat respektováním řádu, jenž je přesahuje. Je pro nich důležité ukázat, jak málo pro nich standardy znamenají a vítají každou příležitost, která jim umožní se nad ně povýšit.

Kterak se nechat přelstít validátorem

Vše doposud uvedené se týkalo W3C Validátoru. Existují však i další validátory, které mohou mít mírně odlišnou funkcionalitu. Představme si jeden z nich – Český validátor. Ten je vlastně nadstavbou W3C Validátoru – využívá jeho engine.

Autor Českého validátoru Tomáš Hradil jej vytvořil se záměrem odradit kodéry od používání XHTML. Postupem času a úprav se však z Českého validátoru stal užitečný a doporučeníhodný nástroj. Autor se však svého záměru stále nevzdal, takže pokud si někdo bude chtít v jeho validátoru zvalidovat svou stránku s XHTML kódem, zřejmě se dočká strašidelných chybových hlášek navzdory tomu, že kód bude v pořádku. Příčinou tohoto jevu není žádný bug, ale záměrné použití HTML parseru na XHTML kód. Mnozí se bohužel v záchvatu validačního entusiasmu rozhodnou nahlášené „chyby“ opravit. Například tím, že změní MIME typ. Tato oprava ovšem způsobí, že se stránka nezobrazí v nejpoužívanějším prohlížeči. Ani druhý způsob opravování, konverze XHTML kódu na HTML kód, nemusí být nejšťastnější. V případě transitional DTD dojde totiž k rozsáhlým změnám ve funkčnosti stránky. Nebezpečí spočívá v tom, že některé změny jsou obtížně zjistitelné. Koho například napadne testovat hover efekt?

Hlavními výhodami Českého validátoru jsou jednak české hlášky, které by měly být pro Čechy a Slováky přece jen srozumitelnější než ty anglické, a jednak jeho důslednost – Český validátor upozorňuje i na nedostatky, kterých si W3C Validátor nevšímá.