Tech Life

Ilustrační obrázek

Parsery HTML

27. 04. 2010 12:00    kategorie: Tech Life    autor: JIz    komentářů: 0

Celkem pravidelně řešíme jeden a týž problém: Dostaneme větší množství obecných (X)HTML dokumentů, o kterých můžeme předpokládat jen tolik, že jejich zobrazení v některém prohlížeči pokládal autor dokumentu za uspokojivé. Naším úkolem je takový dokument nebo jeho část trochu zkultivovat a přizpůsobit stylu webu, který máme pod kontrolou. Množství dokumentů nebo jejich zdroj obvykle vylučuje, že by se každý kontroloval a zpracovával zvlášť manuálně.
 

Prvním krokem bývá převod dokumentu do tvaru, se kterým si poradí standardní nástroje; zpravidla je cílem vytvořit jeho objektový model (DOM). Proč se pro zpracování takových dokumentů obecně nedá použít SGML ani XML parser, je víceméně folklór, proto to tu nebudu zbytečně opakovat v celé šíři. Jen stručně:

  • Není žádný spolehlivý způsob, jak poznat, který z těchto dvou parserů použít. Pokud použijete nesprávný, dostanete chyby nebo neočekávané výsledky. Podrobnosti (a mnoho dalšího zajímavého) najdete v článku Sending XHTML as text/html Considered Harmful.
  • Naprostá většina reálných dokumentů na webu se nedá korektně zpracovat ani jedním z obou parserů.

Břemeno minulosti

U parseru, který použijeme, ale není důležité jen to, jestli se vůbec nějakým způsobem dokáže vypořádat s dokumenty, které se fakticky neřídí žádným standardem. Podstatné je i to, jaká konkrétní řešení volí. Máme totiž nastavenou řadu precedentů danou výrobci hlavních prohlížečů, a těm se musíme podřídit.

Prohlížeče řeší komplikovanou úlohu. Na jednu stranu úplně původní dokumenty velmi často vytvářeli lidé, kteří HTML chápali procedurálně, jako instrukce řídící vzhled dokumentu. Tedy například kód <h2>Ahoj</h2> jako sled instrukcí:

  1. <h2> = zvol velké tučné písmo,
  2. Ahoj = vypiš znaky “A”, “h”, “o”, “j”,
  3. </h2> = vrať se k předchozím vlastnostem písma.

Na druhou stranu autoři standardů (jako je CSS) chápou HTML dokumenty jinak: jako serializované reprezentace struktury, kterou jsme zvyklí nazývat “DOM”. Týž kód je tedy pro ně reprezentací struktury, kterou tvoří:

  • element, jehož jméno je “h2″,
  • jeho jediným potomkem je textový uzel s hodnotou “Ahoj”.

Při vytváření DOM z mark-upu tedy musíme vytvořit takovou strukturu, která se bude prezentovat způsobem, o kterém si “HTML programátor” myslí, že je správný. Běžné prohlížeče to tak skutečně dělají, i když každý trochu jinak – často vytvářejí DOM, jehož serializací je nevalidní dokument, a to ještě zdaleka není to nejhorší, co se od nich dá čekat.

Toto je přesně důvod, proč parsery, které jsme k tomuto účelu používali (zejména jTidy), nedávaly uspokojivé výsledky. Jejich cílem je vytvořit validní dokument, občas i za tu cenu, že se bude prezentovat jinak, než původní mark-up.

HTML 5

Všechny pokusy o parser mají už delší dobu jednoho konkurenta, který má mnoho konceptuálních a hlavně sociálních předpokladů pro to, aby byl lepší: algoritmus, který pro parsování HTML dokumentů předepisuje HTML 5. Toto je skutečnost, se kterou můžete souhlasit i v případě, že jinak směr vývoje představovaný HTML 5 pokládáte za pomýlený.

Zmíněné vnější důvody, proč věřit ve správnost tohoto algoritmu:

  • O HTML 5 slyšel skoro každý, kdo má nějaké zájmy související s webem. Na této vlně zájmu se veze i zmíněná specifikace a tomu odpovídá i množství zpětné vazby, která se dostává k autorům specifikace.
  • Popis algoritmu není v žádném konkrétním programovacím jazyce. Neodřezává od sebe tedy všechny potenciální přispěvatele, kteří si myslí, že jazyk XYZ nestojí za nic. (Že existuje už poměrně brzo javovská implementace, je tedy vlastně spíš štěstí.)
  • K příspěvkům a připomínkám od spousty vývojářů se vyjadřují lidé, kteří se přímo účastní vývoje prohlížečů.

Tolik teorie. Pokusil jsem se ji otestovat alespoň na několika namátkou vybraných konstruktech, kde lze očekávat odlišné výsledky.

Test 1: Nadpis obsahující blokové elementy

Běžné prohlížeče zobrazí i druhý řádek tučně a větším písmem. DOM, který vytvoří, tomu odpovídá: odstavec je potomkem elementu “h2″, a to navzdory tomu, že serializací takového DOM je nevalidní HTML.

Test 2: XML styl uzavírání elementů

Prohlížeče pokládají “Text” za obsah nadpisu. Samozřejmě vyjma případy, kdy jim byl dokument naservírovaný jako XML; pak záleží na tom, jestli je parsovatelný jako XML.

Pozor: Tento výsledek často dostanete v okamžiku, kdy DOM obsahující prázdný element necháte serializovat jako XML. Pak samozřejmě potřebujete jiný opravný prostředek, než je HTML parser.

Test 3: Seznam nastavující odsazení

Toto je ve skutečnosti poměrně frekventovaný prostředek, který některé vizuální nástroje generující HTML používaly pro nastavení úrovně odsazení. Je to věc, kterou určitě budete muset nějakým způsobem dál opravit. Je ale žádoucí, aby před vámi parser neskryl, o co původně šlo, a ponechal na vás, jakou úpravu zvolíte.

Test 4: Formátovací element přesahující hranice bloku

Začátek odstavce se zobrazuje tučným písmem. Věci, které se takto týkají jen formátování, jsou citlivé proto, že každá změna může být nápadná.

Test 5: Odkaz přesahující hranice bloku

Začátek odstavce má být normálně klikatelný odkaz. Toto je opět věc, se kterou je třeba zacházet opatrně: odkazy od samých začátků vývoje prohlížečů fungovaly daleko obecněji, než povoluje specifikace HTML.

Výsledky

Částečně se potvrdil předchozí dojem:

  • jTidy se ve čtyřech z uvedených pěti případů zachovala jinak, než bych potřeboval. (Kupodivu Test 4 dopadl dobře, kdežto Test 5 nikoli. Z mého pohledu je to další úplně zbytečná nekonzistence.)
  • Javovská implementace parsovacího algoritmu HTML 5 všechny případy řeší zhruba tak, jako geckové prohlížeče.
  • Kupodivu stejně dobře se s těmito případy vypořádal také HtmlCleaner.

Uvedený přehled je samozřejmě pro první orientaci. V konkrétní situaci nakonec rozhodnou další okrajové případy: v našem případě to bylo zpracování mark-upu generovaného programy MS Office.

Sdílet odkaz:
tisk

Diskuze k článku

K článku nebyl zatím přidán komentář.

Přidat příspěvek

 

Kontakt pro média


Máte zájem o další informace, odborný článek či přednášku na konferenci? Kontaktujte nás prosím na pr@etnetera.cz.

RSS - Tech life


RSS kanál Tech Life Blogu

Offlineblog

Offlineblog

Ljama


Komix z prostředí imaginární firmy.

ljama

Ještě jste ho nečetli? Tak tudy ...

 
Doporučujeme: Nabídka práce, volná pracovní místa - pracovní portál SPRÁVNÝKROK.CZ