Validace HTML v rámci testů (diskuse)

[retro]

Taky by to šlo přes http://validator.w3.cz/#validate-by-input a CURL. Neznám HTML5 validator.

[zoul]

Asi ano. (Z Chamurappiho jsem míval trochu osypky, ale věřím, že to myslí dobře :) Validator.nu je dobrý v tom, že umí výsledky vracet ve strojově zpracovatelném formátu. Zatím to nevyužívám ($response->as_string !~ /…/), ale výhledově bych chtěl, aby test mohl rovnou poukázat na chybu.

[Jan Grmela]

Díky! Něco takového jsem teď potřeboval. Zákazník si vymyslel, že chce ve fóru rich text editor a já už si představoval ty hrůzny s validováním HTML, co z toho polezou

P.S.: Ano, aplikace je v Catalystu

[hikikomori82]

htmLawed

[Jan Grmela]

Dík, zkusím.

[Josef Kufner]

Díky. Dobrá inspirace. Na testování validity html jsem úplně zapomněl. Vlastně je to věc, která může pomoct odhalit i spoustu jiných problémů... třeba rozbitý strom z <li>, protože se porouchalo menu a podobně...

[petr_p]

Jak je to rychlé? Nebylo by rychlejší použít lokální DTD / XML Schema validaci a některá zvláštní pravidla, které schéma neumí popsat prostě vynechat?

[zoul]

Pomalé testy pouštím jen před nahráváním nové verze na web, takže je to rychlé „dost“. Konkrétně šest vteřin na čtyři URL včetně režie Perlu a Catalystu. Místní validátor by byl určitě rychlejší, ale tohle je přenositelnější a nemusím se o nic starat. Pokud zrovna nejsem připojený k netu nebo vypadne Validator.nu, mám samozřejmě smůlu.

[Andrej Herceg]

Už dosť dlho používam Offline HTMLHelp.com Validator.

Ak editor podporuje nastavenia pre chybové hlášky (prípadne dokáže spracovať chybové hlášky, ktoré vie spracovať aj Emacs), tak nie je problém potom skákať na riadok, v ktorom bola chyba... (napr. presne tak som to používal v editore Bluefish).

[happy barney]

a čo toto? len som našiel, neskúšal ... HTML::Validator

[Radek Miček]

Bylo by hezké programovat v takovém jazyce, který by byl schopen prostřednictvím svého typového systému zaručit, že generované HTML je validní.

[zoul]

K tomu by asi stačilo použít knihovnu. (Ačkoliv si zrovna neuvědomuju, jestli by všechny požadavky validity šly snadno ošetřit bez velkých opičáren v API.)

[petr_p]

Na to stačí v nejhorším případě po každé úpravě stromu zavolat validátor. Čekám, že existující knihovny to mají řešeno chytřeji. Když jsem používal javovou dom4j, tak tam to fungovalo.

[Radek Miček]

Abych to upřesnil, myslel jsem, že by už kompilátor ověřoval validitu generovaného HTML, tj. jazyk nebo knihovna by neumožnila napsat kód generující nevalidní HTML.

[petr_p]

V době překladu těžko, protože jedna z podmínek validity HTML je, že element a nesmí být vnořený. Jakmile budete mít v programu smyčku, neexistuje způsob, jak bez spuštění programu rozhodnout, zda program vloží odkaz do odkazu. To je problém principiální, nikoliv neschopnost programátorů.

Pokud jde o knihovnu, tak za běhu je možné docílit toho, že se to nikdy nestane. Ale to už je za běhu. Jak jsem psal, třeba dom4j to umí. Objektu, přes který se buduje dokument se na počátku vrazí DTD a když aplikace zkusí porušit pravidla, tak dané volání knihovny selže.

[Jirka P]

Tenhle argument mi nějak nesedí - to pravidlo není principiálně odlišné od jiných (třeba že TABLE obsahuje THEAD, TBODY a TFOOT). Pokud byste udělal použitelný typový systém (v jakémkoli jazyce), který umí všechna pravidla HTML z DTD, tak by to šlo upravit na ta vnořená áčka IMHO lehce. Ale i to první by byl strašný nepoužitelný opruz.

[Radek Miček]

Já myslím, že by toho šlo dosáhnout i v běžných jazycích jako je třeba Java. Akorát bych potřeboval docela dost typů -- v podstatě bych do typů zakódoval stavový automat, tj, typy by byly stavy a funkce/metody přechody a jejich návratový typ by určoval cílový stav.

[petr_p]

Praktický typový systém má konečné množství typů, tedy konečný automat, tedy regulární gramatika. Jenže (ořezané) HTML je bezkontextová.

[Radek Miček]

Ale já tu bezkontextovost nepotřebuji. Představte si, že chci třeba generovat do sebe zanořené divy, pak použiji třeba funkci create_div(obsah_divu) a ona mi vygeneruje jak otevírací, tak i uzavírací tag.

[petr_p]

Asi s A problém nebude, protože to je lokální dvou stavová záležitost, ale co taková jedinečnost identifikátorů (@id, @name). Na to asi CFL gramatika stačit nebude. Nebo uživatelsky zadefinované entity v lokálním DTD. Nejsem si jistý, že by to šlo. Sice se tvrdí, že HTML je CFL, ale na druhou stranu se hned dodává (nebo zapomíná dodat), že se tím myslí jazyk bez DTD a ostatních vychytávek. A nikde jsem gramatiku nebo důkaz neviděl.

[Radek Miček]

Máte pravdu, že jedinečnost id do typového systému budu kódovat dost těžko. Pokud bych chtěl zajít do extrému, tak mohu využít toho, že všechna slova lze očíslovat a čísla už v typovém systému reprezentovat mohu, takže by součástí typu muselo být i jaká id byla použita. Nicméně má to dost problémů.

Další řešení je, že se id budou generovat automaticky -- nicméně, to už je podvod, protože to řeším za běhu.

A třetím řešením je využít možnosti spouštět vlastní kód při běhu kompilátoru (pokud to jazyk podporuje), pak lze ověřit, zda-li id už nebylo použito.

[Radek Miček]

Přesněji mám na mysli něco jako WASH -- ten sice nezaručuje úplnou validitu nicméně s troškou snahy by se i to mohlo podařit.

že element a nesmí být vnořený. Jakmile budete mít v programu smyčku, neexistuje způsob, jak bez spuštění programu rozhodnout

Takový kód by se neměl vůbec přeložit. (Samozřejmě nevylučuji, že nastane situace, kdy program generuje validní kód a kompilátor ho odmítne, protože si tím není jistý. To je obecně nerozhodnutelné -- redukcí na halting problém.)

Pro tento účel může být zajímavý jazyk OCamlDuce viz příklad.

[Jendа]

Pochopil jsem správně, že by to šlo udělat i lokálně pomocí tohoto?

[zoul]

Ano.

[Jendа]

A… proč se to tedy posílá nějaké cizí službě?

[zoul]

Dobrá otázka :) (1) Na Validator.nu jsem si zvykl, když ještě ostatní validátory nepodporovaly HTML5. Když jsem teď začal přemýšlet nad validací, na místní validátory jsem úplně zapomněl. (2) Místní validátor je neperlová závislost, kterou bych musel udržovat na produkčním serveru a případně na všech mašinách, na kterých budu chtít aplikaci vyzkoušet. Momentálně jsou všechny závislosti řešitelné čistě přes CPAN – dokonce ani Apache nepotřebuju, a to je pěkné. (3) Chtěl jsem si vyzkoušet, jak rychle se dá napsat klient.