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.
Hned v prvním článku
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.
V prvním výčtu zločinů proti kompatibilitě
- Explorer 3.0 představil tzv. „komplexní tabulkový model”, který umožňuje lépe strukturovat tabulku. Značka sloupce
<col>
měla podle něj atributspan
, který určoval, na kolik sloupců se tato značka vztahuje. Místo tohoto atributu zavedlo konsorcium v doporučení HTML 4 atribut s identickou funkcí pod názvemrepeat
.
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
V reakci na sedmý bod Evangelia zapomnění
[K.05] :
Asi tu specifikaci HTML 4 nečetl,
span
se ucol
používá.Autor: Leoš Ondra, v komentářích na Yuhůově weblogu o webuMá 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í:
- Netscape 2.0 používal atribut
language
pro určení skriptovací jazyku elementu<script>
. Tento atribut uznalo konsorcium až v doporučení HTML 4, ale zároveň ho označilo jako „zavržený“ (tzn. chystá se jeho zrušení). Prý je lepší používat atributtype
s registrovaným MIME typem použitého jazyka. Ovšem pozor: Pro skriptovací jazyky nezaregistrovala IANA (organizace spravující MIME typy) nikdy žádný MIME typ. Typ text/javascript, který uvádí konsorcium, neexistuje.
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:
- Doporučení XHTML 2 bude celé jedno velké přejmenování, např.
<separator />
by měl ekvivalentně nahradit<hr>
. Zavržené a zrušené<menu>
má nahradit<nl />
.
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
Aby čerstvě vykuchaný seznam nebyl tak prázdný, vlepil jsem do něj nekompatibilitu týkající se elementu <button>
.
V klíčovém článku o průběžném vykreslování XHTML dokumentů
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ěť
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.
Při popisování historie CSS
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ů:
- Uživatelův stylopis (případně s nastavenou důležitostí skrze
!important
)- Webmasterův stylopis právě navštěvované stránky
- Interní stylopis uvnitř prohlížeče
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.
Článek o XHTML 2
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.
Hned první článek kritiky
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.
Můj popis historie box modelů
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
Asi chápu, v čem je problém. Při čtení Evangelia zapomnění
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.
V článku o CSS
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.
V nekompatibilním článku o nutnosti zpětné kompatibility
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:
- Webylon.info - funguje znamenitě.
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.
Když si Jirka Kosek všimnul, že jsem se začal šťourat ve vztahu SGML a XML
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
“.
V článku popisujícím temnou tvář drakonismu
Čí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.
Ale že jí to sluší, co?