• RSS
  • Domů na Webylon
  • Weblog
  • B.13
    •

    Kritika Webylonu, 1. část

    7. února 2007

    Mrzí mě, že se za ty dva roky, co Webylon existuje, nenašel nikdo, kdo by mě rozpitval s takovou důsledností, jako já pitvám jiné.

    Chopil jsem se tedy skalpelu a rozpitval se sám. Všechny podstatné patologické nálezy jsou v tuto chvíli již odstraněny. V tomto článku se rozpovídám o mých faktických omylech a neznalostech.

    A řekl Tim: Budiž křížení elementů

    Hned v prvním článku [K.01] kritiky jsem se dopustil mystifikace:

    Metajazyk GML prošel vývojem a v roce 1980 spatřila světlo světa jeho mutace označovaná SGML (Standard Generalized Markup Language - Standardní zobecněný značkovací jazyk). Tato mutace se stala standardem ISO 8879. Syntaxe už byla shodná s prvním HTML. Jazyk HTML je víceméně jen nejjednodušší aplikací SGML doplněnou o element <a> (tedy odkaz).

    Sir otec Tim dlouhou dobu ignoroval existující SGML standard z roku 1986. Ve svém prvním prohlížeči de facto vynalezl křížení elementů. Anomálií oproti dnešnímu HTML bylo více, viz aktuální podoba článku.

    Vycházel jsem ze špatně informovaných zdrojů, omlouvám se.

    Evangelium přehlížení

    V prvním výčtu zločinů proti kompatibilitě [K.05] jsem kdysi dávno zmínil i následující bod:

    Tento nesmysl jsem asi převzal z referenční příručky Index DOT Html, konkrétně z popisu elementu <col>. Nikde jinde jsem o něm nenašel ani slovo. Což je zvláštní.

    Pamatuji si, že jsem si celý ten seznam po dokončení ověřoval, četl jsem HTML 4.0 i 4.01 a chybu jsem nezaznamenal. Brian Wilson, který vytvořil Index DOT Html, také musel odněkud vycházet, nepatří mezi ty, co si historii domýšlí. Ale odkud? Záhada. Kdybyste někdo našel tu líheň, kde to vzniklo, dejte mi vědět.

    Tím to ale nekončí. Já byl na tuhle chybu upozorněn a přesvědčivě jsem ji obhájil [B.02]:

    V reakci na sedmý bod Evangelia zapomnění [K.05]:

    Asi tu specifikaci HTML 4 nečetl, span se u col používá.

    Autor: Leoš Ondra, v komentářích na Yuhůově weblogu o webu

    Má reakce: Já jsem specifikaci HTML 4 četl a vycházel jsem z ní. Naopak Leoš Ondra vycházel z HTML 4.01. Zanedbatelný rozdíl? Číselně ano, časově ne. Mezi těmi dvěma doporučeními byla dvouletá prodleva. Během té doby vycházely nové verze prohlížečů, vývoj pokračoval a specifikace si naštěstí nikdo moc nevšímal. Pro srovnání: od vydání HTML 3.2 do vydání HTML 4 uběhl jen rok.

    Hm, skvělé. Po nějaké době jsem při náhodném listování staršími specifikacemi pojal podezření, že něco nehraje, a obě citované pasáže (nenápadně) vyhodil. Po další době jsem tento svůj zákrok přehodnotil z „obranného“ na „zbabělý“ a svoji reakci na Lea (nenápadně) vrátil. Od nynějška tam opět chybí. Bohatě stačí, když je tady, ve správném kontextu. A nápadně.

    Omlouvám se za svoji tuplovanou nepozornost.

    Ve výčtu byl ještě jeden bod, který nyní mizí:

    V době napsání článku to byla pravda. Od dubna 2006 MIME typ „text/javascript“ existuje jako RFC 4329 a je zavržený. Bravo, konečně smíte v HTML 4 užívat JavaScript tak, jak ukazuje specifikace. Další MIME typy pro skriptovací jazyky v doporučení uvedené stále neexistují.

    A ještě jedna drobnost:

    Ale houby, <menu> přeci nikdo nezrušil. Tento bod vyškrtávám zejména proto, že se XHTML 2 podrobněji věnuji v jiném článku [K.23].

    Aby čerstvě vykuchaný seznam nebyl tak prázdný, vlepil jsem do něj nekompatibilitu týkající se elementu <button>.

    Barnumská reklamace

    V klíčovém článku o průběžném vykreslování XHTML dokumentů [K.09] jsem se dopustil několika chyb, jejichž opravení zdánlivě popírá vyvozovaný závěr. Proto začnu malou teoretickou mouchou, kterou ten závěr podepřu:

    Zde je skryta ona fundamentální nevýhoda XHTML. Žádná jeho nedotažená část totiž nevyhovuje požadavkům na správnou sestavenost. Část, brána jako celek, neodpovídá označení „dokument“, protože alespoň jeden element (kořenový) nemá ukončovací značku.

    XML dokument se skládá z několika částí, kořenový element ovšem není poslední. Za ním ještě mohou být bílé znaky, komentáře a procesní instrukce. Část dokumentu může odpovídat lexikální definici pro „dokument“, pokud je dotažený kořenový element. Vtipné je, že po dotažení zbytku nemusí být dokument jako celek správně sestavený: stačí neuzavřený komentář. Znamená to tedy, že má černobílý drakonismus další rozměr: čas?

    Textový objekt je správně sestavené XML, pokud brán jako celek odpovídá označení „dokument“.

    Zdroj: XML 1.0

    Nemůže mít. Viz stávající podoba článku.

    Proto je rovněž zakázáno používání skriptovací metody document.write(), prohlížeč by musel JavaScript vykonávat už v době rozebírání XML.

    Tuto svoji starší úvahu podpírající ústřední tvrzení považuji teď za chybnou. Veškeré změny, které je schopna provádět metoda document.write(), jsou vždy proveditelné i zpětně, okamžité vykonávání není třeba. Vygenerovaný kód se v HTML vkládá za právě vykonávaný <script>. Proč by totéž nešlo v XHTML? Každý generovaný kousek kódu by mohl XML procesor velmi elegantně pojmout jako externí rozebíranou entitu. V případě fatální chyby uvnitř by skript vyvolal odchytitelnou výjimku. Jak prosté.

    V Mozille a Opeře document.write() v XHTML nefunguje. Což je jednoznačná chyba těchto prohlížečů, de facto i de jure. Doporučení DOM Level 2 HTML zcela jasně metodu write() obsahuje. Nemá vyvolávat žádné výjimky, má fungovat. Vždy a všude. Bez ohledu na odpustek od Pembertona.

    Teď zamířím k pudlovu jádru:

    Jak s XHTML kódem nakládají nejrozšířenější prohlížeče? Mozilla skutečně čeká, než se dokument dotáhne. Až pak zobrazí buď obsah, nebo chybovou hlášku, pokud kód není správně sestavený.

    Zvolená formulace je pravdivá. V době jejího sepsání jsem ovšem netušil, že Mozilla ve skutečnosti zpracovává XML proudově. JavaScripty vykonává okamžitě, přestože není v době jejich načtení jasné, jestli dokument jako celek je či není správně sestavený. Kdyby jediným účelem XHTML dokumentu bylo zobrazení javascriptového dialogu s textem, v Mozille by mohl splnit účel, i kdyby nebyl správně sestavený. Typický prohřešek proti drakonismu.

    Stejného prohřešku se dopouští i Opera, ta dokonce troufale průběžně vykresluje. S poněkud trpkým úsměvem připouštím, že se jej dopouští ještě jeden prohlížeč.

    Explorer preferovaný typ „application/xhtml+xml“ nepodporuje. Podporuje však jiné XML typy. Konsorcium popisuje způsob, jak tento prohlížeč „trikem“ přesvědčit, aby s XHTML dokumentem zacházel správně. Stačí užít povolený MIME typ „application/xml“ a jednoduchou stylopisovou transformaci. Ani Explorer pak nevykresluje stránku postupně a čeká na její úplné načtení.

    V popsaném triku se užívá XSL transformace, tu Explorer podporuje od verze 5. Řekl bych, že transformace nelze nikdy provádět proudově, ale to je v tuto chvíli vedlejší. Kdo četl Explorerovu oběť [K.32], ten ví, že existuje ještě jeden způsob, jak v Exploreru zobrazit pravé nefalšované XHTML. Velmi málo známý. Našel jsem ho náhodou před rokem a půl.

    Jednou takhle po ránu jsem si při štípání kostí jednoho z mých odpůrců omylem přetnul sekerou síťový kabel zrovna při načítání Explorerovy oběti v Exploreru. A hle: vidím půlku článku a pod ní fatální chybu. Zamrazilo mě při pohledu na tu hrůzu. Dokumentu jsem vystrojil krásný pohřeb a jeho viditelné ostatky jsem si vyblejsknul:

    Další vtipné překvapení skrývá Explorerovo pojetí XHTML v metodě document.write(). Ona v něm totiž funguje.

    Nezbývá než vyřknout ortel: Tři nejrozšířenější prohlížeče umí zpracovávat XML proudově. Mozilla jej zatím neumí průběžně vykreslovat (příští verze bude umět), ale stejně jako Explorer a Opera umí průběžně vykonávat skripty. V Barnumské reklamě jsem vinou neznalosti nesděloval úplnou pravdu, přestože užité formulace pravdivé většinou byly a přestože z hlediska teorie je ona úvaha neprůstřelná.

    Jen tak mimochodem: všechny tři nejrozšířenější prohlížeče podporují vlastnost innerHTML, takže nejste-li mimořádní amatéři, můžete si document.write() hravě doskriptovat. Ale bacha — asi tím trošku nakrknete prohlížeče, které jsou drakonismu věrné a nekonají, dokud nemají jistotu.

    Zasněný vodopád

    Při popisování historie CSS [K.21] jsem zkusil vyvrátit mýtus:

    Je rozšířeným mýtem, že slůvko „kaskádové“ souvisí se selektorovou dědičností konkrétních stylů a vrstvením definic v rámci určitého stylopisu. Původ je ovšem jiný. Vznešenější. Spočívá v uspořádání těchto tří úrovní stylopisů:

    Ve skutečnosti jsem napomohl mýtus vytvořit :-)

    Ano, prapůvodně kaskáda skutečně označovala tři úrovně stylopisů. S příchodem selektorů byl však význam pojmu rozšířen i o tu specificitu (vrstvení, prioritu) definic. Ta kapitolka se už v CSS 1 jmenuje „Cascading order“. Dokonce i Plaváček byl lépe informovaný:

    Chamurappi
    Na straně 245 čtu „Využívejte kaskádu“. Jak mohu jako webmaster využívat kaskády stylopisů prohlížečův-můj-uživatelův? Neplete si autor onoho nadpisu kaskádu s kombinovanými selektory?
    Plaváček
    Kaskádou se, pokud vím, neoznačuje pouze kaskáda stylů uživatel-autor-prohlížeč, ale také algoritmus, který se použije v případě, že více pravidel definuje nějakou vlastnost pro stejný prvek.
    Zdroj: diskuse JPW o knize „CSS Hotová řešení“

    Takže pardon, přestřelil jsem, omlouvám se za nepozornost. Děkuji tisovi za odhodlaný vzdor.

    Neprozřetelná formulace

    Článek o XHTML 2 [K.23] mnohokrát zmínil, že XHTML 1.1 něco „ruší“. V Síle víry [K.26] vydané o půl roku později pak odhodlaně mrštím ostrá slova po každém, kdo říká, že XHTML něco zrušilo.

    Lepší formulace je, že verze 1.1 některé věci „zakazuje“. Na zrušení nemá sílu. Prakticky vzato to ani není nová verze.

    Pokračování příště

    Posypat si hlavu popelem je lepší, než míti na ní máslo. Nechť můj příklad následují jiní.