Komentáře k článku

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

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

Zpět na článek

92 komentářů k článku XHTML je mrtvé! Ať žije HTML5! Nebo ne?:

  1. David Grudl

    Super článek.

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

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

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

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

    1. František Kučera

      Re: Super článek.

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

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

      1. Sten

        Re: Super článek.

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

        1. František Kučera

          Re: Super článek.

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

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

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

    2. Oldisy3

      Re: Super článek.

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

  2. Mordae

    doctype u XHTML5

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

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

        Re: doctype u XHTML5

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

  3. petr_p

    Mozilla

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

  4. Rado2

    prečo zlyhalo XHTML

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

    1. František Kučera

      Re: prečo zlyhalo XHTML

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

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

      1. Rado2

        Re: prečo zlyhalo XHTML

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

        1. František Kučera

          Re: prečo zlyhalo XHTML

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

          1. juraj

            Re: prečo zlyhalo XHTML

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

            1. langpa

              Re: prečo zlyhalo XHTML

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

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

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

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

              DTD bych zrušil a nahradil XSD

              1. David Grudl

                Re: prečo zlyhalo XHTML

                To je pravda jen zdánlivá.

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

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

                  1. David Grudl

                    Re: prečo zlyhalo XHTML

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

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

                    1. František Kučera

                      Re: prečo zlyhalo XHTML

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

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

                      1. langpa

                        Re: prečo zlyhalo XHTML

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

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

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

                        1. juraj

                          Re: prečo zlyhalo XHTML

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

                          1. langpa

                            Re: prečo zlyhalo XHTML

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

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

                              1. langpa

                                Re: prečo zlyhalo XHTML

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

                              2. langpa

                                Re: prečo zlyhalo XHTML

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

                      2. langpa

                        Re: prečo zlyhalo XHTML

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

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

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

                      3. juraj

                        Re: prečo zlyhalo XHTML

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

                        1. langpa

                          Re: prečo zlyhalo XHTML

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

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

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

                          1. juraj

                            Re: prečo zlyhalo XHTML

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

                            1. langpa

                              Re: prečo zlyhalo XHTML

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

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

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

                              1. František Kučera

                                Re: prečo zlyhalo XHTML

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

                                *) nebo je snad jiný důvod, proč by někdo psal /> , než že chce prázdný/nepárový element?

                                1. langpa

                                  Re: prečo zlyhalo XHTML

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

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

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

                                    1. bauglir

                                      Re: prečo zlyhalo XHTML

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

                                      1. langpa

                                        Re: prečo zlyhalo XHTML

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

                                        1. bauglir

                                          Re: prečo zlyhalo XHTML

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

                                        2. langpa

                                          Re: prečo zlyhalo XHTML

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

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

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

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

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

                                        3. bauglir

                                          Re: prečo zlyhalo XHTML

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

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

                                        4. langpa

                                          Re: prečo zlyhalo XHTML

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

                      4. David Grudl

                        Re: prečo zlyhalo XHTML

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

                        1. bauglir

                          Re: prečo zlyhalo XHTML

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

                          1. langpa

                            Re: prečo zlyhalo XHTML

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

                          2. František Kučera

                            Re: prečo zlyhalo XHTML

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

                              1. langpa

                                Re: prečo zlyhalo XHTML

                                bez znalosti obsahu entity zahada neni zapis validni.

                                DOM nicmene je:

                                xml
                                  +-- [unknown entity "zahada"]

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

                                1. David Grudl

                                  Re: prečo zlyhalo XHTML

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

                              2. František Kučera

                                Re: prečo zlyhalo XHTML

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

                                1. David Grudl

                                  Re: prečo zlyhalo XHTML

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

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

                                  1. langpa

                                    Re: prečo zlyhalo XHTML

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

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

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

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

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

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

                                    1. David Grudl

                                      Re: prečo zlyhalo XHTML

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

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

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

                                      1. langpa

                                        Re: prečo zlyhalo XHTML

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

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

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

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

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

                                  2. František Kučera

                                    Re: prečo zlyhalo XHTML

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

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

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

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

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

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

                                    1. František Kučera

                                      Re: prečo zlyhalo XHTML

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

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

                                      1. langpa

                                        Re: prečo zlyhalo XHTML

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

                                    2. David Grudl

                                      Re: prečo zlyhalo XHTML

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

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

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

                                      1. langpa

                                        Re: prečo zlyhalo XHTML

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

                            1. langpa

                              Re: prečo zlyhalo XHTML

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

                1. langpa

                  Re: prečo zlyhalo XHTML

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

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

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

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

                    1. langpa

                      Re: prečo zlyhalo XHTML

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

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

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

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

                      1. Jiří KosekAutor příspěvku

                        Re: prečo zlyhalo XHTML

                        Entita samozřejmě značkování obsahovat může, ale musí mít sama o sobě spárované tagy, v SGML/XML se to občas hodilo.

              2. juraj

                Re: prečo zlyhalo XHTML

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

                1. langpa

                  Re: prečo zlyhalo XHTML

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

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

                  1. František Kučera

                    Re: prečo zlyhalo XHTML

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

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

                    1. langpa

                      Re: prečo zlyhalo XHTML

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

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

                      :-)

      2. To je omyl

        Re: prečo zlyhalo XHTML

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

  5. RadekN

    Proč dělat chyby

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

    1. Bubák

      Re: Proč dělat chyby

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

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

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

      1. František Kučera

        Re: Proč dělat chyby

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

      2. NN

        Re: Proč dělat chyby

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

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

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

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

        1. lojza

          Re: Proč dělat chyby

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

    2. alancox

      Re: Proč dělat chyby

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

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

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

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

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

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

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

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

        1. Jerry12

          Re: Proč dělat chyby

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

          1. Pooky

            Re: Proč dělat chyby

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

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

            1. fari

              Re: Proč dělat chyby

              proc by se melo predpokladat nejake zkomoleni?

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

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

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

      1. Naith_cz

        Re: Proč dělat chyby

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

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

      2. Jiří KosekAutor příspěvku

        Re: Proč dělat chyby

        Ano, W3C je zosobnění zla, přímo peklo na zemi.

        Anebo že by to byla organizace složená s členů a těmi členy byli i výrobci prohlížečů, kteří za nic nemohou?

        1. bauglir

          Re: Proč dělat chyby

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

          1. Jiří KosekAutor příspěvku

            Re: Proč dělat chyby

            Doporučuji si něco více zjistit o tom, jak funguje konsorcium W3C.

            Osobně si myslím, že výrobci prohlížečů by neměli mít hlavní slovo — web se nedělá pro výrobce prohlížečů, ale pro uživatele.

            1. bauglir

              Re: Proč dělat chyby

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

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

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

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

  6. juraj

    niekoľko nepresností (?)

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

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

  7. František Kučera

    Zaostalé prohlížeče

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

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

  8. maryo

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

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

  9. emilk

    hrobarem je specifikace nebo implementatori?

    vinim povetsinou specifikaci:

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

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

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

    1. Pavel Šimerda

      Re: hrobarem je specifikace nebo implementatori?

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

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

      1. bauglir

        Re: hrobarem je specifikace nebo implementatori?

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

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3534