Nedávno jsem se zúčastnil diskuse, která mi (opět) připomněla, jak silně jsou u nás zakořeněné mýty týkající se rozdílů mezi HTML a XHTML. Kampaň za formáty s písmenem X doprovázely velké emoce a ty obvykle nechodí ruku v ruce s čistou hlavou. Sice nadšení dávno opadlo, ale značná část odborné veřejnosti i autorit dosud věří celé řadě bludů.
Pokusím se tímto článkem ty největší z nich pohřbít. A to následujícím způsobem. Tento článek bude obsahovat pouze a jen fakta. Své názory i vaše komentáře si nechám až na článek druhý.
V následujícím textu pod termínem HTML rozumím verzi HTML 4.01, pod XHTML verzi XHTML 1.0 Second Edition. Pro úplnost dodávám, že HTML je aplikací jazyka SGML, zatímco XHTML je aplikací jazyka XML.
Mýtus: v HTML je povolené křížení značek
Nikoliv. Křížení značek je zakázáno přímo v SGML, důsledkem čehož i v HTML. Tento fakt je zmíněn například v doporučení W3C: „…overlapping is illegal in SGML…“. Všechny tyto značkovací jazyky chápou dokument jakožto stromovou strukturu, a právě proto není možné značky křížit.
Zároveň tak reaguji i na reformulaci mýtu: „Výhodou XHTML je zákaz křížení značek“. Není tomu tak, značky nelze křížit v žádné existující verzi HTML nebo XHTML.
Mýtus: XHTML zakázalo prezentační elementy a zavedlo CSS
Nikoliv. XHTML obsahuje tutéž sortu elementů, jako má HTML 4.01. Je to zmíněno hned v prvním odstavci XHTML specifikace: „Význam elementů a jejich atributů je definován v doporučení W3C pro HTML 4“. Z tohoto pohledu mezi XHTML a HTML žádný rozdíl neexistuje.
Některé elementy a atributy byly zapovězené (deprecated) již v HTML 4.01. Prezentační elementy se tu zapovídají právě ve prospěch CSS, což je také odpověď na druhou část mýtu: příchod kaskádových stylů s XHTML nesouvisí, odehrál se již dříve.
Mýtus: HTML parser musí tipovat konce značek
Nikoliv. V HTML je možné u definované skupiny
elementů volitelně neuvádět koncovou nebo počáteční značku. Jde
o elementy, u kterých vypuštění značky nemůže způsobit
nejasnost. Jako příklad si můžeme vzít koncovou značku u elementu
p. Jelikož norma říká, že se odstavec nemůže nacházet
uvnitř jiného odstavce, je v případě zápisu…
<p>....
<p>....…jednoznačně dáno, že otevřením druhého odstavce se musí uzavřít
ten první. Uvedení koncové značky je tedy redundantní. Naopak třeba
element div může být zanořený sám v sobě, proto u něj je
počáteční i koncová značka povinná.
Mýtus: zápis atributů v HTML je nejednoznačný
Nikoliv. XHTML vždy vyžaduje uzavírat hodnoty atributů do uvozovek nebo apostrofů. HTML to vyžaduje také, s výjimkou, pokud hodnotu tvoří alfanumerický řetězec. Pro úplnost dodám, že i v těchto případech specifikace doporučuje uvozovky užít.
Tedy v HTML je přípustné zapsat
<textarea cols=20 rows=30>, což je formálně stejně
jednoznačné, jako <textarea cols="20" rows="30">. Pokud by
hodnota obsahovala více slov, HTML trvá na užití uvozovek.
Mýtus: HTML dokument je nejednoznačný
Nikoliv. Jako důvod nejednoznačnosti se uvádí buď možnost křížení značek, nejednoznačnost zápisu atributů bez uvozovek, což jsou již vyvrácené mýty, nebo také možnost některé značky vynechávat. Tady zopakuji, že skupina elementů, u kterých je možné značky vynechávat, je zvolena tak, aby se vynechala pouze redundantní informace.
HTML dokument je tedy vždy jednoznačně určen.
Mýtus: až v XHTML se píše znak & entitou &
Nikoliv – musí se tak psát i v HTML. Pro oba jazyky mají znaky
< a & specifický význam. První otevírá
značku a druhý entitu. Aby nebyly chápány v jejich meta-významu, musí se
zapsat entitou. Tedy i v HTML, jak uvádí specifikace.
Mýtus: HTML dovoluje ‚prasárny‘, které Vám v XHTML neprojdou
Nikoliv. Tento názor má kořeny v řadě mýtů, které už jsem vyvrátil
výše. Ještě jsem nezmínil, že XHTML u jmen elementů a atributů na
rozdíl od HTML rozlišuje velikost písmen (je „case sensitive“). Nicméně
jde o zcela legitimní vlastnost jazyka. Takto se liší například Visual
Basic od C# a nelze objektivně říci, že jeden nebo druhý přístup by byl
horší. HTML kód je možné znepřehlednit tím, že budeme nevhodně
střídat velká a malá písmena (<tAbLe>), XHTML kód
zase třeba používáním řetězců XML kód zase třeba používáním
řetězců abc, AbC,
aBC pro odlišné třídyid, ID, Id pro odlišné
atributy.
Čistota zápisu v žádném případě nesouvisí s volbou jednoho nebo druhého jazyka.
Mýtus: Parsování XHTML je mnohem snazší
Nikoliv. Srovnání na miskách vah by bylo subjektivní, a tedy nemá v tomto článku místo, objektivně však lze prohlásit, že není žádný důvod, proč by jeden z parserů měl mít výrazně jednodušší život. Každý z nich má na krku jiný balvan.
Parsování HTML je podmíněno faktem, že parser musí znát definici typu dokumentu. Prvním důvodem je existence volitelných značek. Ačkoliv je jejich doplňování jednoznačné (viz výše) a algoritmicky snadno řešitelné, tak parser musí příslušnou definici znát. Druhým důvodem jsou prázdné elementy. Že je element prázdný ví parser pouze z definice.
Parsování XHTML je zase ztíženo tím, že dokument může (na rozdíl od HTML) obsahovat interní podsadu DTD s definicí vlastních entit (viz příklad). Raději dodávám, že „entita“ nemusí představovat jeden znak, ale libovolně dlouhý úsek XHTML kódu (obsahující případně další entity). Bez zpracování DTD a ověření jeho správnosti vůbec nelze o parsování XHTML hovořit. Věc navíc zkomplikuje to, že syntakticky je DTD v podstatě protipólem jazyka XML.
Shrnuto: jak HTML tak XHTML parser musí znát definici typu dokumentu. XHTML parser ji navíc musí umět číst v DTD jazyce.
Mýtus: Parsování XHTML je mnohem rychlejší
Z hlediska syntaktické podobnosti obou jazyků je rychlost parsování dána pouze šikovností programátorů jednotlivých parserů. Čas potřebný pro strojové zpracování běžné webové stránky (ať už HTML nebo XHTML) na běžném počítači je lidským vnímáním nepostřehnutelný.
Mýtus: HTML parser si musí vždy poradit
Nikoliv. Specifikace HTML nenařizuje, jak se má aplikace zachovat v případě zpracování chybného dokumentu. Z důvodu konkurenceschopnosti v reálném prostředí došlo k tomu, že prohlížeče se staly zcela tolerantní k vadným HTML dokumentům.
Jinak je tomu v případě XHTML. Specifikace odvoláním na XML nařizuje, že parser v případě chyby nesmí pokračovat v dalším zpracování logické struktury dokumentu. Opět z důvodu konkurenceschopnosti v reálném světě došlo k tomu, že RSS čtečky se staly tolerantní k vadným XML dokumentům (RSS je aplikací XML, stejně jako XHTML).
Pokud bychom chtěli z tolerantnosti webových prohlížečů něco negativního usuzovat o HTML, pak nutně musíme z tolerantnosti RSS čteček něco negativního usuzovat o XML. Objektivně lze shrnout, že drakonický přístup XML k chybám v dokumentech je utopistický.
Závěr?
Pokud už nemáte mysl zatíženou žádným z výše uvedených mýtů, můžete mnohem lépe vnímat rozdíl mezi HTML a XHTML. Lépe řečeno můžete lépe vnímat, že tam žádný rozdíl není. Skutečný rozdíl se odehrává až o patro výše: je jím opuštění SGML a přechod k novému XML.
Bohužel nelze říci, že XML pouze řeší problémy SGML a žádné nové nepřidává. Jen v tomto článku jsem na dva narazil. Jedním z nich je drakonické zpracování chyb v XML, které není v souladu s praxí, a tím druhým je existence odlišného jazyka DTD uvnitř XML, které komplikuje parsování i srozumitelnost XML dokumentů. Navíc vyjadřovací schopnost tohoto jazyka je tak malá, že nedokáže formálně postihnout ani samotné XHTML, takže některé vlastnosti je nutné dodefinovat zvlášť. U jazyka, který není svázán historickými okovy, je to smutné a zarážející zjištění. Kritika XML je však téma na samostatný článek.
(Pokud narazím na další mýty, budu článek postupně doplňovat. Budete-li chtít na ně odkazovat, můžete využít toho, že jednotlivé titulky mají vlastní ID)