2006-03-16 16:32 napsal Lukáš Havrlant
Validátor je sice dobrá pomůcka, která může pomoci odhalit chybu v podobě nějakého neuzavřeného tagu, ale v zásadě se na něj úplně spoléhat nedá. Už Pixy kdysi dávno napsal článek o Spolehlivosti validátoru W3C, kde některé chyby zmiňoval. Já zmíním a vysvětlím další. Ale hned na začátku bych chtěl připomenout, že všechny zde zmíněné chyby nejsou chyby validátoru samotného. Jde o to, že DTD, podle kterého validátor validuje, není schopné pojmout všechny možné výmysly a upřesnění, které obsahuje specifikace samotná. Je to pouze orientační výstup, označí-li validátor vaši stránku za validní, stále ještě nemusíte splňovat všechny možné úskalí specifikace.
Nejdříve tedy chyby, které validátor neodhalí v HTML dokumentu.
Asi nejčastější chyby jsou v hodnotách atributů. Pokud totiž
může hodnota nějakého atributu nabývat nějakých rozličných hodnot, je
v DTD prakticky nemožné toto vyjádřit. Například zápis barev může
být v RGB nebo slovní pojmenování (dle specifikace je to těchto šestnáct
barev). Toto nelze v DTD zapsat, proto má třeba atribut
color konečnou hodnotu CDATA, tedy prakticky
normální text. Takže pokud budete mít v dokumentu tento kód,
validátor jej označí
za validní:
<body bgcolor="pekelně červená">
Správně by tedy hodnota měla být buď v hexadecimálním zápisu
– #RRGGBB – nebo tedy jedna z šestnácti
definovaných barev. Další atribut, který je postižen stejným nešvarem je
již Pixym zmiňovaný width (a samozřejmě tím pádem také
height). Správná hodnota tohoto atributu je buď pouze číslo
– v tuto chvíli prohlížeč počítá hodnotu v pixelech
(pozor – jednotka px se za hodnotu v HTML nedoplňuje,
je to chyba).
Druhá možnost je číslo a následný znak procenta „%“. Nyní
tedy počítá procentuální šířky a výšky. Díky tomuto procentu ovšem
opět musí být konečná hodnota definovaná jako CDATA,
nemůže být definovaná jako číslo, neboť znak procenta číslo prostě
není. Proto tedy projde i tento
zápis:
<img src="obr.gif" alt="" height="jako eiffelovka">
Další takový atribut je určitě rel. Často se totiž
používá u odkazů s hodnotou nofollow, čímž chceme
strejdovi Googlovi říci, aby daný odkaz nesledoval. Ovšem specifikace se
o této hodnotě nezmiňuje, povolené jsou zcela jiné hodnoty.
Tudíž používáním rel="nofollow" porušujete specifikaci.
Validátor na to opět pochopitelně nepřijde, hodnota je definovaná jako
CDATA.
Pokračujeme dále ve výčtu a sice mnohými lidmi tolik nenáviděným
atributem target. Ten totiž může obsahovat prakticky libovolný
název „framu“, ale může začínat pouze písmenem
(a-zA-Z). Dále jsou vyčleněny čtyři hodnoty, které mají speciální
význam (_blank, _top, _self a
_parent). Ostatní jsou dle specifikace nepřípustné. Validátor
opět chybu
neodhalí:
<a href="#" target="1. rám">odkaz</a>
Podobných atributů bude nejspíše více (třeba takový atribut
style – viz
příklad), ale ty nejdůležitější jsem snad již vyjmenoval. Přejděme
tedy k jiným „zajímavějším“ chybám.
HTML zná dva docela zvláštní elementy – <ins> a
<del>. Tyto elementy se od ostatních liší v tom, že
mohou obsahovat jak řádkové, tak blokové elementy a zároveň mohou být
vnořeny jak do řádkových tak do blokových elementů. To znamená, že
můžete stejně tak vyznačit celý odstavec, jako pouze jedno slovo.
Specifikace ovšem praví, že pokud se tyto elementy chovají jako řádkové,
nesmí již obsahovat prvky blokové. Bohužel, v DTD to opět nijak
vyjádřené není, takže přes tyto dva elementy můžete snadno do
řádkového prvku propašovat prvek blokový a validátor
je v koncích:
<a href="#">
Odkaz a
<ins>vložený <div>oddíl</div> který tu</ins>
nemá co dělat
</a>
S těmito elementy je ovšem další potíž. Jsou totiž povolené
v celém obsahu elementu <body> a to tak, že všude.
Ať je tedy zanoříte kdekoliv, vždycky to projde. A to i v
případech, kdy by to rozhodně projít nemělo. Takže snadno můžete tyto
dvě značky vložit přímo do seznamu nebo přímo do
tabulky. Asi nějak takto:
<table>
<ins>kde to jsem?</ins>
<tr>
<td>buňka
</table>
A co na to validátor? Příklad se seznamem:
<ul>
<del>jak jsem se tady dostal?</del>
<li>odrážka
</ul>
A chudák validátor opět musí předchozí kód označit za validní.
V sekci <head> také může být přítomen element
<object>. Ovšem dle specifikace by neměl obsahovat
žádný alternativní obsah, protože v obsahu elementu
<head> by prostě žádný obsah na vykreslení být neměl
(samozřejmě něco jiného je <title>). Ovšem validátor
to opět nepozná a tak si do hlavičky můžete klidně strčit i celou
tabulku:
<head>
<title>valid!</title>
<object>
<table>
<tr>
<td>zase jsem někde mimo
</table>
</object>
</head>
Prakticky identický příklad již uváděl Chamurappi. Hezké příklady se dají vymyslet při použití NET. Neboli stručně řečeno – v HTML se dá element zapsat dvěma způsoby:
<strong>důležitý text</strong>
<strong/důležitý text/
Oba příklady jsou validní.
Element s prázdným obsahem potom můžeme zapsat buď běžným způsobem
<br> nebo pomocí NET – <br/. Situace
v prohlížečích je taková, že to nefunguje :-). Ale ve specifikaci to
je. Problém nastává, pokud třeba udáváte adresu obrázku a vyskytne se
vám v cestě lomítko. Tedy nějak takto:
<img alt="" src=images/image.png>
V HTML je povoleno neuzavírat hodnoty atributů do uvozovek, avšak pouze za předpokladu, že se v hodnotě nevyskytují nějaký klikyháky jako třeba „$“ nebo mezera. Stejně tak se tam nesmí vyskytnout lomítko, protože to lomítko ve skutečnosti uzavírá celý element. Tudíž prohlížeč by měl teoreticky vidět něco takového:
<img alt="" src=images>image.ong>
Ukončovací závorka „>“ se entitami zapisovat nemusí, proto
validátor nakonec nezahlásí chybu ani na závorku, ani na klikyhák
v adrese, ačkoliv tak, jak to nejspíše autor zamýšlel, to je chybný
zápis. Že to opravdu takto funguje si můžete vyzkoušet sami, třeba když
přemístíte atribut alt až „za“ adresu, tedy
takto:
<img src=images/image.png alt="">
Validátor vyhodí
chybu na chybějící atribut alt – ve
„skutečnosti“ se již totiž vyskytuje až „za“
obrázkem.
Tak to by již mohlo ohledně HTML stačit a můžeme se směle vrhnout na XHTML, kde se také dají nalézt různé skopičinky.
Takže předně chyba zřejmě největší – XHTML nedovoluje zakázat vnořování elementů do všech úrovní, proto se musel definovat dodatek Bé, kde jsou dodatečně některá prapodivná zanoření zakázaná. Ovšem všechny tyto konstrukce validátorem projdou:
<form action="">
<div>
<form action="">
<fieldset>
<label>jméno<span><label>zase jméno</label></span></label>
</fieldset>
</form>
</div>
</form>
Dávejte si pozor na to, že v tom dodatku Bé nejsou zmíněny již
zavržené elementy, takže například XHTML tím pádem povoluje zanořit do
<pre> element <basefont>, ač to
specifikace HTML zakazuje.
Další chyba je taková, že validátor nijak nekontroluje, zda splňujete směrnici kompatibility, ač v dnešní situaci je ve většině případů nutné tuto směrnici dodržovat. Validátor však nepřijde ani na jednu chybu vůči této směrnici. Jinak chyby ohledně povolených hodnot atributů se v XHTML vyskytují také.
To by bylo prozatím všechno, už mě nic nenapadá :-).
Málem bych zapomněl – většinu zde zmiňovaných chyb odhalí Relaxed validátor od Petra Nálevky.
Další chybku ještě dnes zveřejnil Dero.
Poučné, hned když jsem si začal číst článek jsem chtěl doporučit relaxed validátor, ale ty jsi na něj nakonec nezapomněl.
Zejména děkuji za upozornění, že do atributů width a height v HTML se nevkládají za čísla jednotky px.
Dovolil bych si ale spekulovat o kontrolování směrnice kompability. Nemyslím že by to přímo spadalo pod validitu stránky ale stejně validátor na některé chyby příjde (amperesandy).
Marty
Dovolil bych si ale spekulovat o kontrolování směrnice kompability. Nemyslím že by to přímo spadalo pod validitu stránky
Pod validitu samotnou to nespadá, to je samozřejmě pravda, ale chtěl jsem tím poukázat na fakt, že validátor neupozorní na chybu vůči specifikaci. Neboli když mi validátor oznámí, že má stránka je XHTML valid, tak stránka sice skutečně validní je, ale nemusí nutně splňovat všechny části specifikace.
Kdysi jsem byl velmi pyšný na to, že jsem vytvořil stránky, které mi bezchybně prošly validátorem. Po čase mi web validní podle validátoru přišel jako samozřejmost a po přečtení tohoto článku o validitě svého webu začínám mírně pochybovat.
Každopádně se mi tvůj článek velmi líbil a byl pro mě velkým přínosem. Máš můj dík :).
Je mi to líto, SuE :-(
(ale nezoufej, třeba žádný ze zde popisovaných „chyb“ na stránce nemáš :-))
Rekl bych, že pixy se minimálně v tomto případě mýlí (NET): http://www.pixy.cz/…s/valid.html
Dero
Ano, viz Jirka Kosek v komentářích. Pixy tehdy pravděpodobně NET neznal.
Viz http://interval.cz/…-xhtml-kodu/ aneb opakování matka moudrosti, že? ;–)
A hele, Timy, už je tady zase ten spammer. Což takhle všechny příspěvky obsahující slůvko „interval“ zamítnout při náhledu s odůvodněním „Spam byl zablokován“?
Jinak gratuluji k dalšímu vydařenému článku.
Pekne :-) Da se rict, ze validator W3C udela prvni cistku, a zbytek si clovek musi/muze zkontrolovat jinak/sam. Nebo je nejaky opacny pripad, kdy validator oznaci stranku za nevalidni, i kdyz je ok? Leo
Leo
Nebo je nejaky opacny pripad, kdy validator oznaci stranku za nevalidni, i kdyz je ok?
V HTML žádný takový případ neznám, v XHTML teoreticky stačí rozšířit dokument třeba o MathML a validátor by měl řvát.
Vilém Málek
Nevím kde je problém, Jirka tam uvádí čtyři chyby, z nichž jednu z nich zde neuvádím vůbec (různé name a id) a druhou uvádím „skrytě“ – nechtěl jsem vypisovat všechny atributy, kterých se tento nešvar týká.
Další rozšíření obzorů, skvělý spot!
Relaxed validátor je velmi kulišácká věcička, ještě, že se Petr rozhodl pro VŠE, kde ho dostal jako bakalářskou práci. Člověk by nevěřil, jaké málo (z hlediska priorit) ho k VŠE přitáhlo. Schválně se ho někdo zeptejte, proč šel na VŠE a ne na ČVUT. ;-)
Tleskám, skvělé!
V titulku tohoto článku je psáno Validátor s velkým V. Tedy je myšlen konkrétní validátor, který se pyšní přívlastkem „checks Web documents for conformance to W3C Recommendations“. Nikoliv DTD, ale rovnou Recommendations.
Tedy byl bych Lukáši klidně tvrdší. Větu „Ale hned na začátku bych chtěl připomenout, že všechny zde zmíněné chyby nejsou chyby validátoru samotného.“ bych klidně nahradil větou „Všechny zde uvedené chyby jsou závažné chyby Validátoru a lze si podle nich udělat obrázek o provozovateli služby“. :-)
2 Lukáš Havrlant: Proto zde také odkaz na ten článek uvádím. A navíc IMHO neuškodí si přečíst o tom, jak a proč lze kontrolu udělat jinak, zvlášť když se zde speciálně Relaxed uvádí.
podla mna je dobra kombinacia W3C validator a k tomu rozsirenie HTML Validator do Firefoxu zalozene na HTML Tidy
Vilém Málek
Spíš jsem reagoval na to „opakování je matka moudrosti, že?“, připadalo mi, jako kdyby jste chtěl říci, že jsem to prostě celé opsal. Proti odkazu pochopitelně nic nemám.
MiSHAK
Zkoušel jsi testovat i jiné (offline) validátory, třeba CSE HTML Validator Lite
Nezkoušel, akorát CSE jsem kdysi míval a vyhazoval mi nesmyslné chyby.
t3rb1
V čem je HTML validátor ve FF dobrý/lepší než ten od W3C? Jediné co vím je, že nepozná NET, jestli ještě pamatuješ :-).
2 Lukáš Havrlant: Ne, kdybych chtěl něco takového říci, řekl bych to – spíš mne nachytáte při prostořekosti, než při podobném „psaní mezi řádky“, to nějak neovládám. Mimochodem, o důležitosti opakování už mne přesvědčil Yuhůů, takže i kdybych tady měl na mysli nějaký jinotaj, pak jedině v pochvalném slova smyslu. Protože článek je to rozhodně dobrý (jen, škoda, trochu omezený na výhradně české obecenstvo, ale to už je jiná pohádka)…
Vilém Málek
V tom případě je všechno v absolutním pořádku jak má být.
Validatoru nevadi neuzavrene tagy TR a TD, jak je to podle specifikace spravne?
To by me fakt zajimalo v cem je VSE lepsi nez CVUT :)
Unika mi, proc proboha W3C neni schopne dodat poradny validator. Vymlouvat se na DTD, ze neni dostatecne specifikovane je blbost. Sice neni, ale pri vhodne zvolene vnitrni forme se da napsat validator, ktery zkontroluje vse bezproblemu. A nemusi notne pouzivat RELAX NG a dalsi vymozenosti.
To by me fakt zajimalo v cem je VSE lepsi nez CVUT :)
Učím tam, ne? :-D
Unika mi, proc proboha W3C neni schopne dodat poradny validator
Nejsou lidi? Podle informací co mám, chtějí v dohledné době předělat validátor tak, aby podporoval validační pluginy. Pak by do něj šlo zapojit třeba i Relaxed. Ale stejně si myslím, že časem přejdou na Relaxed, protože čím dál více prosazují (alespoň teoreticky) komponované dokumenty (XHTML + XForms + MathML + SVG + SMIL + TraktorML +…), a nemají na to vůbec žádný validátor. Díky síle RELAX NG lze již dnes do Relaxed relativně snadno přidat podporu pro vybrané druhy komponovaných dokumentů. Další verze Relaxed bude podporovat jazyk NVDL, takže validace komponovaných dokumentů bude hračka.
Vymlouvat se na DTD, ze neni dostatecne specifikovane je blbost. Sice neni, ale pri vhodne zvolene vnitrni forme se da napsat validator, ktery zkontroluje vse bezproblemu. A nemusi notne pouzivat RELAX NG a dalsi vymozenosti.
No zásadní problém DTD pro validaci je, že nepodporuje datové typy. Logicky musíte použít nějaký schémový jazyk, který je umí. S nějakou vnitřní formou (ani nevím čeho) to nemá nic společného. Nejtěžší je všechna omezující pravidla převést z volného textu specifikace do nějakého formalizmu. RELAX NG + Schematron byla v podstatě nejjednodušší formalizace, která je navíc zcela standardizovaná a exitují pro ní už hotové validátory.
Komentáře jsou uzavřeny