Přejít k navigační liště

Zdroják » Webdesign » XHTML je mrtvé! Ať žije HTML5! Nebo ne?

XHTML je mrtvé! Ať žije HTML5! Nebo ne?

Články Webdesign

Před deseti lety bylo moderní dělat weby v XHTML a v tento jazyk byly vkládány velké naděje. Pak nastalo jisté vystřízlivění a s mohutnou propagací HTML5 v posledních několika letech i jisté zatracení XHTML. Nenechme se však zmást. HTML5 a XHTML se nevylučují, naopak specifikace HTML5 je v mnoha ohledech nejlepší specifikací XHTML, jaká kdy existovala.

Vývoj syntaxe HTML/XHTML

Pro lepší pochopení souvislostí se na chvíli vydáme do historie jazyka HTML. Při návrhu první verze jazyka HTML se jeho autor Tim Berners-Lee inspiroval jazykem SGML. SGML je poměrně složitý jazyk pro definici dalších značkovacích jazyků. Z tohoto důvodu se již od dob prvních prohlížečů nepoužívá pro čtení HTML plnohodnotný parser SGML, ale mnohem jednodušší parser HTML.

Další verze jazyka HTML, počínaje verzí HTML 2.0 a konče verzí HTML 4.01, definovaly syntaxi jazyka právě odvozením od SGML. Prohlížeče však stále používaly specializované parsery HTML. Jejich složitost navíc neustále rostla, protože se snažily co nejlépe automaticky vypořádávat s chybami v kódu. Webové stránky chtěl psát každý, takže se běžně stávalo, že tu nějaký tag chyběl, tu se někde neukončila hodnota atributu,… Takový syntakticky špatný kód se začal označovat pěkným termínem „tag soup“.

Na konci devadesátých let minulého století se pak časově sešlo několik faktorů, které ovlivnily další směřování jazyka HTML:

  • potřeba bezpečného rozšiřování jazyka (žádné divoce přidávané elementy jednotlivými výrobci prohlížečů jako dříve);

  • snaha o vymýcení syntakticky nekorektních stránek;

  • snaha o sjednocení toho, jak je syntaxe definována a jak je skutečně zpracovávána prohlížeči;

  • snaha o zjednodušení parseru, tak aby jej bylo snazší provozovat na zařízeních s omezenými zdroji.

V té době se jako správná cesta pro řešení těchto požadavků zdálo XHTML. Elementy a atributy jazyka HTML se nechaly beze změny, jen se řeklo, že syntaxe musí splňovat přísnější pravidla XML. Oproti SGML je XML jednoduché, existuje spoustu hotových parserů, takže výrobcům prohlížečů teoreticky nic nebránilo v tom je použít a celkem snadno implementovat podporu XHTML v prohlížeči.

Bohužel cíle XHTML se dílem kvůli nedomyšlené specifikaci a dílem kvůli šlendriánu výrobců prohlížečů nepodařilo dosáhnout. Cílem článku není podrobně se zabývat přínosy a problémy XHTML. Připomeňme však alespoň nejdůležitější fakta. Hlavní problém XHTML byl v tom, že přinášelo mnoho problémů, ale nenabízelo žádné nové funkce a elementy, kvůli kterým by stálo za to vypořádat se s problémy jazyka.

Netolerantní XHTML

Z historie přístupů k ošetření chyb na webových stránkách

Asi největším problémem XHTML byl přístup implementací k obsluze chyb. Sebemenší syntaktická chyba v dokumentu vedla k odmítnutí jeho zpracování. Představme si jednoduchou XHTML stránku s překříženými elementy:

<?xml version="1.0" encoding="utf-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="cs">
  <head>
    <title>Pokusná XHTML stránka s chybou</title>
  </head>
  <body>
    <p>A <b>teď to <i>přijde</b></i>.</p>
    <p>Druhý odstavec</p>
  </body>
</html>

Bohužel, když se podíváme, co místo této stránky zobrazí webové prohlížeče, není výsledek zrovna radostný. Každý zobrazí něco jiného a navíc naprosto neužitečného pro běžného konzumenta stránek.

Internet Explorer
Firefox
Chrome
Opera

Příčinou tohoto striktního chování prohlížečů je poněkud úzkoprsý výklad specifikací XHTML a XML. Prohlížeče používají tzv. „draconian error handling“ – jakmile je na stránce sebemenší chyba, stránka se dále nezpracovává. Proč by však autor webových stránek na sebe dobrovolně pouštěl bič striktní syntaxe XHTML, když mu to nepřinese žádné nové možnosti.

Dalším problémem XHTML bylo, že ve svých verzích 1.0 a 1.1 nepřinášelo žádnou novou funkcionalitu oproti HTML 4.01, která by motivovala vývojáře k přechodu. Navíc specifikace XHTML byla napsaná v některých místech tak nešťastně, že formálně znemožňovala si do XHTML přidávat nové elementy/atributy, což měla být jedna z výhod nového jazyka.

Nicméně pokud bychom hledali hlavního viníka neúspěchu XHTML, budou to výrobci prohlížečů. Ač bylo na začátku nového milénia XHTML masově propagováno, výrobce nejmenovaného prohlížeče podporu XHTML přidal až do jeho verze číslo 9, která vyšla letos – o pouhých 10 let později než měla. Ani alternativní prohlížeče však nemají ohledně XHTML čisté svědomí. Kromě již zmíněné uživatelsky nešikované obsluhy chyb, bylo zpracování XHTML věnováno mnohem méně péče než HTML. Například se XHTML stránky dlouhou dobu vykreslovaly pomaleji než HTML, protože se čekalo až se celá stránka načte do paměti a teprve kompletně vybudovaný DOM se poslal k vykreslení. U HTML se přitom vykresluje stránka postupně během načítání. Podobný mechanismus se pro XHTML do prohlížečů dostal až v roce 2006.

HTML5 – napravíme 15 let staré problémy

O HTML5 se poslední čtyři roky mluví stále častěji, někdy možná až moc často. Rozebírají se nové možnosti pro práci s multimédii, nová javascriptová API usnadňující tvorbu webových aplikací nebo se ukazují oslňující grafické efekty v prohlížeči (ty však nemají přímo s HTML5 moc společného, jedná se většinou o funkcionalitu CSS3 a SVG). Nikde se však nedočtete, že by se snad vaše HTML5 stránka neměla zobrazit, pokud v ní někde uděláte malý překlep.

Dnešní rozruch okolo HTML5 je naprosto pochopitelný. I když některé části HTML5 nejsou zdaleka stabilní, i tak pořád zbývá spoustu nových užitečných funkcí, které podstatně ulehčí tvorbu moderních webových stránek a aplikací. O výhodách samotného HTML5 a přechodu na něj tak není potřeba téměř nikoho dlouho přesvědčovat.

V mnoha článcích o HTML5 se dočtete, že jazyk navazuje na „staré dobré“ HTML 4.01, že XHTML se nepovedlo. Ona to přitom není tak úplně pravda. HTML5 sice původně vzniklo jako reakce na vývoj nové verze XHTML 2.0, která zcela rušila zpětnou kompatibilitu a odtrhla se tak zcela od reality běžného webového vývojáře i výrobce prohlížeče. HTML5 je přitom v tomto ohledu velice konzervativní, snaží se navázat na existující osvědčené postupy a jen je vylepšit nebo lépe definovat.

Proč je algoritmus čtení a analýzy HTML5 tak složitý?

Oproti předchozím verzím HTML je přesně definováno, co se má stát (jak se konstruuje DOM) v případě, že je ve stránce syntaktická chyba. Navíc toto chování je navrženo tak, aby bylo co nejvíce v souladu s chováními existujících prohlížečů. Hodně zjednodušeně řečeno se jedná o algoritmus, který vznikl studiem chování IE6 metodou reverzního inženýrství.

Duální syntaxe HTML5

Zcela v tomto duchu tak HTML5 nabízí možnost stránky zapisovat dvěma různými způsoby. První syntaxe navazuje na klasické HTML, kde se například nemusí uzavírat většina elementů. Na rozdíl od dřívějších verzí HTML však jazyk není formálně definován pomocí SGML. Místo toho je velice přesně definováno, jak se mají prohlížeče chovat i v případě, že naleznou chybu v kódu HTML. Tím by mělo být zaručeno konzistentní zpracování stránek v různých prohlížečích. Konečně se tak formální definice jazyka sjednotila s praxí.

V některých aspektech je tato syntaxe dokonce jednodušší než HTML 4.01, zejména v oblasti nastavení !DOCTYPE nebo určení kódování.

HTML5 HTML 4.01
<!DOCTYPE html>
<html lang="cs">
  <head>
    <meta charset=utf-8>
    <title>Pokusná stránka v HTML5</title>

  </head>
  <body>
    <p>A <b>teď to <i>přijde</i></b>.</p>

    <p>Druhý odstavec</p>
  </body>
</html>
<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'>
<html lang="cs">

  <head>
    <meta http-equiv="Content-type" content="text/html;charset=utf-8">
    <title>Pokusná stránka v HTML</title>
  </head>
  <body>

    <p>A <b>teď to <i>přijde</i></b>.</p>
    <p>Druhý odstavec</p>

  </body>
</html>

Pokud však ve stránce uděláme nějakou chybu, třeba překřížíme elementy, specifikace HTML5 přesně říká, jak se má v takovémto případě zkonstruovat DOM a v různých prohlížečích tak dosáhneme konzistentního zpracování a zobrazení stránek.

Co však už na HTML5 není tolik známé, je možnost stránky nezapisovat v HTML syntaxi, ale pomocí syntaxe XML – tedy v XHTML. K dispozici máme všechny nové elementy a funkce HTML5, ale pokud z nějakého důvodu preferujeme striktnější syntaxi XML, nic nám nebrání. Pro stručné označení HTML5 kódu používajícího syntaxi XML se často používá označení XHTML5. Pokud tedy z nějakého důvodu preferujeme striktnější syntaxi, můžeme předchozí ukázku zapsat jako

<?xml version="1.0" encoding="utf-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="cs">
  <head>
    <title>Pokusná stránka v XHTML5</title>
  </head>
  <body>
    <p>A <b>teď to <i>přijde</i></b>.</p>
    <p>Druhý odstavec</p>
  </body>
</html>

Specifikace HTML5 přitom řeší některé dřívější problémy spojené s XHTML. V maximální možné míře se sjednotil způsob vytvoření DOM reprezentace dokumentu pro vstupy v HTML5 a XHTML5. Byly odstraněny některé historické relikty jako nutnost používat !DOCTYPE v XHTML5.

Pro zjištění toho, zda nějaká stránka splňuje formální pravidla HTML5 nebo XHTML5, lze stejně jako u předchozích verzí využít různé validační služby. Klasický validátor konsorcia W3C (validator.w3­.org) už HTML5 podporuje, ale v tuto chvíli je lepší používat validator.nu, který pružněji reaguje na rychlý vývoj specifikace HTML5.

Pokud jste si z nějakého důvodu na otázku „Budu používat striktnější syntaxi XHTML5?“ odpověděli „ano“, zdá se, že s HTML5 máte vyhráno. Není to však tak úplně pravda. XHTML5 tak, jak jsme ho dosud předvedli, funguje dobře v novějších prohlížečích, které přímo podporují XHTML zasílané s odpovídajícím MIME typem  application/xhtml+xml.

Některé starší prohlížeče však XHTML nepodporují a pak je potřeba se uchýlit k postupům, kdy do prohlížeče posíláme XHTML kód se špatným MIME typem text/html, a prohlížeč jej proto čte jako trochu chybné HTML a nakonec většinou získá výsledek, který jsme zamýšleli. Na tuto problematiku a nové možnosti, které v tomto směru přináší HTML5, se proto podíváme někdy příště.

Komentáře

Subscribe
Upozornit na
guest
92 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
David Grudl

V prvé řadě děkuji za skvělý a faktograficky přesný článek. Doplním jen několik (subjektivních) poznámek.

ad „Netolerantní XHTML“: nejzávažnější vadou tohoto přístupu bylo, že postihovala nikoliv „viníka“, ale koncového uživatele. Ono ani nebylo v moci autora stránky zajistit její 100% bezchybnost – stránka se mohla nedotáhnout celá (uživatel to přerušil), občas se v cestě vyskytla proxy, která měla potřebu kód nějak upravit a tím pádem rozbít. S tím souvisí i důvod, proč se stránky XHTML načítaly pomalu, proč se čekalo, až se celá stránka načte. Tvůrcům prohlížečů nejspíš připadalo divné stránku uživateli postupně vykreslovat a pak ji při chybě na konci dokumentu (nebo timeoutu) zahodit a ukázat mu faká …ehm… parse error.

ad „zjednodušení parseru“: kvůli nešťastnému DOCTYPE je parser XHTML ve skutečnosti o dost složitější, než by byl hypotetický (!) drakonický parser HTML. Přičemž DTD používané v době vzniku XHTML nedokázalo XHTML ani formálně popsat, což je jemně řečeno ostuda.

Jako viníka bych proto viděl jednoznačně specifikaci. Dělat prohlížeč vycházející vstříc uživatelům nutně znamenalo, kvůli uvedenému, porušovat specifikaci a jsem rád (a je to i pochopitelné), že zvítězil rozum nad W3C.

František Kučera

Ad „Ono ani nebylo v moci autora stránky zajistit její 100% bezchybnost – stránka se mohla nedotáhnout celá (uživatel to přerušil), občas se v cestě vyskytla proxy, která měla potřebu kód nějak upravit a tím pádem rozbít.“

Chápu přístup, že je lepší (alespoň někdy) zobrazit alespoň rozbitou stránku, než nezobrazit nic… ale s tvými argumenty nesouhlasím: jestliže stahování přerušil uživatel, tak je to jeho věc (navíc úplně špatně by to dopadnout nemělo) a co si myslím o proxy serverech manipulujících s obsahem stránek, jsem tu už jednou psal.

Sten

Ty proxy servery mohou poskytovat užitečné informace (třeba že vám brzo vyprší připojení v kavárně), ale když už manipulují se stránkou, tak ať se jejich autoři alespoň naučí parsovat (X)HTML.

František Kučera

Když je to kavárna se stolními počítači (ne WiFi, kam si lidi nosí vlastní), tak mi přijde zvěrstvo to cpát do www stránek – ten ukazatel času může být desktopová aplikace shozená na liště, nebo ještě lépe třeba plasmoid v KDE panelu, který ukazuje zbývající čas.

A když je to WiFi: proč to dělat složitě, když to jde jednoduše? Proč manipulovat s cizími stránkami? Navíc při použití HTTPS to stejně nepomůže, takže uživatel se nedozví, že mu vyprší limit. Měla by to být normální stránka, kterou si uživatel otevře v jiném panelu/okně – a taky o sobě může dát vědět, když končí limit (např. Firefox mi ten panel obarví modře, když mi přijde do webmailu zpráva).

Proxy, která upravuje stránky, považuji za úplně poslední možnost a nikdy by na ni nemělo dojít – ale pokud ano, tak souhlasím s tím „ať se jejich autoři alespoň naučí parsovat (X)HTML.“

Oldisy3

mne se libi ze to zarve kdyz se upisu, preci jen by na to mel prohlizec, protoze je take vyvojovim prostredim, zarvat ze dostal spatne xml.

Mordae

‚hoj, mam za to, ze i u XHTML5 chceme doctype, tedy:

<?xml version="1.0" encoding="utf-8"?><!DOCTYPE html>
<html>...
ano

… ono by tak ukázka pak nedávala smysl, protože by to byla ukázka XHTML1 a ne XHTML5.

juraj

Prehliadače poznajú jedinú verziu, prosté XHTML. Nemá zmysel rozlišovať verzie.
A ani z toho zbytočného teoretického pohľadu nemáš pravdu, v XHTML5 je použitie doctype povolené.

petr_p

Minimálně Mozilla, která celý svůj prohlížeč vystavěla na XML, vidí XHTML mrvté. Odstranili podporu pro XLink, teď když konečně začali přepínat slovník podle přirozeného jazyka elementu, tak na @xml:lang se velmi slušně řečeno vybodli. Přitom XML má celou řadu krásných specifických jmenných prostorů, jejichž funkcionalitu budeme do HTML5 opět back-portovat a bít se v prsa, jak se nám HTML5 krásně vyvíjí a reaguje na požadavky uživatelů.

Rado2

mne sa skôr zdá že XHTML zlyhalo, lebo nič riešilo. Aspoň ja nevidím potrebu parsovať výstup bežného webu. A ak to niekto potrebuje, tak ako si môže dať námahu napísať platné XHTML, môže napísať aj platné HTML (alebo v niektorých prípadoch ešte lepšie CSV a pod.), akurát použije inú knižnicu na parsovanie.

František Kučera

Ad „Aspoň ja nevidím potrebu parsovať výstup bežného webu.“

Ty možná ne, ale prohlížeč to dělat musí. A načítat chaos a hnůj a domýšlet se, co tím asi autor chtěl říct, dá víc práce, než načítat čistý kód, který vyhovuje předem daným pravidlům.

Rado2

Ale kvôli ostatným miliónom webov aj tak musí vedieť načítavať hnoj a ešte raz ten, komu na správnosti záleží, môže napísať správny HTML kód. Nebolo potrebné vymýšľať novú syntax, stačilo pridať možnosť odmietnuť nevalidný HTML tak ako nevalidný XHTML. Navyše parsovanie na tejto úrovni je prkotina oproti interpretovaniu významu značiek a štýlov.

juraj

Myslím, že to nemá zmysel riešiť v dobe, keď sú parsery dávno napísané; argumentovať týmto bolo pádne v dobe, keď vznikal prvý prehliadač a prvé HTML stránky. Navyše XML parsery nie sú také jednoduché, ako sa môže zdať.

František Kučera

A co bys navrhoval? Zrušit &entity;? Používat jen zápis ve tvaru &#160;? Já entity téměř nepoužívám, ale hodně lidem by asi chyběly…

juraj

Prečo by som mal niečo navrhovať? XML parsery sú dobré také, aké sú. Len som sa ti snažil vyvrátiť tvoju mylnú domnienku, že parsovať XML je oveľa jednoduchšie ako parsovať HTML.

Pavel Lang

Parsovat xml je jednoduché a udělá to stavový automat. Na rozdíl od html(SGML) u xml parser nemusí zajímat jakou značku otevírá (párovou vs nepárovou) aby věděl, kde DOM uzel končí a zda začíná child nebo sibling. Celé parsování je pak otázkou jednoho charu v paměti – aktuání znak a jednoho bytu – stav a switche na rozhodnutí o předání tokenu factory stavějící DOM, která už může (teoreticky) vykreslovat od prvního elementu dokumentu a ne až se DOM načte, jak se zde tvrdí. Bohužel implementace XHTML je vážně tak špatná, jak se píše, není to vina XML ale tvůrců prohlížečů.

a entity? prkotina, vestavěné mohou být zakompilované (amp, lt, gt, apos, quot), ty ostatní (uživatelsky definovené) se dají do hashe a je to.

XSD, XSLT, XPath a další na xml založené (SVG, XMPP) jsou opravdu použitelné a v kombinaci s CSS a ECMA/Javascriptem by nebylo těžké vytvářet uživatelské komponentní nadstavby nad XHTML.

Ještě by to chtělo, aby existoval mechanizmus který by pomocí namespace URI mohl najít XSD a případně výchozí XSLT šablonu

DTD bych zrušil a nahradil XSD

David Grudl

To je pravda jen zdánlivá.

> xml parser nemusí zajímat jakou značku otevírá (párovou vs nepárovou) aby věděl, kde DOM uzel končí

XML parser ve skutečnosti nezná význam ani tzv. entit (krom číselných a několika málo pevně daných). Aby mohl XHTML naparsovat, musí načíst DTD, bez něj nelze obecný XHTML dokument vůbec přečíst. Každý prohlížeč je má pochopitelně zadrátované v sobě. A kdyby se v DTD krom významu entit nadefinovalo i to, že určitý element je nepárový, nebylo by vůbec nutné používat /> v XHTML dokumentech. A přitom by se parser nijak nezkomplikoval.

František Kučera

A v čem je lepší nepsat tam to lomítko?

David Grudl

Přirozeně bývá lepší nemuset dělat zbytečné věci.

Ale tohle byla reakce na složitost a obecnost parseru.

František Kučera

Myslím, že jedno lomítko nikoho nezabije*. Když ho tam nenapíšeme, tak ten, kdo to bude číst, musí vědět, že zrovna XYZ je nepárová, protože jinak by hledal koncovou značku, která tam není.

*) zvlášť v kontextu toho, že se píše <script src="js/scrip­ts.js"></scrip­t> místo <script src="js/scrip­ts.js"/>. Na tom je pěkně vidět, že je hloupost dělit značky na párové a nepárové, protože jedna značka může být současně párová i nepárová (třeba v závislosti na tom, jestli se data načítají z externího souboru nebo jsou přímo v dokumentu), a je lepší se řídit tím, jestli je tam />, než tím, jak se element jmenuje (což vyžaduje, abychom měli někde sepsané, jak se která značka chová – a to pro pouhé parsování dokumentu). Přijde mi lepší mít jednoduchá obecná pravidla než milion výjimek.

Pavel Lang

přesně, třeba zrovna u toho script tagu jsem už intuitivně začal psát <script src=“…“ /> s tím lomítkem na konci že nebudu muset opisovat celou koncovou značku a ono ejhle, ono to takhle nefunguje! To se potom ukazuje nesystematičnost v HTML na úrovni, kde by to nikdo nečekal. A názory typu HTML musí být takové, aby se i poškozené dalo zobrazit mi přijdou totálně mimo.

Autor (X)HTML dneska nemá ani možnost si ověřit pomocí malinkého toolu jako třeba pomocí XSD schema zda jeho dokument je nejen well formed, ale také validní. DTD moc nefandím, XSD umožňuje přesněji definovat strukturu.

Příkladem dobré práce s XML je XMPP protokol a rozšíření XEP. Ano i zde se najdou chyby a ukázky toho, jak by se to dělat zrovna nemuselo, ale ke každému rozšíření je hezky schema podle kterého se dá validovat a podle toho označit přesně viníka při nějaké nesprávné komunikaci.

juraj

Toto nie je o nesystematickosti, ty proste preberieš prvok z iného jazyka a hneváš sa, že v HTML nefunguje. Je to taká istá logika, ako keby som povedal „píšem si XHTML, intuitívne použijem <option selected> a ejha, prehliadač mi ohlási syntaktickú chybu. Fuj, to X(HT)ML je ale nesystematické.“ A áno, naozaj je ten princíp úplne rovnaký.
S tým, že XMPP protokol je dobre využité XML, súhlasím. Ale čo sa týka webu, HTML je lepšou voľbou.

Pavel Lang

Souhlasím že jsou to dva odlišné jazyky, pomocí obou lze vyjádřit stejný DOM strom, u HTML musí být známé DTD při parsování, u XML nemusí být známé schema pro parsování. To je ve sporu s tvrzením, že HTML je „lepší volbou“ (byť třeba jen pro web), protože vyjadřovací schopnost je stejná. (Troufám si ale tvrdit, že díky namespacům je právě XML „lepší“ v možnosti vyjádření sémantiky (používání různých mikroformátů, vkládání strukturovaných dat v jejich přirozené podobě…))

Uvítal bych ale nějaké sbližování syntaxe, třeba v HTML je chybný zápis <br/>, který ale projde; v XML je zápis <br> bez párového tagu fatální chybou. Snažím se jít s XML, takže píšu nevalidní HTML.
Alespoň ty skrypty aby šly vkládat bez nutnosti pouze párově uzavírat script tag.

Timy

Zápis
kupodivu v HTML chybný není. http://atd.havrlant.net/zkracene-html-zapisy

Pavel Lang

Uff, to jsou ale šílenosti :-) pěkná ukázka toho, co všechno by měl HTML parser zvládat, podpora těhle „fíčur“ je zase někde jinde (v některých případech je to asi dobře :-) )

Pavel Lang

Přece jen jsem ale nenašel v tom článku zmínku o empty elementu, tedy zápis <script src="..."/>, rychlým googlením jsem našel, že empty element byl zanesen do HTML omylem a zápis je nejednosnačný s NET zápisem SGML (uvedeným třeba v článku, na který odkazuješ, př.: <em/foo/ namísto <em>foo</em>). To znamená, že empty element dělá v HTML problémy. Zápis nazvaný empty end tag (pouze </>) by se zase hodil do XML, většina je stejně strojově generovaná, ale v kombinaci s kompresí (deflate, gzip) by úspora téměř nebyla znatelná.

Pavel Lang

Přesně! Třeba zrovna u toho script tagu jsem už intuitivně začal psát <script src=“…“ /> s tím lomítkem na konci že nebudu muset opisovat celou koncovou značku a ono ejhle, ono to takhle nefunguje všude! To se potom ukazuje nesystematičnost v HTML parseru na úrovni, kde by to nikdo nečekal. A názory typu HTML musí být takové, aby se i poškozené dalo zobrazit mi přijdou totálně mimo.

Autor (X)HTML dneska nemá ani možnost si ověřit pomocí malinkého toolu jako třeba pomocí XSD schema zda jeho dokument je nejen well formed, ale také validní. DTD moc nefandím, XSD umožňuje přesněji definovat strukturu.

Příkladem dobré práce s XML je XMPP protokol a rozšíření XEP. Ano i zde se najdou chyby a ukázky toho, jak by se to dělat zrovna nemuselo, ale ke každému rozšíření je hezky schema podle kterého se dá validovat a podle toho označit přesně viníka při nějaké nesprávné komunikaci.

Pavel Lang

Omlouvám se za double post, prosím redakci o smazání…

juraj

Argumentácia je to celkom logická, ale nevidíš všetky dôsledky toho, že by ste chceli zabiť nepárové tagy.
<input xmlns="http:/­/www.w3.org/1999/xhtml" value="foo">bar</in­put>
Aj koncové zariadenie, ktoré by poznalo len X(HT)ML, potrebuje zoznam výnimiek, aby vedelo, že zrovna v tomto prípade nemôže text „bar“ zobraziť. Nie je to výnimka, ktorá sa uplatní pri parsovaní, ale je to výnimka týkajúca sa renderovania.

Pavel Lang

Teď nechápu. Snad tady o zabíjení nepárových/párových tagů nemluví, ne? Zrovna v tomto případě by zařízení, které nerozumí tagu input zobrazilo text bar místo „inputu“, takové zařízení by asi nikdo nechtěl :-)

Spíš by se hodilo v HTML možnost říct, tak jako v XML, tady ten párový tag nemá obsah, protože končí sekvencí lomítko většítko…

A ano, zařízení musí vědět, jak renderovat DOM, ale nemusí řešit jak DOM poskládat na úrovni parseru, ale až někde za ním, lze oddělit implementaci. Za rok někdo přijde s jazykem EXML nebo BinML, udělá plugin pouze s parserem, který poskládá DOM, plugin 10 kB a ono to bude fungovat :-)

juraj

No ja som teda Frantu Kučeru pochopil tak, že mu vadí, že HTML parser si musí pamätať, ktoré elementy majú len otváraciu značku (aby nehľadal ich koniec), čo by rád riešil zavedením <tag/> sekvencie pre prázdne elementy (čiže to isté chovanie, ako v X(HT)ML), v nádeji, že potrebe takýchto výnimiek sa dá predísť. Len som teda chcel ukázať, že také ľahké by to nebolo ;-)

Pavel Lang

Aha… no po HTML parseru bohužel nikdo nemůže chtít, aby se nepárové značky musely ukončovat „/>“, já bych po něm jenom chtěl, aby tuto sekvenci vnímal jako explicitní vyjádření (nepárové) značky bez obsahu ve smyslu:
<div id="mujSuperJa­vascriptGenero­vanyObsah" /> je prazdny div a ekvivalent
<div id="mujSuperJa­vascriptGenero­vanyObsah"></div> pokud se nepletu, tak se to v HTML chape ne jako prázdný element, ale jako otevírací značka elementu, která se implicitně ukončí až díky systému ošetřování chybného kódu.

to by se parsery HTML naucit mohl, je to validni XML, ale asi nevalidni HTML. Samozřejmě že by změna byla zpětně nekompatibilní, ale za pár let po zavedení by se už tahle syntaxe mohla používat.

Nempluvě o starém IE, který prázdný element občas umí „vyhodit z renderování“, to je chování úplně na palici, vždycky mě to vypeče :-D

František Kučera

K té zpětné kompatibilitě: prohlížeče/parsery toto chování můžou zavést hned* (proč to tam není už dávno?) a autoři stránek to mohou začít používat až bude dostatečná podpora v cílových prohlížečích (takže kdo píše pro moderní prohlížeče, ten by to začal používat brzy, kdo chce co největší podporu, by s tím počkal – jako s každou novou vymožeností).

*) nebo je snad jiný důvod, proč by někdo psal />

, než že chce prázdný/nepárový element?

Pavel Lang

Přesně tak, jiný důvod není. Pěkný odkaz na článek o HTML značkách poslal Timy o pár příspěvků zpět. (zde); Ukončení párového tagu sekvencí lomítko většítko je v HTML validní, což jsem nevěděl, jak je to s podporou prohlížečů nevím pořád.

Doufám, že většina těch věcí byla myšlena vážně asi jako HTTP response kód 418 (viz HTCPCP – RFC 2324)

Ale zase ten samý problém. Jak získat jistotu, že to bude v prohlížečích fungovat? Dělat to tak, jak se to dělalo s weby často. Dva kroky vpřed, jeden vzad :-(

Pavel Lang

Oprava: empty element v HTML validní NENÍ

bauglir

Ach jo…. nevím sice o kterém HTML mluvíte ale HTML5 definuje void elementy (elementy bez obsahu, které lze ukončovat sekvencí />) zcela jednoznačně.

Pavel Lang

Omyl, pokud se pletu prosím o referenci. Void tagy jsou vyjmenované (W3C), nikoliv na požádání.
Patří mezi ně area, base, br, col, command, embed, hr, img, input, keygen, link, meta, param, source, track, wbr a ty naopak NESMÍ mít end tag. Nikde jsem ale nenašel, že takto mohu uzavřít přeba script tag nebo jakýkoliv párový.

bauglir

Aha, tak to jsem se nepochopili :), já měl na mysli, že píšete, že žádné nejsou povolené :). Váš odkaz je přesně zdroj informací, který popisuje, že void elementy v HTML5 jsou :). Ale ano… nelze takovou syntaxi použít pro jakýkoliv.

Pavel Lang

Přesně, v tomto threadu se o tom bavím už až nesmyslně dlouho :-)

Třeba u toho script tagu by se to mooc hodilo, bohužel SGML historický odkaz to znemožňuje. Stejně by mě zajímalo, jací hackeři dodnes používají třeba tu NET syntaxi, nikde jsem ji neviděl :-)

Rozhoduju se teď zrovna mezi HTML5 a variantou XHTML (a jsem čím dál tím víc zmatený, neb XHTML5 není schválený název, ale spojení, které se spontálně vyvinulo (XHTML5 ne, protože ne XHTML2+))

Zatím jediný rozdíl mezi HTML5 a HTML5+XML (se mě líbí nejvíc) je nepodpora noscript tagu v XML variantě (ale co, udělám div s id noscript a javascriptem smažu…) a problém se „správným“ Content-Type: application/xhtml+xml (taky nevím, proč to není application/xml+xhtml nebo text/xml+html <- poslední by dávalo nejvíce smysl)

Další problém je najít problémy, které může XML+HTML5 přinést

bauglir

Obecně, HTML5 je název specifikace jazyka, existuje HTML a XHTML serializace jazyka s názvem HTML5, aby v tom byl ještě větší bordel :) Takže není potřeba se rozhodovat mezi HTML5 a XHTML, ale vzít HTML5 a rozhodovat se mezi HTML a XHTML serializací.
Já se obecně snažím psát v XHTML (mám v tagách větší pořádek), ale ve finále to je HTML, pač to posílám jako text/html… a důvod je nasnadě: MSIE :)

Ale to by bylo jednoduše řešitelné: použít XHTML a na serveru se podle user agent rozhodnout, co budete posílat za content-type :)

Pavel Lang

bohužel do puntíku dělám to samé, ale podle ‚Accept‘ HTTP requestu.
XML mám rád :-). Jinak v XML serializaci je void element povolený samozřejmě jakýkoliv. Jde mi spíš o to aby se validní XHTML dokument automaticky stal validním HTML dokumentem => XHTML by bylo podmnožinou HTML, tak to ale zatím není :-(

David Grudl

Unavuje mě reagovat na někoho, kdo čte natolik nepozorně, takže jen připomenu, že o dva komentáře výše píšu, že parser XHTML se stejně bez „sepsaných pravidel“ neobejde.

bauglir

Tak jedna věc je parsování XHTML na základě XML a druhá validace proti HTML5 specifikaci :). Obecně parser + validátor HTML je jednodušší, než parser + validátor XHTML

Pavel Lang

Víte, proč XHTML vůbec vznikalo? Bylo to právě kvůli rozdělení parseru (jednodušší pravidla pro jádro XML – odmyslete nutnost DTD podpory) a stavění DOM stromu, což by vedlo ke krásnému rozdělění a zobecnění kódu pro parser

František Kučera

Spíš jedna věc je načíst (parsovat) dokument a sestavit z něj DOM a druhá věc je na základě toho DOMu vykreslit něco v GUI. Pro to první nemusím znát nic víc než obecná pravidla – pro to druhé už samozřejmě musím vědět, jaký je význam jednotlivých značek, např. že <textarea/> se kreslí jako textové políčko, zatímco <p/> je obyčejný odstavec textu.

David Grudl

Tak fajn, napiš mi DOM vzniklý parsováním řetězce <xml>&zahada;</xml>

Pavel Lang

bez znalosti obsahu entity zahada neni zapis validni.

DOM nicmene je:

xml
  +-- [unknown entity "zahada"]

právě proto, že entita nemůže obsahovat DOM uzly (a budu se to domnívat dokud mě někdo nepřesvědčí o opaku)

David Grudl

Entita může obsahovat uzly a o tom to cele je. Jiste si to uz ve specifikaci najdete sami .

František Kučera

Tento řetězec neobsahuje dostatek informací, musíš dodat platné XML. Ale až ho dodáš, tak to není problém – stojí to na obecných pravidlech a nemusím vědět, že <safgsdfh/> bývá párová značka a <gjfdj/> zase nepárová, k tomu, abych načetl dokument resp. sestavil jeho objektový model.

David Grudl

Jaky je rozdil mezi entitou a elementem: u jednoho na obecna pravidla rezignujes, u druheho jsi rad, ze si s nimi vystacis. XML dokument je ale mixem obeho a jako celek je tim padem pomoci obecnych pravidel neparsovatelny. Tim vsechny argumenty padaji. Bez tabulky ani ranu. Zadne jednodussi parsovani.

Proste pokud by DTD reklo, ze INPUT a treba BR bude vzdy neparove, tak bude a nemusi se resit zbytecna lomitka a svet by byl o miliony zbytecnych diskusi jako je tako chudsi :)

Pavel Lang

Entita je slovníková náhrada obsahu, myslel jsem si, že pouze textu ale i kdyby značek, lze DOM po resolvení entity naklonovat z prototypu. Stále jsem ale nenašel žádné použití vložení kusu DOM stromu do entity, takže na to moc nevěřím a specifikaci právě pročítám, ale už budu muset dělat něco užitečného, takže se na to vykašlu.

Mě celou dobu nejde o to, že by XHTML bylo (čistěji) „parsovatelnější“ než HTML (za tím si pořád stojím), jde mě spíš o to, že SGML je dávno mrtvé, nebýt HTML, svět žije s XML a i když ty jazyky vypadají strašně podobně, tak nikdo nemá snahu pár věcí, které se používají už jen historicky ve výskytu pod zlomky promile označit za nepodporované a přiblížit HTML jen o kousek k XML tím, že zavedeme prázdné značky, aby to třeba za 2-10 let bylo použitelné v produkci, zápis <script src=““ /> nebo <div id=“moje“ />, podpora namespaců z XML by také šla přenést tranzitivně, jako se to dělalo v HTML. Zápis <hr/> je zanesen do HTML omylem, protože ale HR je odjakživa void element, má parser vyjímku a nepovažuje tuhle značku za NET syntaxi, hnůj na hnůj, stejně jako naše zákony.

David Grundl je zkušený programátor a vůbec netuším, jestli odepisuju teď jemu, spíš ne, protože sem píše jako registrovaný uživatel, ale stejně, dnešní interpretované a polokompilované jazyky mají hash tak dobře optimalizovaný, že není důvod zadrátovávat cokoliv do kódu, pokud to není nutné. Výhody jsou ty, že se do hashe pro div uloží metoda/delegát/fun­kce továrny na HTMLDivElement, na Canvas, na HR prostě na cokoliv nějaký builder, který potom není zadrátovaný v kódu napřímo, což vede k čitelnosti a k tolik prosazovanému oddělení úloh různýh částí kódu..

Napsat parser na značky k XML je prkotina kvůli pouhým pár pravidlům, u HTML naopak se pro každý element zjišťuje zda je párový, zda to není NET zápis, zda to není ommit end tag, zda to není ommit start tag zda to není.. pár dalších věcí a zda to není chyba, která není ve standartu definovaná a každý vendor ji řeší jinak..

Kolik chybných XML dokumentů se dostane přes síť, než si někdo všimne, že tam je chyba? Téměř, žádný, protože to i patlal u sebe pozná, že tam je chyba. Kolik HTML „hnoje“ je na internetu? Už je to lepší, ale pořád toho je moc.

Jde o posun jednodušší <=> lepší. Je HTML jednoduché? … Je XML jednodušší? V základu je XML jednodušší.

David Grudl

Tento článek vysvětluje, že SGML se vlastně nikdy nepoužívalo, proto třeba ani žádný browser nerozumí NET zápisu (na něm je pikantní vlastně jen to, že popírá zpětnou kompatibilitu HTML s XHTML).

Problém XML je v tom, že má ve specifikaci řadu vážných nedostatků, některé si nese ze SGML (!), prostě to není žádná výhra, na to, že jde o nový formát. Například nelze v kódu ani zakomentovat libovolný text.

Taktéž vyrobit parser na XML je nesmírně složitý úkol, stačí se podívat na historii a složitost projektu libxml. Zkus říct jeho autorům, že parsování XML je hračka.

Pavel Lang

Díky, že máš se mnou trpělivost :-)

Jakto že nejde zakomentovat text, jde, ale komentář se stává součástí dokumentu a je jen na kódu dál, co se s tím komentářem stane dál (asi se zahodí, že?)

U libxml jde asi víc než jen o parsování, je tam spousta věcí, co se na XML nabalilo, vždyť na XML lze provádět transformace, několik různých možných validací, dotazování a vybírání, namespacy a nenapadá mě co všechno ještě.

A znova (a promiň), chtěl jsem jen, abych výstup z XML nástorjů mohl poslat jako HTML a bylo to kompatibilní, tedy aby existoval průnik obou jazyků, pročež by mi postačilo jen odmazat z XML dokumentu vygenerovaném v nástroji prvotní xml processing instruction s verzí, přihodit doctype html a nemuset přiřazovat značkám script prázdný string aby se vygeneroval otevírací a zavírací tag bez obsahu, protože textový obsah void značek (nevím jak java, ale třeba C# určitě) je null.

Každý prohlížeč stejně musí HTML rozumět, o tom jak rozumějí XHTML mám pořád pochybnosti, ale stejně píšu spíš XHTML, protože si to jednoduchým programem načtu a pak mám DOM, kde nemusím rozumět celé sémantice, ale zajímá mě jen jeden atribut (třeba class) a v něm jedna odpovídající hodnota (třeba samostatné slovo „T“) a pak mám textový obsah, který přez ten nástroj proženu a mám parádní statický obsah, který je slovníkově přeložený (jednou a bez další režije), výstup uložím jako XML (s příponou html) do příslušného adresáře a až někdo pošle přeloženou větu, tak vygeneruju zase jen jeden statický html soubor, který byde jak HTML tak XML validní. To ale teď není tak jednoduché a přitom by to někdo schopný dokázal dopsat do prohlížečů skoro tak stejně rychle, jak dlouho řešíme tuhle debatu :-)

František Kučera

Ale já na ně právě nerezignuji ani v jednom případě.

Entity fungují v XHTML, ale podle úplně stejného obecného principu se s nimi pracuje v SVG, ODT, ISDOC nebo v jakémkoli jiném podobném formátu, třeba nějaké proprietárním, který jsem si právě teď vymyslel. Pro změnu chování stačí změnit data (XML dokument + případně DTD), ale není potřeba měnit jediný řádek v programu (parseru).

Pro ten krátký zápis prázdných entit existuje taky univerzální pravidlo: značka končící /> a opět to funguje zcela obecně a parser zde nemusí rozumět významu jednotlivých značek a může zpracovávat libovolný formát.

A pak je tu třetí případ, kdy zapíšeme něco, co vypadá jako počáteční značka a na tu koncovou se už vykašleme a v nějakém textovém dokumentu (psaném přirozeným jazykem, strojově nezpracovatelným) je napsáno, že je to v pořádku – což není obecné řešení, ale řešení platné jen pro jeden konkrétní formát (HTML5) a vyžaduje, aby si programátor tento zvláštní dokument přečetl a upravil podle něj svůj software – jen proto, aby byl schopný sestavit DOM.

Až se bude v DTD (nebo nějakém podobném strojově čitelném formátu) uvádět, které značky jsou nepárové* a tak se to (možná) dá považovat za rozumné a obecné řešení – ale do té doby je to hnůj a rád si při zápisu prázdných elementů „vystačím“ s obecným pravidlem: />

*) ona tam může být informace, že element je vždy „EMPTY“, která by se k tomu dala použít… ale pak je potřeba, aby každý dokument obsahoval platný odkaz na DTD soubor (bez toho by to nefungovalo jako obecné řešení) a aby tomu parsery správně rozuměly. Ale i tak mi to přijde celé dost hloupé, protože některé značky mohou být jak párové, tak nepárové (script, object a další).

P.S. jen ještě připomenu, že tu řešíme (podle mého malichernost) jak psát <vždyPrázdnýE­lement> místo <vždyPrázdnýE­lement/> tzn. jak si ušetřit jedno písmenko. Ale tento přístup* vede k daleko větší neefektivitě a škodám, kdy se píšou značky, které bývají prázdné i neprázdné, vždy jako párové – např. <script src=“js/scrip­ts.js“></scrip­t>.

*) snaha definovat ne/párovost značek na úrovni jejich třídy (značka XYZ vždy párová, značka ABC vždy nepárová) nikoli na úrovni jejich instance (konkrétní značka XYZ je ne/párová podle toho jestli ne/končí na />)

Pavel Lang

Napsal jsi to tak, že bych to asi nenapsal lépe a snažím se o to tady dlouho… :-) Přesně. Jednoduchý kód dokáže zpracovat XHTML, ale HTML je plné vyjímek co se týče samotných značek a přidává to spoustu práce při tvorbě vlastního (jednoduchého a jednoúčelového) parseru.

David Grudl

> ale pak je potřeba, aby každý dokument obsahoval platný odkaz na DTD soubo

A každý XHTML dokument _musí_ obsahovat platný odkaz na DTD. Takže by tam ta informace být klidně mohla. Amen. (fakt už mě to nebaví opakovat)

Nic jako párové i nepárové značky v XHTML neexistuje. Ani script, ani object. I kdyby existovaly, neni, to duvod, proč by nepárové nemohly mít příznak EMPTY, např br.

Pavel Lang

Mě už to taky moc nebaví, ale pořád si nerozumíme.
Nevím, co nástroje vyčtou z <!DOCTYPE html []>.
A nikdo nemluví o párových a nepárových značkách v XHTML, ale v HTML a tam jsou (nepárové == void elementy); v HTML ale oproti XML nejsou explicitně vyjádřitelné empty elementy obecně, ale jen pár vybraných značek, které obsah obravdu mít nemohou (jen void elementy), právě jako odkaz NET syntaxe; povolené je (v HTML) třeba <hr/> ale už ne <script src="test.js" />

Pavel Lang

Parsovat a vytvořit DOM se dá rozdělit do dvou úloh v XML, v HTML je to úloha jen jedna. (Samozřejmě s komplikacemi se dá rozdělit i parsování HTML a výstavba DOM v HTML do dvou úloh.) O renderování tu nikde nebyla ani zmínka, to je úkol sám pro sebe velice obtížný.

Pavel Lang

To také není úplně pravda. Parser XML samozřejmě nemusí načítat DTD, nemusí načítat ani schema, ale pak jeho výstup je pouze strom bez té sémantiky (ale výstup je a je strojově lehce zpracovatelný).

Také je možné volat nějaký builder, který DOM vytvoří včetně výběru správných tříd pro uzly a efekt je stejný, kód čistý a rozšiřitelnost browseru.. krása sama.

Parser XML ale nemusí rozlišovat přechody stavů na základě jména tagu jak předpokládám to dnešní parsery HTML dělat musí.

Ad entity, ano základní a zadrátované v XML jsou pouze amp, lt, gt, quot a apos, dále pak jsou podporovány unicode číselné. Ostatní pojmenované definuje (HTML) DTD.

David Grudl

Co když je ale hodnou entity část DOM stromu? Ano, skutečně může být http://knowhow.davidgrudl.com/html/xhtml-hell/. Bez znalosti obsahu entity nemůže XML parser sestavit DOM.

Pavel Lang

Ano, toto je skutečně průšvih a co k tomu dodat. Jak se k tomu postavili autoři prohlížečů? na tento kód jsem se již díval…

Co jsem pochopil, specifikace umožňuje definovat entitu za pomocí odkazu na jiné entity, co se týče ale samotného markupu, tak ten by se měl chápat jako CDATA, tzn. použití <!ENTITY hello „Parser <b>nightmare</b>“> se vyrenderuje jako Parser <b>nightmare</b>

Nevím kterého v.la by napadlo vládat do entit markup, to snad ani ve W3C ne :-)

Tvojí námitku beru jako, že v tomhle nemám pravdu, tak jestli budeš tak hodný a navedeš mě, kde se píše opak, tak budu rád :-)

juraj

O niekoľko príspevkov vyššie som odkázal na článok na webylone, ktorý myslím zrozumiteľne vyvracia tvrdenie „Parsovat xml je jednoduché“. Čítal si ho?
Čo sa týka entít, asi si to nepochopil, ale nejde o to, aby sa nahradilo pár preddefinovaných ampersandových sekvencií príslušným znakom. Parsovanie internej podstaty DTD je vyžadované špecifikáciou a XML parser to musí vedieť, čo celú jeho prácu značne komplikuje (a to aj bez ohľadu na to, že by si DTD rád zrušil :-).

Pavel Lang

Ano, DTD je obluda a komlikace :-) ale zase bych to neviděl tak černě. Je to jazyk, k němu se dá udělat gramatika a parser a ten nebude o moc složitější než dnešní obludy v HTML, nehledě na to, že DTD parsery jsou stejně v každém prohlížeči již dávno implementovány, protože XHTML…

Viděl jsi zdrojáky třeba bluginu pro Firefox nebo Firefox samotný? DTD entity se používají pro lokalizaci řetězců, podobně jako je to v té ukázce na webylonu :-D

František Kučera

Ad „Je to jazyk, k němu se dá udělat gramatika“

Hlavně je to obecné a konfigurovatelné řešení, ne jako když někdo zadrátuje do softwaru, které značky jsou ne/párové a která entita co znamená – to je podle mého prasárna.

Pavel Lang

Přesně, když už zadrátované do kódu, tak na začátku s poznámkou:

This is generated by a tool... see original grammar here...

:-)

Marek Knápek
To je omyl

Aký hnoj? Skús to definovať. Rozdiel medzi HTML a X je v tom, že X pri chybe zlyhá, pričom je jasné, že tento prístup je z užívateľského hľadiska úplne zlý. HTML a X sú prakticky zhodné, takže ak je kód hnoj, nezáleží či je to hnoj v X alebo HTML. A prehliadač si nikdy nič nedomýšľa :-) táto demagógia sa používa často. Parser nepotrebuje žiadnu inteligenciu a funkcie pre domýšľanie, pravidlá sú jasné aj v tom „hnoji“.

RadekN

Nechápu dodnes,
proč je tolerováno dělat chyby v kódu. Pokud by byl od začátku striktní přístup, nebylo by nikdy tolik problémů.

acko

Přesně tak, pořád nad tím ještě kroutím hlavou.

Bubák

Chápu dnes, proč je tolerováno dělat chyby v kódu. Pokud by byl od začátku striktní přístup, nebylo by nikdy tolik webů.

Když si představím ten chaos, který by nastal kvůli tomu, že každý výrobce pojal pravidla striktnosti jinak, tak nezbývá, než parafrázovat známý výrok: „HTML není dokonalé, ale je to to nejlepší, co máme“.

Tak mě napadlo, bylo vy zajímavé, kdyby článek „Co prozradila homepage velkých českých serverů?“ obsahoval také informaci, jako procento z posuzovaných stránek je validní, jinak řečeno, nezobrazilo by při striktním přístupu.

František Kučera

Jedna věc je (ne)validní (např. chybějící alt atribut u obrázku) a druhá věc (ne)dobře formovaný (well-formed – např. překřížené značky nebo jinak rozbitý dokument).

NN

Otázka je, prečo chyby netolerovať?

Tolerovanie chýb v kóde je dané v prvom rade nepresnou špecifikáciou HTML. Prirodzený dôsledok tohto stavu je snaha výrobcov prehliadačov poskytnúť užívateľom čo najlepšiu funkčnosť a použiteľnosť ich prehliadača. Je to prirodzené.

Nechápem zástancov striktného prístupu. Ako užívateľ chcem, aby aj chybne zostavený dokument bol aspom čiastočne prístupný, podobne ako akýkoľvek iný prenosový formát, textový, zvukový, obrazový. Porovnanie HTML s programovacím jazykom považujem za absolútnu scestnosť a všetkým týmto zástancom striktného dodržiavania gramatiky by som prerušil prehrávanie CD alebo MP3 pri akejkoľvek drobnej chybe, ktorú by inak možno ani nepostrehli.

Že by si niekto kúpil video prehrávač, ktorý by pri chybnom kontrolnom súčte v dátach prestal prehrávať film bez toho, aby sa pokúsil o opravu alebo preskočenie chybnej časti? Možno nejaký sterilofilný masochista, vyžívajúci sa v ideále striktnosti a bezchybnosti. Bežný život je ale iný a prirodzenou súčašťou Matrixu sú aj chyby ;-)

lojza

Proč netolerovat? Protože to co se zobrazí může být špatně a nikdo nepozná, že je to špatně. CD a video formáty byly přímo navrženy, aby se definovaným způsobem z chyb vzpamatovaly (opravné kódy, různé typy snímků ve videu). A pokud je ten výpadek z pohledu formátu fatální, tak to video vypadne a ne že se tam něco domýšlí.

biggringo

Vypadne, ale hned jak je to možné se zase chytí a hraje dál.

alancox

„Nechápu dodnes, proč je tolerováno dělat chyby v kódu. Pokud by byl od začátku striktní přístup, nebylo by nikdy tolik problémů.“

Protože W3C. Protože to tak stanovilo W3C.

Jendoduše – banda hochštaplerů a neumětelů – napsala normu HTML, kde nestanovilo jak se bude přesně parsovat HTML. Kdyby W3C do první normy HTML napsalo, že na chyby v HTML se bude reagovat chybovým hlášeníám, tak to dnes je.

Stejně tak – přes vynikající článek – nesouhlasím s tím, že XHTML dopadlo špatně kvůli prohlížečům. Nikoli, kvůli W3C.

Každá norma – tedy pokud jí nedělá banda idiotů z W3C – vždy závazně stanoví základní gramatiku, stejně jako řešení chyb. Nedávno vyšla nová norma jazyka C++, podívejte se na ní a na kapitolu o gramatice a parsování C++. Podívejte se takto na mnoho jiných norem jazyka. A pak se podívejte na normy produkované W3C a bude Vám jasno kde je chyba.

Jednoduše, kdyby W3C na začátku napsal do HTML normy „chyby se v HTML tolerovat nebudou“, nebo „budou se chyby zpracovávat přesně takto“ tak se dnes tak děje. Stejně tak jako to W3C napsal do XHTML.

Ale protože W3C nebylo vůbec schopno napsat dobrou a úplnou normu HTML? tak způsobilo tento dnešní bordel. Jen W3C za to může.

Pokud napíšete neúplnou normu, kde si většinu věcí musí vývojáři prohlížečů domyslet, tak máte dnešní stav HTML. Vinou špatně udělané normy a špatné práce W3C.

Pooky

To tu opravdu chcete srovnávat HTML s C++ ?

Jerry12

Jsou to dva jazyky a maj gramatiku … minimalne v tomhle ohledu jdou porovnavat (a je jedno, ze v jinejch to dava pramalej smysl)

Pooky

Ano, mají gramatiku ale stejně tak nemůžeš porovnávat úřední dopis a rozhovor dvou lidí u piva. Protože jsou každý určený pro jiné sdělení informace.

U kompilovaného kodu se nepředpokládá nějaké „zkomolení“ při kompilaci ale u HTML, který je hlavně značkovací jazyk vyvinutý pro web, mohlo dojít k chybám, které autor nezavinil – vložené bloky, ztracené pakety v síti, modifikace na straně serveru atd. Proto nevidím žádný problém v tom, že specifikace chyby povoluje, dokonce to považuji za jednu z věcí, která umožnila tak velký rozmach a dominaci HTML

fari

proc by se melo predpokladat nejake zkomoleni?

tak ztracene pakety snad asi ne, jestli vite, kde se provozuje html nad udp, tak me opravte

a jetsli dochazi k nejakym modifikacim, at uz na strane serveru, po ceste, nebo u klienta, tak by mely byt provedeny v souladu se specifikaci

ekvivalentni k modifikaci html v pripade zminovaneho c++ muze byt libovolny preprocesor

Naith_cz

Naprostý souhlas, jen s výhradou, že se nejedná o normu, ale bohužel jen doporučení.

Já si naopak myslím, že XHTML sehrálo naprosto klíčovou roli v tom, že se valná většina tvůrců odnaučila dělat v kodu bor… zmatek. Jestli pamatujete weby z roku 2000, tak to bylo něco neuvěřitelného. Tenkrát bylo poměrně časté překřížení tagů, chybějící úvodní, nebo koncový atd. Opravovat to byla opravdu legrace.

bauglir

Oblíbený argument… „ale vždyť vendoři jsou členy“…
Realita je taková, že vendoři si museli založit separátní WHATWG aby měli vliv… a alespoň já osobně jsem rád, že se skutečně ukázalo, z čeho čerpá W3C svou moc (alespoň co se HTML a příbuzných doporučení týče), právě od vendorů. A vendoři prakticky donutili W3C se vzdát plánů na XHTML2 a začít kodifikovat HTML5… protože se taky mohlo stát, že zůstane ze hry venku…
Doufejme, že W3C pochopilo, že nemůže mít hlavní slovo a vendoři nějaké poradní, ale musí to být přesně naopak…

bauglir

Kde se dá zjistit, jak funguje W3C? A nemyslím nějaký popis na papíře „takhle jakože oficiálně fungujeme“, ale realitu… rád se poučím… Ovšem znovu, pokud se podívám na to, co w3c ve webových standardech „zvládlo“ za posledních 10 let a pokud se podívám, co zvládli vendoři proti vůli W3C (a tam není sporu o tom, že to bylo proti vůli)…

Vaše 2. poznámka ale jaksi postrádá odpověď, kdo by měl mít hlavní slovo… W3C? po zkušenostech prosím už ne… Uživatelé? jako například moje matka?… hm… jaké by mohla mít požadavky… „aby to bylo hezčí“… uživatelé nejspíše také ne… Developeři? při jejich počtu.. kdo by to řídil s jejich požadavky „tohle prostě JÁ nutně potřebuju, jinak stojí Chrome/IE/FF/O­pera/Safari za hovno“??

Ne, stejně tak, jako v jakémkoliv jiném odvětví, jediný, kdo se skutečně bude starat o co nejlepší produkt, je výrobce… žádná samozvané komise, žádné plebiscity stovek miliónů zákazníku, miliónů developerů…. Ne, jediným řešením je současná situace, kdy se vendoři dohodnou na pravidlech (HTML/WebApp/ES), která vycházejí z reality a v těchto mantinelech se předhánějí.

Nic proti W3C dokud standardizuje… do roku cca 98 dělalo dobrou práci… s HTML5/WebApp dělá zase dobrou práci… ale ať už nic moc radši nevymýšlí…

juraj

> „V maximální možné míře se sjednotil způsob vytvoření DOM reprezentace dokumentu pro vstupy v HTML5 a XHTML5.“
Prosím vysvetliť. HTML sa parsuje HTML parserom (ktorý je po novom štandardizovaný), XHTML sa parsuje stále tým istým XML parserom. Stále existuje tisícpäťsto spôsobov, ako rovnaký kód vytvorí dva úplne iné stromy dokumentu podľa toho, akým parserom sa parsuje.
> „Hodně zjednodušeně řečeno se jedná o algoritmus, který vznikl studiem chování IE6 metodou reverzního inženýrství.“
Parser IE6 má k HTML5 parseru možno bližšie ako parser vo Firefoxe 3.x, ale rozhodne nefunguje presne tak isto. Nie som si istý, či to zo súčasnej formulácie každý pochopí.
> „V některých aspektech je tato syntaxe dokonce jednodušší než HTML 4.01, zejména v oblasti nastavení !DOCTYPE nebo určení kódování.“
Nerozumiem, prečo sa do článku o syntaxi a parsovaní HTML vtrela zmienka o novom zápise doctype a „novom“ atribúte <meta charset>. Toto nesúvisí s parsovaním.

Ja som za HTML5 parser inak vďačný, keďže vďaka nemu už tri najrozšírenejšie prehliadače podporujú SVG (a MathML) v HTML. Už ani ten posledný dôvod, prečo používať drakonické X(HT)ML, nie je relevantný, chacha :-)

František Kučera

Ad „Některé starší prohlížeče však XHTML nepodporují a pak je potřeba se uchýlit k postupům, kdy do prohlížeče posíláme XHTML kód se špatným MIME typem text/html“

Testoval jsem šest prohlížečů (čtyři jádra) a problém měl jen jeden z nich: Microsoft Internet Explorer – jen kvůli němu bylo potřeba stránky přegenerovat a posílat se špatným MIME typem.

maryo

Taky jsem doted(par mesicu) psal HTML5 + XHTML a posilal jsem to jako text/html. U XHTML 1.0 je to tusim i povoleny. Ale kdyz je teda XHTML mrtvy, jak resite napr. Opengraph a podobny vymozenosti ktery maji svuj namespace?

emilk

vinim povetsinou specifikaci:

* kolikrat jsem postavil kurzor mezi </td> a <td> a nadaval, ze muj content neni videt = xhtml mi umele vytvorilo problem

* ignorovani priorit: w3c se vrtalo v semantickych nuancich <b> vs <strong>
ale pro menu, footer a podobne elementy pritomne na vetsine(!) stranek z realneho zivota markup nebyl?!

* a jiz zminovana drakonicnost: nasadte si adsense nebo jeho klon a zariskujte si. Na validaci mame validator, proc tu funkcnost tlacime i do vieweru?

Pavel Šimerda

Jo já ty sémantické nuance hodnotím celkem kladně, že se řešily… na footer není prvek potřeba (přesněji řečeno je potřeba, aby si uživatel mohl dodávat vlastní prvky), ale třeba rozložení stránky a obrazovky je v HTML ubohé a představa, že HTML vyjadřuje jen obsah a CSS stačí na stylopis je naivní a hloupá.

Nehledě na to, že ani XSL:FO nevydává funkční výstup na webu, takže si celou tuhle šaškárnu mohli odpustit (nebo alespoň nepředstírat, že to má z hlediska webu nějaký zásadní význam).

bauglir

Rozložení stránky z hlediska HTML? Hm…. to nejspíše neprojde… prož by taky mělo, když máme media queries, fluid a grid layout definovaný/na­vrhovaný v CSS

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.