Názory k článku
Soumrak nad moderním X

Jestli "X" je mrtve a snasi se nad nim soumrak, co ma podle autora prijit noveho? To nam bud cudne zamlcuje nebo sam nevi. Pusu i web ma plnou kritiky, ale reseni (ani jeho smer) jak se zda nenabizi. Mozna text/plain se kterym nebude mit problem nikdo?

Nic nového nepřijde. imho další vývoj nemá smysl, protože 90% lidí stejně musí zachovat zpětnou kompatibilitu s existujícími prohlížeči, 90% lidí na nějaké dodržování pravidel stejně dlabe, protože prohlížeč to stejně nějak zobrazí, prohlížeče jsou nepředvídatelné bastly protože musí mimo jiné řešit předchozí bod, každej prohlížeč se stejně chová jinak než ostatní, co funguje v jednom nefunguje v druhym a míra nefunkčnosti roste s vývojovým stupněm použitého prostředku. Tak k čemu něco nového?

HTML 5

„co ma podle autora prijit noveho?“
Proč by muselo přijít něco nového? HTTP protokol je také už řadu let bez úprav.

„Pusu i web ma plnou kritiky, ale reseni (ani jeho smer), jak se zda, nenabizi“
Proč bych zrovna já měl nabízet řešení? Řešení čeho?

Trošku pletete koše s baňama. HTTP je bez úprav pouze kvůli tomu, že není nutné, aby byla každá změna nějak specifikována. V HTTP můžu posílat naprosto neznámé značky a přesto to bude standardní HTTP.

Proč bych zrovna já měl nabízet řešení? Protože kritizovat umí každý blbeček?

To teda ani ho***, většina lidí kvalitně kritizovat neumí!

A ani Chamurapi to neumi... :)

Jako treba ty ze.. Mozek ti nestaci na to aby si pochopil dusledek toho co pises? :D Trosku logiky chlapce nez neco napises.. hm?

To je ovsem zasadni nepchopeni cele problematiky. Tlak na upravu omezeneho html byl obrovsky, a vznikajici nekompatibility byl velk problem, ktery bylo nutno nejak resit. Jeda cast reseni prineslo oddeleni struktury od vzhledu, ktere prineslo CSS, ktere prineslo ohromnou flexibilitu a zjednoduseni dokumentu. Resenim vyvoje struktury dokumentu je prave flexibilni modularni XML ktere bylo aplikovano na html a tak vzniklo xhtml.

Chcete oddeleni obsahu od formy ? RSS. Chcete aby vypadalo hezky ? Pridejte mu XSLT sablonu.

clanek me zaujal. celkem vhodne pracuje s ruznymi verzemi xhtml tak, aby bylo dosazeno kyzene efektu. nicmene skutecnosti je velmi prosta:

- chcete psat slusny kod? muzete i v html, proste budete uzavirat parove tagy, psat uvozovky kolem atributu, nebudete tagy krizit, ... a mate to.

- zpraseny kod lze vygenerovat i v xhtml

- aktualne me nenapada duvod, proc se vyhybat validnimu striktnimu xhtml - xhtml JE xml, xml parsery jsou bezne k dispozici, tzn. dalsi prace s takovym textem je mnohem snazsi.

mimochodem vysledky validace xhtml 1.1 s tagem font (copy & paste):

Error Line 10 column 20: element "font" undefined.

Ojojoj. Slušný kód nemá nic společného s HTML vs. XHTML:

- HTML zakazuje křížit tagy - takže to dělat nemůžu v žádném případě, a nejde o to, jestli píšu v HTML nebo XHTML.

- HTML určuje, které značky v páru jsou volitelné - pokud je vynechám, tak jde samozřejmě stále o "slušný kód"

- HTML určuje, kdy je potřeba psat uvozovky kolem atributu a kdy se mohou vynechat - pokud se tímto řídím, opět píši "slušný kód".

Technicky vzato nic jako „párové tagy“ neexistuje. Jsou elementy, které mají nepovinnou počáteční a/nebo koncovou značku. Pozice vynechaných nepovinných značek jsou dobře definované.

„proc se vyhybat validnimu striktnimu xhtml“
Striktní DTD je příliš omezující. Ruší pouze třetinu prezentačních elementů a společně s nimi i několik sémantických. Když už nějakou DTD, tak Transitional.

A můžete uvést nějaký příklad těch dvou třetin prezentačních elementů, které nejsou zrušeny či sémantických elementů, které naopak zrušeny jsou?

Třeba - prezentační: <b>, <i>, <big>, <small>

sémantické: <menu>

Chamurappiho přehled:
http://www.webylon.info/K.33

Co se článek snaží říct? Skutečně si autor myslí, že jelikož XHTML nemá lepší sémantiku, není přístupnější, není lepší pro vyhledávače a funguje v IE, znamená to, že je mrtvé?

Já většinu stránek generuju staticky pomocí různých kombinací XSL procesoru a perlových skriptů. XHTML mi usnadňuje práci, protože je [plus mínus] XML a můžu na něj tím pádem používat nástroje určené pro práci s XML. Když musím napsat nějaký skript sám, jsem rád, že nemusím přemýšlet nad parsováním HTML a můžu použít XML parser. (Ano, Perl samozřejmě parser HTML má, ale s XML je to zkrátka jednodušší.)

Sám Kosek v tom článku na Intervalu píše: "(...) nehádejte se s ostatními, zda je lepší XHTML nebo HTML." To mi přijde docela přesný. Někdo pro použití XHTML důvody má, někdo ne. Pokud někdo XHTML používá a ostatním cpe do huby, aniž by přesně věděl proč, je pako. Pokud se někdo snaží rádobyduchaplně ukázat, že je XHTML k ničemu, asi by svůj čas též mohl strávit lépe.

"V tuto chvíli postrádá smysl tvořit nové weby v XHTML. Stejně jako posledních sedm let."

Když je pro mě výstup do XHTML otázka přepnutí jednoho parametru v XSL stylu a XHTML výstup mi usnadňuje nějaký postprocessing, proč bych XHTML nepoužil?

P.S. Didaktická past blažené nevědomosti? Nosorožce nezajímá jádro pudla? WTF?

Zcela s vámi souhlasím. Stránky generuji, přičemž hojně využívám XSL, XPath, DOM, atd. Neumím si představit, že bych namísto XHTML při jejich vytváření používal HTML.

Pozor, autor (snad) nikde nepíše, že XHTML je horší volba než HTML, protože kdyby to napsal, jednoduše by nehovořil pravdu. Pouze demonstroval několik aspektů, kdy použití HTML a XHTML vyjde nastejno. Na újmu jeho cti však slouží, že tento postup v úvodu nijak nezdůraznil a celkově pak nechává článek vyznít tak, že XHTML nic nového oproti HTML nepřináší, proto není nutné se jím obtěžovat.

Neodpustím si jedno malé pošťouchnutí -- Jak chce autor zkombinovat HTML s SVG, MathML či v budoucnu třeba s XForms?

„Neumím si představit, že bych namísto XHTML při jejich vytváření používal HTML.“
Tvořte si je, v čem chcete a jak chcete, ale prohlížečům nemá smysl posílat cokoliv jiného než HTML.

„nechává článek vyznít tak, že XHTML nic nového oproti HTML nepřináší, proto není nutné se jím obtěžovat“
To nové, co přináší, málokdo potřebuje. Většina autorů stránek se jím skutečně nemusí obtěžovat.

„Jak chce autor zkombinovat HTML s SVG, MathML či v budoucnu třeba s XForms?“
O tom se více rozpovídám ve druhém dílu.

Tvořte si je, v čem chcete a jak chcete, ale prohlížečům nemá smysl posílat cokoliv jiného než HTML.

Jinými slovy potvrzujete, že XHTML je potřebný a v současnosti asi nezastupitelný jazyk pro web. Nechápu, na základě čeho jste dospěl k závěru, že prohlížečům nemá smysl XHTML posílat.

O tom se více rozpovídám ve druhém dílu.

Tedy nejdůležitější argument zůstává (prozatím) nezodpovězen.

Nechápu, na základě čeho jste dospěl k závěru, že prohlížečům nemá smysl XHTML posílat.

Kvůli tomuto vznikají bouře ve sklenici vody v diskusi na jakpsatweb. Jde o to, že i když napíšete XHTML musíte ho nakonec stejně poslat jako text/html, aby to zchroupal IE. A otázkou je, jestli XHTML dokument poslaný jako text/html je XHTML (tedy založený na XML) nebo je jen zprzněné HTML.

Nemusím. Od toho je HTTP hlavička Accept, podle které se rozhodnu, s jakým MIME typem stránku pošlu. Tohle zařídit na straně serveru není až tak obtížné. U všech současných stránek tak činím.

To vaše "MÁLOKDO" platí tak maximálně v partě náctiletých amatérů.

Kdo vám proboha umožnil publikovat takové kokotiny?
XHTML má smysl, pokud to nechápete, tak o tom nepište.

Podepisuji a souhlasím.

Davam 100x suhlas. Autor clanku je znamy obmedzenec na obozore webu.
Kludne nech si pise HTML a ignoruje vsetky "standardy", ale mne ako vyvojarovi webu, nie HTML bastlicu vyhovuje XHTML v plnej miere, pretoze s nim vdaka prepojeniami s inymi kniznicami dokazem spravit divy, ktore HTML malo kto spravi.

A ak sa autor clanku odvazi reagovat, ze uzatvaracie znacky moze robit aj v HTML tak si pekne serie do huby, pretoze prave on presadzuje tieto nepovinne ukony, ktore v HTML predsa nemusi robit a tym padom prechadza na povinnu cistu syntax XHTML.

Přesně tak. Autor zřejmě nikdy nepotřeboval svoje HTML dokumenty něčím dále zpracovávat. To by si na HTML pěkně zanadával. Není zkrátka nic jednoduššího, než odsoudit něco, čemu nerozumím.

Autor asi nepracoval na větším systému (scriptové aplikaci) s rozraním pro veřejný internet. Okleštěné Html v podobě Xhtml s extrahováním vizuálního zobrazení do externího Css je v současné době nejlepší cesta pro vývoj (aneb lepší zatím nebyla).

Mýtus autora č.1:
"XHTML očištěno od prezentačních částí HTML.Stejnou pitomost opakují začátečníci i pokročilí, amatéři i profesionálové, lidé známí i neznámí, experti světoví i čeští."
Autor se nás snaží přesvědčit, že účel pro který byl tento standart vydán vlastně není smysl proč byl vydán. Odstranění stylujících elementů přineslo pokrok v odstraňování stylizační vrstvy od popisné vrstvy informací.

Mýtus autora č.2:
"Z mýtu o sémantice částečně pramení i sen o lepší přístupnosti."
V tomto bodě se nás autor snaží přesvědčit, že výhody vlastně nejsou výhody. Zkoušel někdy autor naprogramovat nějaký parser html(indexátor, zobrazovač) pro extrakci informací z popisného dokumentu? Asi by rychle obrátil a začal psát články o rozednění na novým(starým) X.

Mýtus autora č.3:
"Pomůže vám ultramoderní X v honbě za skvělou pozicí mezi výsledky vyhledávání.Opět si většina odborníků popletla jazyk XHTML se čistým HTML 4."
Autor předhazuje další argument do své zbírky, plácá páté přes deváté a snaží se nás přesvědčit, že validní stránka s exrahovanými designovanými prvky(třeba do toho Css) nás nepoposune trošku výše v SERP při předělávce z Html4 s designovými prvky přímo v těle dokumentu.

Mýtus autora č.4:
"Formát XML DTD je žebrák na molu módní přehlídky, sice fajn člověk, ale mezi modelky nezapadá. Krom estetických vloh postrádá i žádané schopnosti."
Autor se nás prostě už snaží ukecat o své pravdě čímkoliv, aby článek byl dostatečně dlouhý a splňoval požadavky na délku přesvědčivého článku. Proč si autor nenapíše vlastní DTD? Asi zkoumá jen do té hloubky, která stačí k sesmolení několika argumentů.

Didaktická past blažené nevědomosti autora:
"V tuto chvíli postrádá smysl tvořit nové weby v XHTML. Stejně jako posledních sedm let."
Některým názorům se velice divím jako názorům sdružení Mladí Komunisté (nespojuji autora s komunisty, pouze s propagátory z neznalosti).

Rozhodně doporučuji autora najímat jako copywritera, ale jako tvůrce webu ho odehnat od počítače. Obdivuji autorovu schopnost umě manipulovat s argumenty a protiagrumenty, i když jeho schopnost dávat si do souvislosti směr vývoje, krapet pokulhává.

Asi jste četl moc rychle ;)

ad 1) mezi XHTML a HTML žádný rozdíl v elementech a sémantice NENÍ. Tedy jaké odstranění elementů? To není mýtus autora, to je mýtus váš, na který se naopak snažil autor upozornit. Prozřete!

ad 2) nevím jak autor, já zkoušel naprogramovat obojí. HTML parser je brnkačka, XML parser neskutečně složitá záležitost. Nakonec se stačí podívat, jak dlouho se třeba vyvíjí taková knihovna

ad 3 a více) vážně si článek ještě jednou či dvakrát přečtěte. Žijete totiž v bludu, že HTML nemůže být validní, zatímco XHTML musí. Je zajímavé, že čím větší máte mezery ve znalostech, tím více hýříte jízlivostí a sarkasmem. S tím opatrně, protože jakmile znalosti získáte, budete se za svůj komentář stydět.

...vypadl mi název knihovny Libxml2 - http://www.xmlsoft.org/

"HTML parser je brnkačka, XML parser neskutečně složitá záležitost."

To je zvláštní. Řekl bych, že pro účely webových stránek je XML parser mnohem jednodušší. Nikdy jsem HTML ani XML parser nepsal, ale až dodnes jsem o tom byl přesvědčený. Kdybych chtěl napsat parser pro HTML stránky a ekvivalentní XHTML stránky, v čem přesně by ten XML parser byl o tolik složitější?

Předně, není nic jako "XML pro účely webových stránek", existuje pouze jedno XML. Zkuste se podívat třeba na tento fragment http://www.w3.org/TR/2006/REC-xml-20060816/#sec-entexpand a řekněte upřímně, máte chuť na něco takového psát parser? A vůbec - rozumíte tomu? Já s tím mám hodně velké problémy, abych pochopil, která bije.

HTML tohle neumí a proto jej parsovat je ve srovnání s XML skutečně brnkačka.

Mluvil jsem o _parserech_ pro účely webu, nikoliv o XML. (To už jsme se dostali do fáze chytání za slova? :) Mně jde zkrátka jen o to, že když jsou webové stránky zároveň XML, dá se s nimi hezky pracovat standardními XML nástroji, kterých je požehnaně. O tom taky mluvil Martin Jersák, když se ptal, jestli si Chamurappi zkoušel napsat nějaký nástroj pro práci s webovými stránkami. Nástroje pro zpracování XML jsou (alespoň podle mých zkušeností) mnohem dostupnější než nástroje pro zpracování HTML. Samozřejmě můžete namítnout, že HTML parser napíšete za chvilku, ale... taková diskuse už pro mě ztrácí kouzlo.

Prosím? Na vaši otázku "Kdybych chtěl napsat parser pro HTML stránky a ekvivalentní XHTML stránky, v čem přesně by ten XML parser byl o tolik složitější?" jsem zcela korektně odpověděl. Neptal jste se na existující nástroje, ale na psaní (programování) parseru XML.

Proto jsem se ptal tak, jak jsem se ptal -- v těch ekvivalentních XHTML stránkách by žádné zběsilé entity nebyly. Pořád se ale bavíme čistě hypoteticky: hotových parserů XML je tuna a jejich autoři se specifikacemi nejspíš podobné problémy neměli.

Ale to je snad jedno, kolik existuje hotových XML parserů. Řeč je o tom, že naprogramovat obecný XML parser je značně komplikovanější než obecný HTML parser. Nic víc, nic míň.

_Obecný_ ano, proto od začátku mluvím o "parseru pro účely webových stránek". Hezké rozdělení parserů je například tady:

http://www.cogsci.ed.ac.uk/~richard/xml-parser-requirements.html

Pro web se podle mě bez problémů hodí i parsery z té úplně první kategorie, které jsou (opět pouze podle mě) co do složitosti s HTML parsery rozhodně srovnatelné. Dobrý článek na tohle téma je tu:

http://www.xml.com/pub/a/2000/11/22/deviant.html

Rozebírají i problémy, které s sebou takové "neúplné" parsery nesou. Logický protiargument zní, že jiný než úplný parser XML není parser XML, beru.

Je videt, ze o tom moc nevite (coz neni az tak ku podivu, vzhledem k tomu ze SGML standart se spatne hleda).

HTML ma entity ktery jsou v XML taky. Pokud jim nerozumite, je to vas problem. Navic, nevalidujici parser XML se nemusi o nejae entity vubec starat.

Chtel bych vas videt, jak parsujete nektere v html validni obraty jako </>, H<sub/2/O nebo neukoncene parove znacky, u kterych musite zjistit, kde vlastne konci.

V čem konkrétně je jednodušší parsovat HTML než XML?

Chamurappi přinejmenším tuší, co naprogramování parseru obnáší:
http://www.webylon.info/K.17

Ukazuje, že je to obtížnější, než by neprogramátor čekal. Vzhledem k tomu, že všechny významnější prohlížeče (včetně IE) XML parser mají, není to asi není taková rána ve srovnání se SGML parserem, který žádný prohlížeč pro HTML nepoužívá.

Zdá se mi, že autor si plete DTD a odkaz na DTD. To je dost závažný nedostatek, nehledě na další chyby.

Autor zpracovává (nejen) své dokumenty vlastním HTML parserem, který umí v souladu s pravidly HTML implikovat nepovinné značky a na výstupu má klasický XML DOM. Nicméně návyky autora nejsou podstatné.

...když nejsou podstatné, proč o nich píše do diskuse? Použití standardních nástrojů má kupu výhod -- většinou běží na více platformách, jsou udržované (aniž bych pro to cokoliv musel dělat) a pokud se o některý z mých projektů musí postarat někdo jiný (a nebo já s ročním odstupem), je docela slušná pravděpodobnost, že se s onou technologií už seznámil jinde.

Mimochodem: Kdyby byl článek podaný stylem "takhle to dělám já, funguje mi to dobře, má to tyhle výhody a tyhle nevýhody", bylo by to něco úplně jiného.

Píše o nich, aby si dělal reklamu.

Sere z blbosti na standardy, protože nechápe, že není na světě sám.

Každý, kdo ještě nechápe, jaký idiot je Chamurapi, ať se hned koukne na html kód jeho stránek!!!!!!!!

view-source:http://webylon.info/

Milý pane anonyme, tenhle člověk vzal spoustě lidem čtvrt hodiny času a některé z nich bohužel i ovlivnil, jak jde vidět z některých diskusních příspěvků.

Jen tak bokem, vy jste se nepobavil nad jeho HTML? Já jsem smíchem probrečel dva papírové kapesníky :-D!

Co je na tom zdroji vtipneho? Dyk je to krasne prehledne HTML.

HTML to rozhodne neni.... jen neco co se mu trosku podoba. ;))

A proc to neni HTML? Nejake zduvodneni?

jen idiot muze uvest odkaz v tomto tvaru.

Ty už radši nemluv... :-)))

Ten kód je docela zajímavý. Kdybych já implementoval stejný grafický návrh, asi bych použil mnohem více divů... Taky bych si asi netroufl vynechávat všechny ty nepovinné značky (html, head, body), protože v těchhle kramflecích si taky nejsem nejjistější a radši je explicitně uvedu i kvůli čitelnosti (aby se mě to lépe četlo). Ale když se v tom vyzná on, proč ne.

Na tom ale vůbec nesejde, to je OT. Zkus někde najít něco, kde ze sebe Chamurappi dělá idiota tím, co píše!

Ale když se v tom vyzná on, proč ne.

Protože takoví pracovníci jsou nepoužitelní. Dělají práci, kterou po nich nikdo nepřevezme a když pak onemocní nebo je když je vyhodí z firmy, tak se to po nich musí celé předělávat.

Jestli si myslíš, že ti k obživě bude stačit plichtit si sám na koleně amatérské webíky na zakázku, tak se připrav na chudobu.

Kód mé úvodní stránky — té její složitější verze — je záměrně zamotaná úchylárna. Fakt si myslíš, že by pomohlo, kdybych doplnil <!DOCTYPE> a zavřel ten jeden <div>? Nebo kdybych doplnil značky <body> a <head>? Nebo kdybych z toho udělal XHTML? Pochybuju.

Jednodušší verze té stránky je v pohodě. Každý, kdo umí HTML, má vědět, kde se nepovinná značka dosazuje. A já pochopitelně po kodérech vyžaduji znalost HTML, takže tomu zrovna tomuhle kódu bezpečně porozumí.

Tak teba by som nechcel mat ako kolegu v praci a nebodaj pracovat s tebou v jednom teame a zadalsie keby som komercny subjekt a davam zakazku na vytvorenie stranok za velky penazny obnos tka by som si hladal viac serioznejsiu firmu a ty by si mal z toho prd.

Som rad, ze sa nezivis web developerstvom.

Odkazujete se na opravdu autoritativní zdroje :-) Ale když to obrátíme. Musel jste si naprogramovat vlastní parser a ten musí doplňovat nepovinné ukončovací značky. V případě XHTML byste nemusel. Máte k tomu asi důvod. Ale jaký?

Najväčší rozdiel medzi parsermi vidíte v (ne)doplnovaní značiek?

Ani v případě HTML samozřejmě nemusel. Příklad z oblíbeného PHP:

$dokument = new DOMDocument;
$dokument->loadHtml($zdrojovy_kod);

„Skutečně si autor myslí, že jelikož XHTML nemá lepší sémantiku, není přístupnější, není lepší pro vyhledávače a funguje v IE, znamená to, že je mrtvé?“
Autor si myslí, že nebýt prvních tří mýtů z uvedené čtveřice, málokdo by dnes XHTML považoval za nástupce HTML. Upozorňuji, že v mém článku se mezi agresivní anotací a agresivním posledním odstavcem nachází spousta dalšího textu.

Chápu, že vám XML usnadňuje práci, ale vy jste jen jedna polovina řetězce. Ta druhá — prohlížeče — vám na XML při „text/html“ dlabe. Posíláte jim zbytečný balast.

Jste-li autorem stránky, kterou chcete zpracovávat XML nástroji, nemáte důvod posílat XML podobu prohlížečům. Užíváte-li na jeho výrobu XSLT 1.0, pak ani nemáte jistotu, že výstup bude odpovídat dodatku C z doporučení XHTML 1.0. Jak jste řekl, přepnutí formátu je otázka jednoho <xsl:output>. Nachrlit si pro své potřeby svůj XML formát a pro potřeby prohlížečů jejich HTML formát je snadné.
Nejste-li autorem stránky, kterou chcete zpracovávat XML nástroji, musíte mít od autora zajištěné, že výstup bude vždy správně sestavený a že bude mít do určité míry neměnnou strukturu. Značná část existujících XHTML stránek (i přes snahu autorů) obsahuje fatální chyby, které při „text/html“ nikoho netrápí.

„Někdo pro použití XHTML důvody má, někdo ne.“
Přes 98 % z těch, kdo ho „používají“, důvody nemá. Pro ně je tento článek. Dnes a denně potkávám lidi skálopevně přesvědčené o jednom z uvedených mýtů.

Chápu, že vám XML usnadňuje práci, ale vy jste jen jedna polovina řetězce. Ta druhá — prohlížeče — vám na XML při „text/html“ dlabe.

To je právě další rozšířený omyl. Nedlabe. MIME typ je opravdu celkem podružný. Týká se jenom HTTP a server dokonce nemusí poslat žádný. Rozhodující je právě DOCTYPE.

Že prohlížeč zpracuje i XHTML, kde některé koncové značky vynecháte a některé neexistující atributy použijete, znamená pouze to, že se snaží chyby v kódu co nejlépe překonat. Ale to dělá pouze proto, že mu nic jiného nezbývá a ne proto, že by kašlal na to, že je to XHTML. V důsledku se to tak jeví, ale je v tom významný rozdíl.

> Nedlabe. MIME typ je opravdu celkem podružný. Týká se jenom HTTP a server
> dokonce nemusí poslat žádný. Rozhodující je právě DOCTYPE.

Já tomuhle moc nerozumím, ale řekl bych, že tady je to vysvětlené docela dobře:

http://hsivonen.iki.fi/doctype/

Cituju: "Another common misconception is related to XHTML parsing. Some people think using an XHTML doctype gains different parsing. It does not. XHTML documents served as text/html are parsed using the same tag soup parser that is used for HTML. As far as browsers are concerned, XHTML served as text/html is just "tag soup with croutons" (an extra slash here and there). Only documents served using an XML content type (e.g. application/xhtml+xml or application/xml) get an XML treatment."

P.S. PROSÍM, programátoři Lupy, v diskusi pod Safari nejde UTF-8, UŽ DLOUHO.

Na jiném místě říkáte, že <!DOCTYPE> určuje jazyk, což ale přímo nesouvisí se zdejším tvrzením. Na rozlišení HTML od XHTML nestačí ani <!DOCTYPE>, ani deklarace jmenného prostoru, ani XML deklarace. Bez MIME typu nevíte nic, můžete si maximálně tipnout. Každý jazyk má jinou syntaxi (ač podobnou).

„Že prohlížeč zpracuje i XHTML, kde některé koncové značky vynecháte a některé neexistující atributy použijete, znamená pouze to, že se snaží chyby v kódu co nejlépe překonat.“
V XHTML musí chybějící koncová značka zajistit smrt a naopak neexistující atribut nikdy nesmí způsobit problémy (maximálně způsobí nevaliditu). Tak to i funguje.

Při MIME typu „text/html“ skutečně všechny prohlížeče vždy užívají HTML parser. Neporozumí zápisu <div /> — pochopí jej jako začátek elementu. Nikdy nepřeloží entity uvnitř <script>u. V DOMu vrací document.doctype vždy null. Jak se tedy pozná, že prohlížeč skutečně zpracovává XHTML?

Je fakt, že většina dnešních prohlížečů zpracuje XHTML jako HTML kvůli text/html.

Mno ale kromě IE bych řekl, že všechny další prohlížeče zvládnou pravé XHTML. Konečně, vyzkoušejte sami:

http://bredy.jinak.cz/index.xml.php

(PS: Tahle stránka samozřejmě existuje i ve variantě text/html), ale přepnout na XML režim je docela dobrý validátor, aspoň co se XML týče :-)

"Ta druhá -- prohlížeče -- vám na XML při 'text/html' dlabe. Posíláte jim zbytečný balast."

Uf, ale díky tomu "zbytečnému balastu" (který prohlížečům vůbec nevadí) tu stránku přečte libovolný XML parser, což je praktický, ne?

"Nachrlit si pro své potřeby svůj XML formát a pro potřeby prohlížečů jejich HTML formát je snadné."

A poněkud zbytečné, když můžu mít obojí najednou.

"Značná část existujících XHTML stránek (i přes snahu autorů) obsahuje fatální chyby, které při 'text/html' nikoho netrápí."

To není argument. (Přišel čas na analogii s autem :-) To je jako kdybych řekl, že rozbité poršáky jezdí dost bídně.

Kdo říkal, že XHTML je poršák?

Vcelku suhlasim s autorom. Este by som pridal par hrejivych slov na stranu W3C. XHTML ako take neprinieslo ziadne zasadne zmeny, kto si skusil par krat spravit web 2.0 vie o com hovorim. Je to na hranici pouzitelnosti. HTML chapem ako nastroj na popis skinov. Nieje to nic ine ako ked si vo WinAmp-e zmenite skin. Len moznosti skinovania beznych windows aplikacii su niekde uplne inde.

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čů.

Článek kritizuje nepřesnosti ostatních, přičemž sám nám přináší snůšku nových a ještě větších. Jistě, mnoho nesmyslů se o XHTML napsalo a mnohé výhody, které se XHTML přisuzují, jsou falešné. Ale stále zbývá mnoho opravdových, o kterých se autor vůbec nezmiňuje.

Dále autor evidentně nemá přesnou představu o způsobu, jakým počítač formální jazyk (tedy značkovací či programovací) zpracovává a s čím to souvisí. O tom svědčí chybná tvrzení, jako "<!DOCTYPE> je odkaz na primitivní schéma, podle něhož může být dokument ověřován k tomu určeným nástrojem" (to skutečně takto zjednodušit nelze), "jeden jediný jazyk XHTML, který je identifikován jmenným prostorem http://www.w3.org/1999/xhtml" (jmenný prostor v žádném případě nedefinuje jazyk, proto XHTML také není jediný jazyk, důvod nepochopení viz DOCTYPE výše) nebo přehnaný důraz účelově kladený na MIME typy, což je podružná záležitost týkající se pouze přenosu dokumentů přes HTTP.

Pokud se tedy chce autor dále nazývat zkomoleným jménem zákonodárce, měl by mít mnohem větší rozhled o informatice obecně, než začne něco sebevědomě hlásat.

„O tom svědčí chybná tvrzení, jako "<!DOCTYPE> je odkaz na primitivní schéma, podle něhož může být dokument ověřován k tomu určeným nástrojem" (to skutečně takto zjednodušit nelze)“
Co tedy <!DOCTYPE> je? Podle 11 dní starého návrhu druhého vydání XHTML 1.1 je FPI v <!DOCTYPE> zjevně nepovinný, takže jedinou smysluplnou informací zůstane adresa DTD, kterou si pochopitelně může webmaster zkopírovat k sobě.
Modelová situace: na začátku dokumentu najdete <!DOCTYPE html SYSTEM "kopie-xhtml11.dtd"> — jak z toho poznáte, že jde zrovna o XHTML 1.1? Má snad prohlížeč tu DTD číst? A když ji přečte, jak z ní pozná, že zrovna tohle je XHTML 1.1 a ne nějaký můj vlastní jazyk s mojí vlastní sémantikou?

„jmenný prostor v žádném případě nedefinuje jazyk, proto XHTML také není jediný jazyk, důvod nepochopení viz DOCTYPE výše“
K čemu podle vás slouží jmenné prostory?

„přehnaný důraz účelově kladený na MIME typy“
MIME typ určuje parser. Nebo by alespoň měl. Ověřit, že se tak v prohlížečích při HTML či XML skutečně děje, je snadné.

„Pokud se tedy chce autor dále nazývat zkomoleným jménem zákonodárce, měl by mít mnohem větší rozhled o informatice obecně“
Nerozumím, jak souvisí zkomolené jméno zákonodárce s rozhledem v informatice.

jedinou smysluplnou informací zůstane adresa DTD, kterou si pochopitelně může webmaster zkopírovat k sobě

Podle mého názoru, ta adresa DTD slouží jako identifikátor. Tudíž prohlížeče nemusí to DTD stahovat, aby věděly, že jde o XHTML. V případě, že si to někdo zkopíruje k sobě, tak to má jiný identifikátor a pak to opravdu není XHTML ale uživatelský formát, který ovšem může být s XHTML shodný. To pak prohlížeč má problém, protože z DTD nevyčte sémantiku. Normální prohlížeč ale doufá, že je stejná, jako v HTML/XHTML a podle toho jedná. Co mu také zbývá jiného.

K čemu podle vás slouží jmenné prostory?

Slouží k tomu, aby nám nekolidovaly značky, které mají v různých jazycích různý význam a přitom stejná jména. Ale nedefinují jazyk. V tomto případě si lze jmenný prostor představit jako množinu značek, tedy abecedu, ze které můžeme tvořit věty, zde dokumenty. Abychom dostali jazyk, potřebujeme k tomu ještě gramatiku jazyka a tu právě definuje DTD. XHTML jsou tedy jazyky nad stejnou abecedou, ale každý má trochu jinou gramatiku.

DTD není nutné pro definování gramatiky jazyka. XSD také definuje gramatiku jazyka a využívá jmanných prostorů. Takže nemáte úplně pravdu.

XSD opravdu je alternativa k DTD, je možné ba i nutné tam pracovat s jmennými prostory, ale tyto jmenné prostory opět nedefinují gramatiku a k tomu tam nejsou. Tu definují jednotlivé elementy XSD.

Pro zpracování dat je však nejdůležitější znát jejich sémantiku a právě jmenné prostory slouží jako identifikace této sémantiky -- máme jmenný prostor pro XHTML, SVG, MathML, XSLT ... Aplikace tak podle jmenného prostoru pozná, zda daný druh XML vůbec dokáže zpracovat.

„Podle mého názoru, ta adresa DTD slouží jako identifikátor.“
Jenže adresa už vůbec nemusí být fixní. XHTML 1.0 i 1.1 (obě vydání obou) říkají, že systémový identifikátor smí být ve vyhovujícím dokumentu změněn.

Zrovna XHTML 1.1 nabízí dvě verze své DTD. Jednak má svoji mamutí modulovou verzi skládanou z cca dvaceti modulů, jednak i sloučenou verzi do jednoho souboru — kopii té prokazatelně používá validátor. Modulová se od sloučené mírně liší. V prvním vydání XHTML 1.1 nevyžaduje modulová žádný element v <body>, kdežto sloučená ano. V druhém vydání zatím ta modulová naopak vyžaduje alespoň jeden element v <body> a sloučená je už dva týdny vadná, neboť na jejím konci kdosi utrousil kus dokumentu.

„To pak prohlížeč má problém, protože z DTD nevyčte sémantiku.“
Jenže uvnitř DTD není určena sémantika, tam se může dozvědět nanejvýš názvy validních elementů, atributů a entit. Není tam řečeno „tohle je nadpis, tohle obrázek, tohle odkaz“.

„Slouží k tomu, aby nám nekolidovaly značky, které mají v různých jazycích různý význam a přitom stejná jména. Ale nedefinují jazyk.“
Kdyby měly pouze bránit kolizi, tak by nepotřebovaly mít k prefixu přiřazenu adresu. Prefix by totiž stejně natvrdo zakotvila DTD a dokument s jinými prefixy či dokument složený z více jmenných prostorů by potřeboval buď svoji DTD se svojí adresou, která by se neshodovala s adresou oficiální DTD, nebo modularizaci + velkou interní podsadu DTD.

Kdybych chtěl do XHTML vložit prvky svého vlastního jazyka, při čemž XHTML i ten vlastní jazyk by měli každý svou oficiální DTD, znamená to, že by kvůli zkombinované DTD neměly výsledku rozumět ani XHTML prohlížeče, ani prohlížeče toho mého jazyka?

Ve stávajícím návrhu druhého vydání XHTML 1.1 je psáno, že se veřejný identifikátor musí odvolávat na oficiální DTD, pokud je přítomen. Z čehož usuzuji, že povinný není. Ale uznávám, že to je jen pracovní návrh.

Domnívám se, že FPI jako obdobu jmenných prostorů chápat nelze. Doporučení XML 1.0 o něm hovoří pouze jako o alternativní pěšince k adrese DTD. Odhlédnu-li od teorie: v praxi prohlížeče podle veřejného identifikátoru jazyk neurčují.

Bez XHTML by většina tvůrců stránek pořád psalo prasácků kódy. Je pravda že oproti HTML strict vlastně nic novýho nepřineslo, ale lidi asi potřebovali zdání nějaké nové supertechnologie kterou musí mít, i když se skoro výhradně jen zkopírovala definice HTML 4.01. Ale HTML se bralo jako Transitional a XHTML jako Strict. A tak jenom se místo pouhopohého přepsání dokumentu do čitelnější podoby stalo nasazení nové technologie a tu už přece stojí za to, no ne? Myslím že to bylo dobrý, tohle pomohlo, ale mrzí mě že tady veškerá snaha skončila. Přece jenom sedm let bez jakékoli změny už je nuda a nejhorší je že bez výhledu na lepší časy. Přirovnání XHTML k mrtvole se mi líbí, ale ne proto že by ho nikdo nepoužíval, používá ho skoro celý internet. Ale nic se s ním neděje, nic novýho, žádnej pohyb... To už umírá celý internet, zůstane tu ležet jak je a nic novýho už nebude? Chce to HTML 5, nebo XHTML 2 nebo cokoli co by přineslo změnu, když už nic jinýho bude se zase o čem hádat :o)

Nesmysl, to s tim nijak nesouviselo. Souviselo to s tim, ze konecne umrel shitozni Netscape 4.x, takze se mohlo hromadne rozjet pouzivani CSS pro designy.

Autor evidentne nepochopil, ze hlavny ak nie jediny, zato vsak podstatny, prinos XHTML oproti HTML je, ze to XHTML je validne XML a preto je s nim mozne pracovat standartnymi xml nastrojmi...

Chamurappi, docela nerozumím, proč máš potřebu prezentovat své myšlenky ruku v ruce s tím, že zesměšňuješ někoho jiného. Jsou ty "citáty" nutné?

Každý se může zmýlit, každý se může nešikovně vyjádřit, to je normální a mám pro to sympatie. Ale rozhodně je nemám pro takové vození se po (případných) chybách jiných.

To mě zase vadí, že Chamurappi nejspíše nebude reagovat zde, ale odcituje si některé reakce komentujících u sebe na webylonu a... zesměšní je tam.

Ale třeba se mýlím a Chamurappi ještě dorazí.

Co jineho cekat od cloveka, ktery musel i na Lupe publikovat pod prezdivkou...

V článku bylo vychrleno spoustu informací, ale minimum mělo nějakou argumentační váhu. Subjektivní závěry vyvozené z úzkého úhlu pohledu jsou prezentované jako objektivní pravda.
Kdo je anonymní Chamurappi, chlubící se jednou propagandistickou prezentací, ale pasující se do role guru značkovacích jazyků?
IMHO na otázku zda používat HTML nebo XHTML si musí každý odpovědět sám. Podpora v prohlížečích je u obou dobrá. Obojí může mít své výhody a nevýhody, ale ty záleží minimálně na způsobu použití, zpracování a vytváření kódu. Jinak nad tím bude uvažovat člověk, který si dělá ve volném čase osobní stránku a jinak profesionální programátor zpracovávávající a generující zdrojové kódy různým způsobem a pracující v týmu.

Koukněte se, co o sobě píše ten mamlas:

Chamurappi

Autor je nezávislý publicista zaměřený na historii webdesignu, značkovací jazyky, JavaScript a W3C specifikace. Na svém webu Webylon.info kritizuje a zároveň nehorázně porušuje webové standardy, za což se ani trochu nestydí.


Nic nechápe, přesto mudruje. Úplně mi připomíná dnešní školní mládež.

Ne, jen nazývám idioty pravým jménem.

Serou mě totiž mudrlanti, co nic neví a kážou bludy. Někteří lidé se totiž webem i živí, takže jim není jedno, jaký markup mu budou psát jeho zaměstnanci.

A když bude lupa vydávat takovéto s**čky místo fundovaných článků, tak tom bude dost lidí tratit.

a ja proc porad nemam uctu ke koderum bez schopnosti odhledu od jejich pisecku...

Chamurapiho web: Webylon.info

Zobrazit zdrojový kód jeho webu:

view-source:webylon.info

A teď mudruj! Jaké právo má člověk, který neumí ani HTML ani XHTML a evidentně ani nezná filosofii XML, psát do lupy články o XHTML? Žádné, ať si slintá do svýho blogu.

Mudruj si co chceš, ten jeho web není validní v žádném markupu.

Ten jeho web není zpracovatelný v žádném XML toolu.

A vyzná se v něm jen prase -- koukal ses na ten Javascript pohřbený uprostřed stránky pod jménem /ui??? Jde vidět, že ještě žádný web nedělal v týmu více lidí (co dělají HTML). Ti by ho velice rychle poslali někam.

O pár komentářů níže jsem ti poslal odkaz na validátor, aby ses přesvědčil, že Webylon je zcela OK. Udělal jsi ze sebe uřvaného sprostého hlupáka. Ten tým více lidí se ti teď asi bude dlouho smát, co? :-)

Zcela evidentně si nic nepochopil :(

ocekavam od nekodera priznani, ze je -li standard pochybny, a implementace ho nedodrzuji, tak se na nej vysere

Dramembejs: děláš tu rozruch, protože špatně komentuješ. Doporučuji navštívit http://webylon.info/K.Lupa , aby jsi věděl jak správně komentovat tento článek.

:-))

Já jsem se o X přestal zajímat ve chvíli, kdy se objevily návrhy typu zrušit _blank u tagu A (věc, kterou považuji za důležitou) nebo nahrazení IMG tagu OBJECTem (to musel navrhnout fakt nějaký magor). Jinak bych také nepřeceňoval zásluhy xhtml na rozšíření css. Různé hacky jsou principielně větší prasárna, než vnořené tabulky.

Hmm ot je zaujimave.A preco potom aj lupa je pisana v xhtml?
xhtml je prirodzeny vyvoj z html. Okrem toho na xhtml mozem pouzivat xml nastroje.

Lupa je napsaná v XHTML 1.0 bez ohledu na dnešní článek – kdysi jsem dal na názory o pokrokovosti a užitečnosti XHTML a začal na ně pomalu jednotlivé weby převádět, což se stalo i nadále používaným zvykem. Lupa mohla být napsána i v HTML 4.01, je to v podstatě jedno.

Změna formátu přirozený vývoj není. Proto o ní lze i po sedmi letech úspěšně pochybovat.

Zrovna na Lupu XML nástroje nepoužiješ, protože na ní zařvou „syntax error“. Nebýt těch stávajících chyb v kódu, mohl bych ji oddstřelit zákeřným komentářem, bohatě stačí tohle: „]]>“.

Ty si doplň vzdělání, srandisto. V HTML:

http://www.w3.org/TR/html4/struct/global.html#edef-HTML

Every HTML document must have a TITLE element in the HEAD section.

XHTML to taky není protože ani nemáš uzavřený tag DIV.

Tak co vřískáš, chamurappi? Neumíš nic a mudruješ... A jen to víc a víc dáváš najevo!

Kdybys používal nejen slovník, ale i MOZEK, tak by ti došlo, že z věty:

"Každý HTML dokument musí mít tag TITLE v sekci HEAD."

Má chamurappi tag TITLE v sekci HEAD? Nemá!

Zase ze sebe děláš hlupáka! Nech už toho!

...tak by ti došlo, že z věty:

"Každý HTML dokument musí mít tag TITLE v sekci HEAD."

plyne, že každý html dokument musí mít i sekci HEAD, která je definována tagem HEAD.

Jenže jste zapomněl na nepovinnost značky HEAD. V kódu nemusí být uveden, prohlížeč si jej musí být schopen na obalení značky TITLE sám přimyslet.

Viz DTD, otevírací i ukončující značka je volitelná:
<!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- document head -->

Validní HTML dokument může vypadat i jen takto (nebude jen asi považován za verzi 4.x):

<title>Prázdný dokument</title>

Já myslel, že rozdíl mezi tagem (značkou) a elementem (prvkem) se učí na první lekci HTML :-). Asi ne, takže to zopakuji:

<head> - značka head
<head><title>název</title></head> - element head

Značka head je nepovinná. Element head je povinný. Co to znamená? Že prohlížeč si značky head doplní sám podle k