Vlákno názorů k článku
Soumrak nad moderním X

S demagogií lze jen těžko polemizovat. Za sebe ale jen podotknu, že jsem taky rozčarován z toho, jak vývoj (X)HTML zakysnul na mrtvém bodě. Měl jsem pocit, že každý, kdo do toho trochu vidí, chápe, že XHTML měl být jen jakýsi meziščlánek, přestupní stanice od nevázaného a neurčitého HTML, kde si každý dělá co chce a jak chce, k něčemu striktnímu, zcela exaktně definovanému, co umožňuje jak unifikaci výstupu bez ohledu na prohlížeč, tak i algoritmizované manipulace, další strojové zpracování atd. Kritizovat, že tento mezistupeň je nedokonalý je prostě blbost. Jistě že je, a nenásleduje-li za ním (ani výsledek, ani zájem) ten další logický krok, nemá celé XHTML valného smyslu. Nerozumím tomu, nechápu to a mám pocit, že dalších sedm let čekání na pokračování bude mít za následek jen definitivní pohřeb a slavný nástup něčeho úplně jiného, co ty staré zahnilé specifikace s přehledem převálcuje.

Na druhé straně XHTML a jeho propagace svůj díl práce rozhodně udělaly. Kde dnes potkáte weby "stylované" vnořenými tabulkami, kdo dnes nepoužívá CSS, kkterý profesionál nevaliduje (nebo se aspoň nesnaží validovat) kód? Kdo si dnes troufne vyrobit wysiwyg editor, který by ignoroval standardy tak jako dřív? Díky za tu snahu, bylo to užitečné. XHTML byla pomocná ruka, která vytáhla vývojáře na ostrůvek uprostřed řeky, odkud měl vést most na druhý břeh. Jenže ten ani nestojí, ani se nestaví a kdesi v dáli diskutuje pár filozofů na plány, jestli tedy most, nebo přívoz anebo třeba paprskový teleport. K smíchu i k pláči.

Myslet si, že by se CSS neprosadilo bez XHTML je nesmysl. Styly jsou užitečné i v obyčejném HTML :). Vždyť je to pohoda něco zmenit ve stylu a zmení se Vám celý design v HTML :).

Myslet si, že by se CSS neprosadilo bez XHTML je nesmysl. Styly jsou užitečné i v obyčejném HTML :). Vždyť je to pohoda něco zmenit ve stylu a zmení se Vám celý design v HTML :).

Myslet si, že by se CSS neprosadilo bez XHTML je nesmysl. Styly jsou užitečné i v obyčejném HTML :). Vždyť je to pohoda něco zmenit ve stylu a zmení se Vám celý design v HTML :).

> ... k něčemu striktnímu, zcela exaktně definovanému, co umožňuje jak unifikaci výstupu bez ohledu na prohlížeč, tak i algoritmizované manipulace, další strojové zpracování atd.

Hovoříš o HTML 4.01? :-) Respektive, existuje v HTML 4.01 něco, co není exaktně definované, co je vázané na prohlížeč nebo co nelze algoritmicky zpracovat? A strojové zpracování - existuje v této nice něco jednoduššího, než parser HTML, a něco složitějšího, než parser XML?

dgx, to mi nepovídej, takovéhle věci. Jak může být parser striktního XML, jehož algoritmická syntaxe se dá zapsat málem jedním regexpem, složitější než parser HTML (notabene s volnou syntaxí s nestriktním DTD)? Parser XML už jsem psal několikrát, ale do HTML by se mi nechtělo ani ve snu. Tipovat si pravděpodobné konce neuzavřených tagů, rozpoznávat několikerý možný zápis téhož, domýšlet si jednotky atd... No fuj. Vedle toho XML je prostinké - PRVEK je otevřený, dokud není uzavřen pomocí /PRVEK, co je mezi <PRVEK a > jsou atributy a mají tvar attr="hodn" a vše, co je mezi > a </ je obsah prvku. A když je to jinak, je to syntax error, chyba, konec.

Já ti prostě nevěřím, ty filuto. ;)

To víš že budu povídat. Tak nejprve, mrkni na ukázku XML http://www.w3.org/TR/2006/REC-xml-20060816/#sec-entexpand a zkus tohle předhodit svému parseru. Jak se s tím popral? Zvládl to? Jestli jo, tak to asi bude něco šikovnějšího než prostý regulární výraz.

DTD fragment nelze ani regulárním výrazem odfiltrovat. Možná snad nějakým extrémně složitým s využitím rekurze.

DTD sice existuje i v HTML, ale zde se ho můžeme dovolit ignorovat. V XML rozhodně ne.

A teď k HTML. K žádnému tipování pravděpodobných konců značek nedochází. Strukturou je HTML zcela ekvivalentní s XHTML. Ačkoliv koncová značka chybí, tak existuje jedno a právě jedno místo, kam patří. Netipuje se, nezkouší se. Algoritmus jsem napsal třeba pro Texy. Nezabírá víc než pár řádků kódu.

Znova opakuji, HTML je strukturou ekvivalent s XHTML. Takže neexistuje žádný několikerý zápis téhož! Existuje jen jeden platný zápis.

Tož tak :-)

DTD sice existuje i v HTML, ale zde se ho můžeme dovolit ignorovat. V XML rozhodně ne.

Co to je za argumentace, todleto? Proč do toho pletete parsování DTD a jaký je v tomto bodě rozdíl mezi XHTML a HTML? Porovnávejme věci na stejné úrovni. Buď HTML a XHTML (pak je DTD dané a co s tím), nebo férově SGML a XML. A když si přečtete, co všechno se v SGML DTD může objevit, tak zjistíte, že připouští třeba i nepovinné počáteční značky (neptejte se mě k čemu) a vůbec zvěrstva, která v celé své složitosti nikdy nikdo nenaprogramoval. Tedy vyčítat XML, že obecně může obsahovat DTD přímo v sobě je úchylné.

Rozdíl je v tom, že v HTML si ho můžeme dovolit přeskočit, v XHTML ne. Jak jsem ostatně psal.

To právě nechápu. Šlo by to rozvést? Proč si ho v HTML můžeme dovolit přeskočit a proč v XHTML ne?

Doslova rozdíl je v tom X - tedy eXtensible, rozšiřitelný. Zatímco HTML v plné míře popisuje specifikace a žádné rozšíření není možné (tedy parsováním DTD se nedozvíme nic nového), v případě XHTML je záměr přesně opačný. Customizace XHTML 1.1, modulární systém atd. Bez DTD nedáme ani ránu. O podobě dokumentu prakticky nelze říct vůbec nic.

Ale bez DTD v XHTML ránu dám a né jednu :) Máme tu ijiný mechanizmus na rozšiřování gramtiky než je DTD, stačí sáhnout po schématu a prostorech názvů. Osobně chovám k DTD antipatie, právě pro jeho striktnost, složitost apod. :)

Ale právě tím hůř! Čím víc existuje mechanismů, tím je zpracování XML a potažmo tedy XHTML složitější.

Ok, já už na to koukám jako uživatel XML parseru, ne jako programátor :)

V XHTML se prohlížeč parsováním DTD dozví úplně to samé jako v HTML, tedy nic moc. Význam značek se z DTD poznat nedá, ten už musí prohlížeč znát. V obou případech. Proto v XHTML nemá cenu cpát DTD do dokumentu a nikdo to snad ani nedělá. Jiná situace by byla, kdybychom se bavili přímo o zobrazení obecného XML pomocí nějakého stylování, ale to už je přeci úplně jiná kapitola.

Ta rozšíření XHTML mají pouze tu výhodu, že specifikace není jedna obrovská, ale v menších kouscích a lze proto pro konkrétní účely pracovat pouze s podmnožinou jazyka.

"Proto v XHTML nemá cenu cpát DTD do dokumentu"

Nesmysl. Podle toho, zdali dokument obsahuje DTD a pokud ano, tak jake, se prohlizec prepina do rezimu standard, strict ci almost standard. DTD tak slouzi jako prepinac.

Je mi líto, ale nemáte dostatečné znalosti.

V XHTML bez naparsování a hlavně důkladného zpracování DTD nevíte vůbec nic. Už zde padl tento (samozřejmě validní) příklad http://www.webylon.info/K.17 - pokud nezpracuji kompletni obsah DTD, nevím nic o obsahu dokumentu.

Tohle bohužel drtivá většina lidí ani netuší. Zkuste se nad tím prosím zamyslet a uznejte fakta.

Zrušit !DOCTYPE, a bude klid.

Sen náš společný :-)) Možná naše děti se toho dožijou.

V tom případě prosím buďte sdílnější. Představme si nějakou konkrétní webovou stránku v HTML a stejnou v XHTML. Tvrdíte, že v HTML ji zpracuji i bez DTD a v XHTML o ní nic nevím, dokud nenaparsuji DTD? Co z toho DTD získám, abych se bez toho v HTML obešel a v XHTML ne? Já tvrdím (na jiném místě této diskuse), že prohlížeči stačí znát identifikátor DTD v DOCTYPE, aby pochopil, že se ma zařídit podle specifikace XHTML. Ale parsovat to podle mě nemusí, sémantiku značek v DTD stejně nenajde.

Abychom zabránili zmatení pojmů: tím "cpát DTD přímo do dokumentu" jsem měl na mysli opravdu vložit obsah DTD přímo do XHTML stránky tak jak je to ve Vámi odkazovaném přikladu. Nemyslel jsem tím DOCTYPE.

V právě v tom odkazovaném příkladě to je nutnost znát obsah entit &dotaz; &verdikt;. Ty zjistíte z DTD a bez jejich znalosti dokument nesestavíte.

Ale vždyť entity v SGML jsou obdobné jako v XML! Stručně viz http://en.wikipedia.org/wiki/SGML_entity . Teoreticky proto můžete nacpat ty entity i do HTML, ale samozřejmě to nebude fungovat. Takže to na čem triumfálně "nachytáváte" XHTML parser nachytáte i HTML parser, protože oba dva si svoji práci zjednodušují. Rozdíl je jenom v tom, že u HTML Vám vůbec nevadí, že parser v prohlížeči neimplementuje všechny vychytávky, zatímco u XHTML to bůhvíproč vadí.

V HTML autor stránky nesmí rozšiřovat jazyk dostupnými SGML prostředky. Viz http://en.wikipedia.org/wiki/SGML_entity.

Většina hotových XML knihoven (včetně těch v Exploreru, Mozille a Opeře) interní podsadu DTD podporuje, nenachytají se.

To je pak řeč jak rozprávka. Bavíme se o HTML nebo o SGML? Bavíme se o HTML. HTML je podmnožina SGML. Tedy je úplně šumafuk, co všechno je povoleno v SGML, podstatné je, co z toho je povoleno v HTML - a definování vlastních entit to není!

Naopak, v XHTML definování vlastních entit povolené je. To je celý rozdíl.

„Tipovat si pravděpodobné konce neuzavřených tagů, rozpoznávat několikerý možný zápis téhož, domýšlet si jednotky atd... No fuj“
1) Konce neuzavřených elementů jsou jasně definované.
2) Několikerý možný zápis téhož? Příklad? Tak či onak — HTML je jednoznačný jazyk. I v XML můžete řadu věcí zapsat různě při zachování stejné logické struktury.
3) Domýšlet si jednotky. Nerozumím. Kde se jaké jednotky v HTML domýšlí?

„A když je to jinak, je to syntax error, chyba, konec.“
Pokud implementujete specifikaci špatně, tak pak buď popravíte nevinného, nebo necháte žít „zločince“.

„Parser XML už jsem psal několikrát“
Selže v souladu se specifikací na sekvenci znaků „]]>“ užité v obsahu elementu?
Umí rozebrat interní podsadu DTD? Umí správně překládat parametrické entity?

Jak jsem řekl, s demagogií se doskutovat nedá, a asi by se ani nemělo. Jenže já jsem nepoučitelný hlupec.

ad 1) ano? Tak mi tedy jasně a neoddiskutovatelně doplňte konce tagů:

<div>Bla bla bla
<div>Bla bla bla
<p>Bla bla bla
</div>
</body>

Parser v prohlížeči to nějak zpracuje a zobrazí - ale že by nějak jasně a jednoznačně vyplývalo, jak? I toto...

ad 2) <td colspan=2> vs. <td colspan="2"> - stačí, nebo musím vymýšlet další, pádnější příklady?

ad 3) Kde je nějaká jednotka třeba v <td width=30>?

ad parser - už to tu padlo dříve, tak to asi nemá smysl pitvat znova. Proč oba (i dgx) mícháte parsování XML a parsování DTD? Nebo OK, pojďme srovnávat parsování XML z vašeho pohledu, ale laskavě si při tom budete poctivě parsovat i DTD HTML 4.01/Transitional...

Všechny XML parsery, co jsem kdy dělal, byly přísně účelové - stejně jako ty vaše pro HTML. Myslet na sekvenci ]]> jsem tedy nikdy nemusel; nicméně ano, parametrické entity jsem parsoval - a snad správně.

ad 1) Jen za použití vlastní hlavy bych si tipl, že to bude vypadat přesně takto:

<div>Bla bla bla
<div>Bla bla bla
<p>Bla bla bla
</p></div>
</div></div></body>

ad 3) Nechápu, proč by tam měla být jednotka? Respektive tam jednotka je - pixely, pixy :-).

ad 3) Nechápu, proč by tam měla být jednotka? Respektive tam jednotka je - pixely, pixy :-).

no jasne a co treba <textarea rows=30 cols=10> to jsou podle tebe taky pixely?

Kuk do specifikace, jo? A jestli zůstane ještě nějaká nejasnost, rád zodpovím :)

ad 1) Chybové stavy zatím definované nejsou. Ale v tom Vašem kódu je definované, že <p> skončí při zavření druhého <div>u, a pak je vysoce pravděpodobné, že první <div> skončí s koncem <body>. Ať si tipnete jakkoliv, autor si za případný nehezký výsledek může sám a tenhle tip vám nedá tolik práce.

ad 2) V XML máte dva druhy uvozovek, máte možnost dvojího zápisu elementu (s obsahem či prázdný) a máte jmenné prostory. <mašinka:td xmlns:mašinka="http://www.w3.org/1999/xhtml" mašinka:colspan='2'/> — platí ten colspan nebo ne?

ad 3) To od vás pochází ten rozšířený omyl, že by se v atributech značících rozměry prvků měly uvádět jednotky? Nepřestáváte mě překvapovat.

ad parser) Každý XML procesor musí rozebírat interní podsadu DTD. U HTML tenhle požadavek nikdy nikdo nevyřkl a W3C prokazatelně počítá s tím, že se prohlížeče o DTD nestarají.

ad entity) Jak váš parser fungoval, vložil-li někdo v dokumentu parametrickou entitu do hodnoty atributu bez středníku?

1) Nic neni vysoce pravdepodobne. Proste nelze zjistit, kde uzavrit prvni div. Klidne muze koncit pred otevrenim druheho.

2) Neplati, protoze uvozovky musi byt v celem dokumentu stejne. Nelze na jednom atributu pouzit dvojite a na jinem jednoduche. Takove dokument je cely spatne.

1) Nesmí skončit před otevřením druhého, neboť nemá nepovinnou koncovou značku a <div> je dovolen v jeho obsahu.

2) Uvozovky rozhodně nemusí být v celém dokumentu stejné. Kde to říká specifikace? Zápis <div id='něco' class="něco"> musí vždy fungovat.

Mate pravdu.

Opravuji se:
„U HTML tenhle požadavek nikdy nikdo nevyřkl“
Autorům je přímo zakázáno rozšiřovat HTML dostupnými SGML mechanismy.

Pixy, odpusť si úvod o demagozích. Dokážeš doufám diskutovat bez hloupých emocí a urážení protistany (tedy momentálně mě). Děkuji, v opačném případě si jukni.

ad 1) Značka </div> značí, že se uzavřou všechny elementy s volitelnou koncovou značkou, které byly otevřeny v rámci právě uzavíraného elementu, tedy elementu DIV. Zde jde element P. Je to pochopitelné?

Stačí si uvědomit, že elementy se nesmí křížit a že P má volitelnou koncovou značku.

ad 2) dvojce asi nerozumím. Jaký je v tom rozdíl? Číslo přece nemusí být v uvozovkách, ať s nimi nebo bez nich ho jinak zapsat nejde. Existuje snad jiný možný výklad?

ad 3) stačí kouknout do specifikace. Width u TD je deklarován jako typ "length", u nějž je specifikováno, že jde o pixely, není-li jednotka uvedena, nebo o procenta, je-li uveden symbol procenta. Je tu nějaká nejasnost?

ad parser: Už jsem zmiňoval, bez naparsování a korektního pracování DTD nemáš ani páru o obsahu tohoto http://www.webylon.info/K.17 dokumentu. Nebo si vem nějaký příklad z W3C.org, pokud chceš relevantní zdroje. Zakryj si DTD a řekni mi, co dokument obsahuje za text a značky.

Naopak v případě HTML 4.01 není potřeba žádné DTD řešit. Dokument je plně dán specifikací.

Nevidíš ten závratný rozdíl?

Naopak v případě HTML 4.01 není potřeba žádné DTD řešit. Dokument je plně dán specifikací.

Ale to není nutné ani v případě XHTML! I zde je dokument plně dán specifikací. Jakékoliv rozšíření DTD dělá z dokumentu obecný XML dokument, byť na XHTML založený.

Už vidím druhý díl, kde bude prezentováno, že HTML je aplikací SGML, tudíž je stejně, ba dokoce více, rozšiřitelné než XHTML. Taktně bude zapomenuto vše, co je ukazováno v tomto díle jako hlavní výhoda HTML – že nemusím parsovat DTD či se starat o cokoliv nad rámec specifikace. Buďme korektní, bavme se o čistém XHTML a čistém HTML, nebo o rozšiřitelnosti obou jazyků, ale neukazujme jako nevýhodu, že XHTML je rozšiřitelné.

Mimochodem, u XHTML si mohu být téměř jistý, že pokud jej pošlu prohlížeči, dokáže jej rozumně zpracovat svým XHTML či HTML parserem. Co se však stane, pokud pošlu prohlížeči korektní HTML dle SGML specifikace, avšak obsahující méně obvyklé prostředky syntaxe? Autor takový příklad sám uvádí jako K.34 na svém webu. Jinými slovy, podpora HTML je v prohlížečích řádově horší než podpora XHTML.

A prosím vás, jak souvisí to, že HTML je aplikací SGML, s tím, že je rozšiřitelné? To je opačná implikace. Ano, SGML má na to prostředky, ale HTML je definované specifikací, která nic takového nedovoluje. HTML 4.01 má své DTD a když do něj zasáhnete, tak už to není HTML 4.01. Narozdíl o XHTML.

A co je to "čisté XHTML"? Projev nedostatku argumentů? Nebo jsem na w3c.org něco přehlédl. Pure XHTML nevidím.

Vážně nad tím přemýšlejte, jste na dobré cestě.

Argumenty nedocházejí. HTML je konkrétní aplikace SGML a XHTML je konkrétní aplikace XML. Je na tomto postulátu něco špatně? Kde se tvrdí, že po zásahu do DTD XHTML je výsledek stále XHTML, jak zde postulujete?

Ohledně (ne)rozšiřitelnosti HTML, věnujte pozornost autorovu pamfletu K.24, kde ukazuje, že HTML lze v nadmnožině SGML rozšířit. To samé platí o XHTML v nadmnožině XML, ale v této diskuzi je to ukazováno jako nevýhoda a složitost XHTML. Buďme k oběma specifikacím stejně tvrdí. Podle mého názoru je obecná rozšiřitelnost v rámci XML nesrovnatelně jednodušší než obecná rozšiřitelnost v rámci SGML.

Překvapuje mě, že jste nechal bez odezvy mé tvrzení, že současné prohlížeče podporují lépe XHTML než HTML. Mám to chápat tak, že s tím souhlasíte?

> současné prohlížeče podporují lépe XHTML než HTML.

To je odvážná hypotéza. Teoreticky by v roce 2007 měli všechny prohlížeče umět obojí na 100 %, bohužel to tak není, ale neznám žádnou studii, který by "měřila", kolik toho ten který umí a neumí. Předpokládám, že z HTML jim bude dělat problémy pouze (nepoužívaná) NET syntaxe, nic víc. Ale tohle vážně nerozhodneme, ok?

Vraťme se k rozšiřitelnosti formátů. S prvním odstavcem naprosto souhlasím.

HTML je aplikací SGML. Pokud ji v této nadmnožině rozšířím, zůstane nadále aplikací SGML, ale nikoliv už HTML. Ano?

Totéž platí pro XHTML a XML.

Nicméně klíčové jak, jak je možné rozšířit XHTML v rámci XHTML, tedy aby to stále bylo XHTML - podívejte se sem http://www.w3.org/TR/2006/PR-xhtml-modularization-20060213/dtd_developing.html#sec_E.4. Doslova tam stojí: "tato sekce popisuje metody rozšiřování XHTML". Nikoliv: tohle když uděláte, tak už to není XHTML, ale "nějaké" XML.

Douška ke zvládání HTML a XHTML v prohlížečích: Smutnou skutečností je, že IE 6 nezná element abbr.

Doslova tam stojí: "tato sekce popisuje metody rozšiřování XHTML". Nikoliv: tohle když uděláte, tak už to není XHTML, ale "nějaké" XML.

A dále tam stojí: „Hlavním důvodem definice XHTML modulů a obecně modularizační terminologie je zjednodušení tvorby typů dokumentů založených na XHTML.“ Jinými slovy, modularizace je zde od toho, aby se od XHTML snadno odvozovaly další typy XML dokumentů, které však již nemohou být označovány jako (čisté, standardizované) XHTML.

Standardem je právě ona rozšiřitelnost. Vezměte si tento příklad: http://www.webylon.info/K.17 - to je stále standardní XHTML 1.0 Strict! Ale bez zpracování DTD ho nevyhodnotíte. Což je klíčové. (V HTML tohle udělat nelze)

Já myslím, že tímto můžeme diskusi klidně ukončit. Šlo o to, že napsat parser pro XHTML není v žádném případě legrace a je to ukrutně složitější, než parser HTML. Věřím, že už to vidíte taky.

Standardem je právě ona rozšiřitelnost.

Ba právě naopak. X(eXtensible)HTML není rozšiřitelné, resp. když ho rozšíříte už to není podle specifikací W3C přesně vyhovující (strictly conforming) dokument:

http://www.w3.org/TR/2002/REC-xhtml1-20020801/#normative

http://www.w3.org/TR/2001/REC-xhtml11-20010531/conformance.html#s_conform

Šlo o to, že napsat parser pro XHTML není v žádném případě legrace a je to ukrutně složitější, než parser HTML.

Pokud jde o to napsat parser, který zvládne korektně načítat XHTML podle specifikací W3C a totéž pro HTML, je rozhodně složitější napsat HTML parser. Ale nevím, proč se o tomhle pořád bavíte, parsery jsou dávno napsané...

XHTML by šlo však celkem snadno vylepšit. Zakázat používaní !DOCTYPE, a upravit výše zmíněnou klauzuli o shodě tak, aby šlo XHTML rozšiřovat pouhým použitím elementů v jiném jmenném prostoru. Stačilo by pak říci, že po odstranění cizích elementů a atributů musí zůstat dokument vyhovující XHTML schématu.

moje řeč, podto se podepisuju ;)

> Ba právě naopak. X(eXtensible)HTML není rozšiřitelné, resp. když ho rozšíříte už to není podle specifikací W3C přesně vyhovující (strictly conforming) dokument:

To není tak úplně pravda. Rozšíření o "entity reference", která je definovaná přímo v parsovaném souboru, je nutné zpracovat, viz bod User Agent Conformance 3.2.7. Ale proč se o tom bavíme, už taky přesně nevím :-)

Každopádně zcela souhlasím s tím, že zrušení !DOCTYPE je velký výzva pro XHTML.

„Kde se tvrdí, že po zásahu do DTD XHTML je výsledek stále XHTML, jak zde postulujete?“
Vyrobím-li interní podsadu DTD, kde přidám obecné entity, bude můj dokument stále splňovat podmínky pro striktně vyhovující XHTML dokument.

„věnujte pozornost autorovu pamfletu K.24, kde ukazuje, že HTML lze v nadmnožině SGML rozšířit“
Nelze. V HTML je CONCUR vypnutý.

„v této diskuzi je to ukazováno jako nevýhoda a složitost XHTML“
Nevýhodou není rozšiřitelnost, ale povolení interní podsady DTD.

Davide, úvod o demagozích si neodpustím, protože ten člověk, který se podepisuje jako Chamurappi, prostě demagog je a používá od samého začátku, co jsem se s ním prvně setkal, výhradně tvrdě damagogické postupy. To není žádné urážení protistrany (a tebe už vůbec - proč taky, že), ale prosté konstatování. Tohle i celý autorův web je demagogie přímo esenciální a učebnicová.

ad 1) - to jsi asi nepochopil. Nejde o to, co se stane na tom zapsaném </div>, ale spíš o to, kdy se uzavře ten první otevřený <div>. Jsou dvě rovnocenné možnosti a není ani trochu zřejmé, která se kdy použije. Nicméně každý HTML parser si nějakou z nich zvolí. Neurčitost, v XML nemyslitelná.

ad 2) - opět nechápeš. Já přece vím, že číslo nemusí být v uvozovkách (a string taky ne - sice je to chybně, ale parsery to běžně zpracují stejně jako číslo). Jde mi jen o to, že v XML mám jasně danou syntaxi atribut="hodnota", zatímco v HTML musím uvažovat i variantu, že tam ty žádné uvozovky nejsou. Co se parsuje líp? Nemluvě o takových možných perlách, které opět v HTML obvykle projdou a parser na ně musí myslet, jako např. <td class= colspan=2>... *)

ad 3) Nepopírám, že to je nejasné. Jen jsem to uváděl jako příklad "špatných mravů", kdy je v HTML běžné používat čísla bez jednotek, což se pak promítá i jinde. Ale ok, tohle je v daném kontextu už trochu scestné, musel bych déle vysvětlovat, jak jsem to původně myslel, což sem nepatří. *)

ad HTML 4.01 - Právě že vidím ten závratný rozdíl. DTD je jednoznačné, zatímco specifikace je děravá, nejasná a místy si i protiřečí. Stejně jako každý slovní, nealgoritmizovaný (a nealgoritmizovatelný) popis.

ad parser - to je právě ten ukázkový příklad demagogie a tyokozismu. Srovnáváme běžné parsery a vy argumentujete zcela netypickými špeky a vychytávkami, které by sten parser měl správně umět, aby fungoval OPRAVDU korektně. A srovnáváte to s HTML parserem,který si uděláte podle potřeby se zohledňováním "zvykového práva" (protože specifikace HTML je leckde nejasná) a žádné DTD rozhodně neparsujete. Mám snad taky dohledávat a vymýšlet špeky, kteeré naprostá většina HTML parserů zpracuje blbě nebo na nich selže? Takové jsou taky. A přitom si vždy vystačíš s jednodušším HTML parserem, který pro tvoje potřeby stačí, stejně jako většina vývojářů si vystačí s účelovým parserem XML, který stačí zase pro jejich potřeby, aniž by museli detailně zpracovávat DTD. Není parser jako parser - nějaká obecná xml_lib (zpracujeme úplně každé XML!) je něco zásadně jiného než účelový XML parser napsaný pro konkrétní projekt. Mimochodem myslím si, že zcela univerzální XML parser, který by byl bezchybný a zvládl všechny myslitelné obskurnosti syntaxe DTD, ani neexistuje. Každý má nějaké mezery, nedostatky a chyby - stejně jako všechny existující parsery HTML.

*) Mohli bychom si konečně rozumět v tom, že já přece vůbec nemluvím o specifikaci HTML, ale o tom, že HTML parsery nemají error-state a nesmí nikdy zkolabovat s chybou (jako XML)? Každou chybu, nejasnost a rozpor se specifikací si musí samy nějak rozseknout, domyslet, doplnit chybějící části kódu, vypustit přebývající a vždycky něco zobrazit. Když to přeženu, takový HTML parser si postaví DOM i z první kapitoly Babičky - zatímco XML parser skončí se syntaktickou chybou hned na prvním znaku. Proto je (dobrý) HTML parser nesrovnatelně těžší a náročnější na vytvoření než jakýkoli XML parser, držící se striktně formální syntaxe.

stejně jako většina vývojářů si vystačí s účelovým parserem XML .... je něco zásadně jiného než účelový XML parser napsaný pro konkrétní projekt

A to je právě chyba. Kdyby použili hotovou odladěnou komponentu parseru XML, ušetřili by si práci a navíc by jejich kód zvládal načítat XML, ne jen jeho podmnožinu, kde se se spoustou věcí nepočítá.

Mimochodem myslím si, že zcela univerzální XML parser, který by byl bezchybný a zvládl všechny myslitelné obskurnosti syntaxe DTD, ani neexistuje.

To trochu zavání demagogií, ne? ;-D Na svém počítači jich mám několik.

dodnes se mi nekde prasi tva kniha o XML .. achich jo..

tak nejak mam pocit, ze jsi od DTD dosud nepokrocil dale

Vytrvalý brekot o demagogii vám nesluší.

ad 1) Tipnout si jednu z možností je obdobně snadné jako selhat.

ad 2) „a string taky ne - sice je to chybně, ale parsery to běžně zpracují stejně jako číslo“ — to není pravda, ani řetězec nemusí být v uvozovkách, pokud obsahuje znaky [A-Za-z0-9.-_:]. Bavíme-li se jen o uvozovkách, máte pravdu, že povinné uvádění mírně zjednodušuje parser.

ad 3) Nejasné to není, zápis s jednotkami jinými než procentovými (třeba <td width="30px">) porušuje všechny existující HTML/XHTML specifikace, třebaže si prohlížeče běžně ta písmenka odmyslí. Jak to souvisí s tématem HTML vs. XHTML?

„Mám snad taky dohledávat a vymýšlet špeky, které naprostá většina HTML parserů zpracuje blbě nebo na nich selže? Takové jsou taky.“
Jenže lidé se spoléhají na to, že tyto špeky implementované nejsou. Proto se nikdo nehrne do jejich implementace. Každý, kdo napíše do HTML <br />, počítá s chybou v parseru.

Jakkoliv vám ty syntaktické nepodporované špeky připadají divné, jejich implementace je pořád jednodušší než rozebírání DTD.

ad 1) podívej se do specifikace http://www.w3.org/TR/html4/index/elements.html - element DIV nemá nepovinné značky. Já doufám, že se bavíme o HTML, nikoliv o tom, co jako HTML vypadá, protože se tam používají ostré závorky.

ad 2) co se parsuje líp? to je jako zeptat se, jestli se lžičkou lépe míchá čaj nebo káva. Je to jedno. Naprosto. Počátek i konec hodnoty atributu jsou jasné a nepochybné.

Dále příklad <td class=olspan=2> není HTML dokument.

ad 3) je to dokonce hrubě scestné. Protože mezi XHTML a HTML, tedy XHTML 1.0 a HTML 4.01, žádný rozdíl kromě syntaktických libůstek není. Takže uvést toto na podporu XHTML je podporování onoho mýtu, že XHTML přináší CSS, přístupnost, použitelnost a mír do celého světa a úsměv do tváři dětí i starých lidí.

ad parser) to je právě ono. Kdyby bylo XML navržené dobře, tak tyto špeky nebude obsahovat. Ty špeky se sice ve webdesignu nepoužívají, ale to nic nemění na tom, že tento (nový) formát jimi disponuje a bohužel jejich zpracování ho extrémně komplikuje. Co z toho plyne? Buď je budeme přehlížet a tvrdit, že neexistují, a tudíž cituji "na parsování XHTML stačí regulární výraz", nebo prostě řekneme, že XHTML je formát na ho**o. Jo, kdyby přišlo XML 2.0 a potamžmo kompatibilní XHTML, které by se lišilo jen v odstranění těchto špeků + třeba přidání "nevypsaného" koncového tagu, budu první, kdo půjde oslavovat a velebit nový formát.

ad *) Pixy, bavíme se o HTML a také o parserech HTML. Pokud parser odmítne neplatný dokument, je to v pořádku, ať už jde o parser HTML nebo XHTML.

Promiňte dotaz amatéra ale příklad:

<div>Bla bla bla
<div>Bla bla bla
<p>Bla bla bla
</div>
</body>

mě nepřijde korektní, neboť, podle specifikace HTML je koncová značka </div> povinná. Což je ostatně logické, protože DIV může obsahovat další blokové elementy třeba P DIV. A není tudíž možné implicitně určit kde blok tvořený DIV končí.

Takže ve shodě se specifikací HTML je to buď:

<div>Bla bla bla</div>
<div>Bla bla bla
<p>Bla bla bla
</div>
</body>

Nebo:

<div>Bla bla bla
<div>Bla bla bla
<p>Bla bla bla
</div>
</div>
</body>

Nebo se mýlím?

Přesně tak. Správný je pouze ten první příklad.

...hádam druhý? Inak by nemohlo fungovať vnáranie div-ov...
Proste parser zistí: sakra, mám tu /html ale chýba mi tu ešte jeden /div

Možná jste mě nepochopili, chtěl jsem říct, že Pixyho přiklad neodpovídá specifikaci HTML (neuzavřený tag DIV - podle specifikace povinný). Pokud uzavřu DIVy, není s neuzavřeným P žádný problém a navíc to odpovídá specifikaci (P má uzavírací tag nepovinný), prostě jakmile parser narazí na </div> ukončí i P. V obou případech se zobrazí to co autor chtěl.

„kdo do toho trochu vidí, chápe, že XHTML měl být jen jakýsi mezičlánek“
Mezičlánek, který není kompatibilní ani s jedním okolním článkem. To už je veřejně známé nejméně pět let.

„Kritizovat, že tento mezistupeň je nedokonalý je prostě blbost.“
Přecházet na něj blbost není?

„Na druhé straně XHTML a jeho propagace svůj díl práce rozhodně udělaly.“
Jenže to, co se propagovalo, jen zdánlivě připomíná XHTML. Ano, má to jeho <!doctype>, ano má to (většinou) pozavírané elementy, ano, lidi validují. Ale tím to končí. Má to mnohem blíž k HTML než k XHTML.

Ty zmíněné dobré návyky se prosadily jen díky praktičnosti a rostoucí podpoře CSS ze strany prohlížečů.