• TwitterRSS
  • Domů na Webylon
  • Blog
    •

    Kritika Webylonu

    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“.

    — 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.
    — 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.

    Nyní se zaměřím na filozofické rozpory a všelijaké protimluvy. Spíše než (sebe)kritika je to obhajoba.

    Co to vlastně řekl Tim

    Hned první článek kritiky [K.01] nesl nejasné sdělení.

    Celá ta stránka je jeden velký blábol, ale nepovím ti, s čím tam konkrétně nesouhlasím.

    — Pajuc na diskusi JPW

    Článek měl rozostřit představu jediného ideálního osvíceného otce World Wide Webu. Zplodil úžasnou věc, nedalo mu to moc práce, nevyžadovalo to žádný talent, žádnou sofistikovanou činnost. To je vhodné si na začátku pochybování o pozici konsorcia uvědomit. Šéfuje mu fyzik, kterému se náhodou povedlo změnit svět. Není to zázračný vizionář, který uskutečňuje svůj velký plán. Musí to být zrovna jeho spolek, kdo vede web k plnému potenciálu?

    Závěr textu „A řekl Tim: Budiž web...“ jsem upravil.

    Roztržka v kaskádovém ringu

    Můj popis historie box modelů [K.10] kritizuje především box model definovaný v doporučení CSS 2. Zmiňuje i, že „správný“ box model byl definovaný už v CSS 1, tedy dříve, než se k jeho implementaci dostaly Netscape a Microsoft. Přesto článek odsuzuje W3C.

    Hromada mých odpůrců v tom zjevně cítí rozpor. Namítají „A není vinen spíše Netscape tím, že porušil CSS 1?“, občas mě pak obviňují z demagogie [B.05] nebo z omylu [B.07]. Ano, v roce 1997 skutečně Netscape porušil doporučení. Ano, porušil jej i Microsoft. Ano, ano, ano, oba dva porušily „posvátný webový standard“. To je z mého článku na první pohled zřejmé, nic z historie netajím, nezamlčuji, nemlžím.

    Asi chápu, v čem je problém. Při čtení Evangelia zapomnění [K.05] část čtenářů přistoupila na férový pohled: „OK, konsorcium a výrobci prohlížečů jsou si rovni, W3C také dělá bordel“. S tímto pohledem pak koukají na celou historii. U box modelů to byl Netscape, kdo jako první zapříčinil nekompatibilitu, tak proč chrlím lávu na konsorcium?

    Protože si konsorcium a výrobci prohlížečů rovni nejsou. Má-li W3C požívat titulu standardizačního tělesa, musí nést za své kroky vyšší odpovědnost než ti, kdo se jeho standardy řídí. Netscape porušil CSS 1, ale tímto svým činem zásadně ovlivnil celý World Wide Web. Konsorcium se s „chybou“ Netscapu nedokázalo vyrovnat. Dělalo, že neexistuje, což je mnohem závažnější provinění.

    Správný standardizátor nejen, že by neměl konflikty vyvolávat, on by měl i ty existující urovnávat. To je přeci jeho poslání — vnášet řád. W3C je vinno tím, že vzniku reálného problému nepředešlo. Příležitost mělo.

    Bdělý vodopád

    V článku o CSS [K.21] jsem se nečekaně rozpovídal o obecnosti:

    Mocná kombinace živlů HTML+CSS+JS nabízí ohromnou rozmanitost. Prostor pro tvořivost, sebeuplatnění, představivost a originalitu. Ten se chtě nechtě zmenší, jakmile od sebe jednotlivé technologie hermeticky oddělíte.

    Tudíž, budete-li ctít svatý ideál obecnosti, nebude vás omezovat?

    Nebude. Ovšem pozor! Jen při vhodně navržených technologiích.

    Článek „Sen vodopádu“ měl kritizovat především vztah k prapůvodnímu pojetí kaskádovosti: na jednu stranu je stylovací jazyk komplikován natolik, že se uživatelské stylopisy nelepí, na stranu druhou se brání zavádění užitečných „programátorských“ komplikovaností. Proti obecnosti a oddělení vrstev nic nemám, naopak jí fandím, a proto jsem závěr svého textu upravil.

    Oběť Netscapu 3.0

    V nekompatibilním článku o nutnosti zpětné kompatibility [K.32] píši:

    Přeci i kdyby Internet Explorer 6 podporoval XHTML přesně tak, jak konsorcium chce, navždy tu bude ta možnost, že na váš web přijde někdo někdo s Netscapem 3.0. S naprostou stařešinou, která stejně, jako nepodporuje stylopisy, nezná ani XHTML.

    Zrovna trojková verze Netscapu nebyla dobrý příklad pro poučování o ideálu universálního přístupu. Ten ideál je dobrá věc. Jenže v historii WWW už došlo k pár karambolům, které svým způsobem představovaly tlustou čáru, tedy sprosté přibouchnutí dveří před nosem nevinných návštěvníků.

    Přibouchnutím dveří pro Netscape 3.0 je kódování UTF-8. Při výchozí instalaci jej nezná. Stránky užívající toto kódování a zároveň znaky s diakritikou jsou v něm dost špatně čitelné.

    Vezmu si třeba ten Netscape 3.0 a jdu do světa:

    Pár čtenářů si všimlo, že Webylon.info užívá UTF-8. Jak to, že v Netscapu 3 funguje znamenitě? Přiznávám, že jsem mu trošku pomohl. Tento web je dodáván v UTF-8 pouze tehdy, díváte-li se na něj v Exploreru, Mozille nebo Opeře. Ostatním prohlížečům dorazí v ISO-8859-2. Takže v Netscapu 3 opravdu běží.

    Omlouvám se za tento optický klam. Pointa článku na něm nezávisí. Netscape 4 už UTF-8 umí, takže jsem „Explorerovu oběť“ upgradoval.

    Tragikomedie o CONCURu

    Když si Jirka Kosek všimnul, že jsem se začal šťourat ve vztahu SGML a XML [K.24], pustil se do mě. A já se pustil do něj [B.08]. Pěkně jsme si o tom popovídali na diskusi JPW. Celý náš spor byl ale mimo téma.

    Kosek mi vytýkal, že SGML CONCUR se vším všudy není v XML použitelný. A já mu na to odpovídal, že SGML CONCUR se vším všudy není zavrženíhodný. Dozvěděli jsme se, že existuje něco jako MuLaX a že je to hezký/ošklivý jazyk. Fajn. Jenže o to mi zpočátku vůbec nešlo. Tragikomedie o Normě vůbec neměla hájit SGML CONCUR se vším všudy. O co tedy šlo?

    Chamurappi
    Splňuje CONCUR podmínky pro to, aby mohl být označen za „celosvětově škálovatelný systém zabraňující kolizi v pojmenování elementů“? Pokud ne, v čem je háček?
    Jirka Kosek
    Každý pohled má při použití CONCUR svůj vlastní !DOCTYPE a ten může být použit jako unikátní identifikátor. [...] Technicky by určitě jmenné prostory šly na CONCUR založit, ale muselo by se např. říci, že je zakázané překřížené značkování. Jenže se to před 10 lety neudělalo, takže je teď pozdě.
    — diskuse JPW o CONCURu

    V tom jsme se nakonec zjevně shodli.

    Základní princip jmenných prostorů tu byl. XML nestaví na základech již hotového, ale převytváří již vytvořené. Tečka. „Tragikomedii o Normě“ neupravím, neb mám pravdu.

    Důrazně upozorňuji, že celá má teorie okolo CONCURu nepočítá s tím, že veřejný identifikátor v <!doctype> je využitelný jako unikátní identifikátor, ale pouze s tím, že by býval mohl být využitelný, kdyby to tak někdo zadefinoval. Ta definice není ani v SGML, ani v XML, což mi Kosek vmetl do tváře:

    Z článku mi připadá, že Chamurappi asi standard SGML nečetl, můžu mu ho zapůjčit. Alespoň tam zjistí, že jeho interpretace toho, co by CONCUR mohl a nemohl, jsou jeho fantazie, standard o ničem takovém nemluví.

    — diskuse JPW o CONCURu

    Na rozdíl od většiny přátel XHTML jsem si plně vědom stávající nesměrodatnosti textu „-//W3C//DTD XHTML 1.0 Strict//EN“.

    Podpora drakonického života

    V článku popisujícím temnou tvář drakonismu [K.34] počítám s tím, že X(HT)ML prohlížeč je povinen selhat na fatální chybě.

    Čím v tom tvém článku hodláš doložit, že prohlížeč musí na ne well-formed dokumentu selhat?

    — thingwath, diskuse JPW týkající se XHTML

    Pár dní před thingwathem stejně zvláštní argument předložil i Jirka Kosek:

    Standard XHTML nikde neříká, že dokument musí být WF, aby se mohl zobrazit. Jen říká, že se dokument musí parsovat podle pravidel XML, a že se musí zkontrolovat WF, ale naštěstí nikde není řečeno, že by se dokument (nebo jeho část) nesměl zobrazit, pokud je WF porušena.

    — Jirka Kosek, delší diskuse JPW týkající se XHTML

    Cením si neotřelosti téhle kacířské myšlenky. Přiměla mě k důkladnému zamyšlení, jestli náhodou není ten proslulý drakonismus jen dalším hluboko zakořeněným mýtem. Zkoumal jsem, zkoumal. Mýtus to bohužel není.

    Specifikace hovoří jednoznačně:

    Striktně vyhovující XHTML dokument je XML dokument.

    — Doporučení XHTML 1.0
    XML dokument
    Datový objekt správně sestavený dle definic v této specifikaci.
    Požadavek správného sestavení
    Pravidlo platící na všechny správně sestavené dokumenty. Porušení požadavků správného sestavení jsou fatální chyby.
    Fatální chyba
    Chyba, kterou vyhovující XML procesor musí odhalit a nahlásit aplikaci. Po setkání s fatální chybou smí procesor pokračovat ve zpracování za účelem nalezení dalších chyb a smí tyto chyby nahlásit aplikaci. Kvůli podpoře opravení chyb smí procesor nezpracovaná data zpřístupnit aplikaci. Nicméně jakmile je odhalena fatální chyba, procesor nesmí pokračovat v normálním zpracování.
    — Doporučení XML 1.0

    Slušný rozbor historického pozadí sepsal před třemi roky Mark Pilgrim.

    Poodstoupím-li pár kroků od specifikací: I kdyby fatální chyby neměly být de jure fatální, v praxi v existujících XML procesorech fatální bývají. Málokdo si troufne status quo záměrně nabourat. Přivodil by si tím spoustu potíží a nic úžasného by nezískal.

    Můj článek „Podpora života“ shrnuje zejména praktické problémy s X(HT)ML prohlížeči. K nim bohatě stačí, že XML specifikace naznačuje oprávněnost trestu smrti. Říkám „ten a ten prohlížeč tady (omylem) zabíjí a tady (omylem) nechává žít“. Zda jde o justiční omyl, to vyhodnocuji dle mého pochopení specifikace. Pokud jsem ji pochopil špatně, pak se pouze prohodí role, ale nebezpečná situace nezmizí. Názorně:

    IE a Mozilla jsou naopak při čtení a zobrazování spíše papežštější než papež.

    — Jirka Kosek, delší diskuse JPW týkající se XHTML

    Klidně mě mučte. Do toho! Donuťte mě uznat, že drakonismus neexistuje. Že prohlížeče jsou vadné. Že dokumenty se zabíjet nesmí.

    A přece se zabíjejí. Článek zůstane nezměněn.

    Očista Kritiky W3C dokončena

    Ale že jí to sluší, co?