Věc veřejná si zaslouží připomínky. Věcné i veřejné. V tomto článku shrnu relevantní reakce, které jsem zaznamenal do 17. prosince 2004. Některé jsem obdržel přes formulář, některé jsem si vyhledal vyhledávačem.
Mým cílem rozhodně není potupit jedince s jiným názorem. Pouze upřesním či obhájím svá tvrzení či řešení a vyvrátím omyly. Tento článek budiž dalším schůdkem pro konstruktivní diskusi. Omlouvám se všem, kdo ho tak nepochopí.
V § S01 mi chybí prohlížeče založené na KHTML (Konqueror, Safari). Nejsou na úrovni MO, ale zase umí spoustu věcí, které neumí IE, včetně toho PNG alfa kanálu.
Autor: llook
Zdůvodnění: Dlouho jsem nad osudem KHTML váhal. Po Mozille a Opeře patří k nejznámějším prohlížečům. U většiny webmasterů zpravidla zakončuje seznam prohlížečů, které znají a považují za použitelné. Bohužel je (zatím ?) příliš málo používaný a nevyplácí se počítat s jeho schopnostmi. Mnoho webmasterů ani nemá možnost (nebo schopnosti) vyzkoušet, jak v něm jejich stránka vypadá. Proto prezentované řešení
Řešení: Kód funkce Bake si můžete upravit dle libosti. Pokud v prohlížeči XYZ zaručeně funguje verze pro Explorer, Mozillu nebo Operu, můžete přiřadit ke znaku daného prohlížeče i detekci XYZ. A když ne, jednoduše vyčleňte další znak. Rozhodnutí čiňte na základě očekávaných statistik webu, který tvoříte.
Co to meleš o komerčnosti W3C? To je nezisková organizace — od toho to .org v adrese, takže prachy ze standardů rozhodně NEMÁ. XHTML zavádí, protože ho podporují mobilní zařízení!!
Autor: nepodepsal se
Reakce na komerčnost: Strávil jsem na W3.org spoustu času a hledal jsem jakékoliv zmínky o neziskovosti. Marně. Naopak jsem našel agitační stránky, které lákají firmy ke členství podobně jako teleshoppingy ke koupi zázračné supervěci na hubnutí. Od členů je inkasován členský poplatek.
Reakce na XHTML: Já osobně bych si nikdy nekoupil mobil, který umí zobrazit jen XHTML. Nejsem sám, nikdo netouží po tom, aby viděl pouze část WWW. Na trhu chytrých zařízení tedy přežijí jen ti, kteří zvládnou zpracovat i HTML. Krom toho: Podpora XHTML v mobilech je pouhým důsledkem existence specifikace. Nebýt jí, mohou být mobily jednodušší a umět jen jeden jazyk.
Stránka se v Mozille při použití application/xhtml+xml opravdu začne vykreslovat až po úplném načtení. Viz Mozilla Web Author FAQ. Ale nemělo by to tak zůstat do budoucna, ve FAQ se píše, že jde o chybu, či spíše nedostatek současného řešení.
Autor: Pachollini, v komentářích na Yuhůově weblogu o webu
Má reakce: Tušil jsem, že lidé pohybující se v blízkosti Mozilly o problému ví a že o něm bude cosi napsáno v Bugzille. Té FAQ stránky jsem si však nevšiml. Při své dedukci v Barnumské reklamě
Na Bugzille najdete několik hlášení tohoto nedostatku XHTML. Pod ním je zpravidla kraťoučká diskuse o tom, jestli je to chyba nebo přirozená vlastnost metajazyku. Všechna tato hlášení končí jako duplikáty chyby 18333. Jak dlouho se o této chybě ví? Teprve pět let. Nikdo ji neřeší.
Zajímalo by mne, jak je to při použití gzip komprese, tipoval bych, že tam se i prosté HTML bude zobrazovat až po načtení celé stránky. A pokud se komprese použije na XHTML, bude rychlost IMHO dostečná i pro modemisty.
Autor: opět Pachollini, v komentářích na Yuhůově weblogu o webu
Má reakce: Specifikace gzip počítá s proudovou kompresí i dekompresí. Žádný známý prohlížeč nečeká na dotažení celé odpovědi. Ona komprese je pouze třešinka na dortu a je jedno, jestli ji umístíte na HTML nebo XHTML. Tak či tak, závěr je stejný: XHTML je pomalejší.
Víte, proč by prohlížeče v XHTML měly čekat na celý zbytek stránky? Protože existují možnosti v CSS2, jak změnit zobrazení celé stránky s načtením posledních deseti bytů.
Autor: Jakub Srb, v komentářích na Yuhůově weblogu o webu
Má reakce: Toto s CSS nesouvisí. Stránka se nezobrazuje postupně, protože rozebrání XML struktury vyžaduje správnou sestavenost a té nekompletní dokument nikdy nedosahuje.
Ale já na W3C vidím jednu velmi přínosnou věc: snaží se uceleně a bezesporně něco definovat. Budu vždycky radši pracovat se systémem, který je takto dobře zdokumentovaný než s jakousi podporou-nepodporou, u níž člověk nikdy předem neví, co se stane.
IE byl nepochybně před nějakými šesti sedmi lety v době slávy verze 4.0 výborný, protože tenkrát plně spoléhal na docela dobře zdokumentovaný jazyk HTML a na CSS kašlal.
Autor: Honza Hučín, v komentářích na Yuhůově weblogu o webu
Reakce na bezesporné definice: Právě, že specifikace z produkce konsorcia jsou mnohdy buď příliš volné, nebo nedomyšlené. Nejpatrnější je to na doporučeních DOM, ta definují pouze třídy objektů (o tom už jsem se zmiňoval
Reakce na podporu-nepodporu: Dokumentace prohlížečů jsou alespoň v případě Mozilly a Exploreru poměrně propracované. I z nich jde vycházet. Celý lesk a celá sláva standardu padá, když stejně nakonec musíte zohlednit potvoru-nepotvoru, prohlížeč návštěvníka.
Reakce na Explorer 4: Tento prohlížeč v době svého vydání už implementoval většinu z HTML 4 (vydaného o rok později) a nemalou část CSS 2 (vydaného o dva roky později). Nemohl vycházet z ucelených doporučení, která ještě neexistovala.
Ziadna Amerika, ziadny objav, nic sa nedeje ;-)
Nech sa prihlasi, kto nevedel, ze XHTML 1.1 ma doporucene spracovavanie dokumentu az ked je kompletny???
(O pár řádků výše:) Moja otazka znalejsim: u XML je to ako?
Autor: rony, v komentářích na Yuhůově weblogu o webu
Hlásím se, kromě mě to nevěděl ani Yuhů. Hulán to označil za blbost, aniž by si to ověřil. Ani při nedávném bajtoprolití během bitvy o XHTML tento argument nezazněl. Je zřejmé, že je triviální, ale není zřejmý.
Reakce na otázku znalejším: U XML je to samozřejmě stejné. Je to hlavně formát XML, který nutí zpracovávat až po dotažení. Jazyk XHTML pouze tuto nevýhodu zdědil v celé její „kráse“.
Pan Leoš Ondra zamířil pár dní po přečtení Barnumské reklamy
Upozornění: Následující citace jsou podle Málkových slov vytržené z kontextu a jejich význam posunut. V zájmu objektivity vás proto nyní žádám, abyste si před jejich přečtením pročetli celou diskusi.
Jak si autor babylonskeho hanopisu nejspíše sám přečetl, ale "takticky" zamlčel, jde pouze o dočasnou záležitost, týkající se pouze aktuální [1] verze Mozilly. Podobně jako v případě gzipovaných stránek [2], které se dříve také nevykreslovaly postupně, což už dnes není problém.
Jenže XHTML je velmi specificky aplikované XML, což není totéž. Jedním z požadavků této aplikace je, že se má XHTML zpřístupňovat renderovací jednotce postupně a tato má provádět průběžné vykreslování [3].
Navíc si ani nemyslím, že by tato chyba Mozilly [nemožnost průběžného vykreslování] nějak škodila autorům nebo čtenářům stránek, protože je v podstatě chrání [4] před stránkami od základu špatně utvářenými, které se stejně zobrazí chybně nebo dokonce přímo ohrozí jejich počítač [5] (vyvoláním chyby vedoucí ke zhroucení nebo k nějakému nestandardnímu chování, využitelnému jako bezpečnostní mezera).
Z HTML je zvykem, že se takový dokument vykreslí postupně (původně snaha o eliminaci problémů s HTML, kde převažovaly [6] prezentační elementy nad obsahem).
Do věci vůbec nepleťte MSIE, protože to s tím nijak nesouvisí. Tento prohlížeč je starší [7] než normy XML a XHTML, proto se řídí jejich drafty a někde vlastními proprietárními standardy.
Je hezké, když se o věci diskutuje, nicméně mě zaráží, především v souvislosti s "babylónskou" kritikou W3C, jak si Češi vždy myslí, že vědí víc [8] než zbytek světa. A to tu nemáme ani půl miliónu uživatelů WWW.
Autor: Vilém Málek, v diskusi k článku Jak používám XHTML
1) Přesněji: týká se verze aktuální a všech předchozích verzí, které MIME typy založené na XML podporují. Problém se neřeší, protože vyžaduje jiný přístup ke XML, než je doporučeno. Žádá si přepsání víceméně celého XML parseru. Nový parser by obsahoval i nové kritické chyby. A bez těch se Mozilla ráda obejde. (Nevylučuji, že se do toho někdo doopravdy pustí.)
2) Zde si pan Málek vymýšlí. Podpora gzip komprese byla nejprve v Netscapu 4, pak Exploreru 4 a o tři roky později v Opeře 4. Již tyto nejstarší implementace dekompresních algoritmů pracovaly proudově (odzkoušeno). Problém s průběžným vykreslováním gzipovaných webů nebyl nikdy.
3) V žádném doporučení, návrhu doporučení, ani poznámce jsem nenašel jedinou zmínku o průběžném vykreslování. Žádný požadavek, žádné ponouknutí.
4) Nemožnost průběžného vykreslování chrání návštěvníka nanejvýš před šokem z rychle reagujícího prohlížeče. Chtěl-li tímto pan Málek vyjádřit, že XML parser chrání návštěvníky před špatně sestavenými stránkami, pak má pravdu. Je však otázka, jak moc je tato medvědí služba žádána. Chybné zobrazení je vždy lepší než žádné zobrazení.
5) V praxi XML parser špatně sestavenou stránku nerozebere. Kdyby ji v hypotetické rovině rozebíral, mohlo by dojít k nepředvídatelnému nedefinovanému chování: zhroucení počítače, návštěvníka i celého vesmíru :-)
6) Důvodem k zavedení postupnému zobrazování byla konkurence. Netscape 4 vykresloval postupně jen málo věcí (jeho chování bylo v tomto ohledu poněkud nedeterministické). Explorer 4 byl v tomto lepší a jedinou závažnou brzdou pro něj byly tabulky. Pro Mozillu a novou Operu už i tato brzda odpadla. Prezentační vs. strukturální značky s tím nemají vůbec nic společného.
7) Jak snadné je zapomínat. Doporučení XHTML je o rok a půl starší než Explorer 6 (tj. i o půl roku starší než Explorer 5.5). Microsoft ignoroval nový jazyk záměrně a podle některých drbů nebude ani prohlížeč v budoucím operačním systému této firmy podporovat XHTML. Tedy, pouze pokud vývojáři neobjeví jeho tajné zázračné výhody.
8) Díky urputnému snažení evangelizátorů je bohužel nesmírně snadné vědět víc než zbytek světa.
Já osobně považuji za absurdní vydávat chování stávající verze Mozilly za argument proti používání XHTML - pokud tak někdo činí, buď není schopen elementární logické úvahy nebo záměrně klame své okolí.
Autor: opět Vilém Málek, v diskusi k článku Jak používám XHTML
Nechci zabíhat do osobních invektiv, takže tu poznámku o elementární logické úvaze raději nebudu komentovat; stejně jako chyby v Málkově článku.
Vycházel jsem z „normy“, ne z Mozilly. On i Explorer rozebírá XML podle doporučení (viz aktualizovaná Barnumská reklama
Z reakcí některých kritiků cítím, že nečetli část R
Chápu správně, že toto serverové řešení by znamenalo skutečně vytvářet stránky pro různé implementace téže technologie? Proč? Není to trochu zbytečné?
Autor: Mark, v komentářích na Yuhůově weblogu o webu
Má reakce: Nejsou obecně zbytečné i kaskádové styly? Slouží jen k tomu, aby web vypadal lépe. Stejně tak řešení Webylonu
Různé implementace téže technologie tu byly, jsou a budou. Pragmatik s nimi počítá a využije jich. Idealista si raději vytyčí jeden ideál. Jeden bod, kolem něhož ohne realitu a na nekompatibility s ideálem spokojeně nadává.
Je dobré, že existuje více proudů a více možných řešení. Prosadí se nejspíš to nejjednodušší. Člověk je z principu líný, a nebude si zbytečně přidělávat práci.
Autor: pájek, v komentářích na Yuhůově weblogu o webu
Má reakce: V tržním prostředí se prosadí to nejúčinnější. Mé řešení je jednoduché, když si na něj člověk zvykne. Výrazně těžší pak je si odvyknout :-)
Osobně používám své řešení převážně z lenosti. Nemusím řešit, proč něco nejde. Nemusím hledat důvody, proč to prohlížeč A zobrazí tak a prohlížeč B jinak. Nemusím pátrat po „svatých“ řešeních. Nemusím hledat kompromisy. Ač se funkce Bake možná zdá někomu na první pohled složitá, její použití mi práci mimořádně usnadňuje.
Testovat, aky je na druhej strane prehliadac, a posielat mu to v prenho pouzitelnej forme?????? A kvoli komu? Aby sa to otvorilo ludom v mosaic a NN4.7? Ako toto moze niekoho napadnut v roku 2004, tak to teda skutocne nechapem.
Autor: Roman, v komentářích na Yuhůově weblogu o webu
Má reakce: Nikoliv kvůli Mosaicu, o tom nebyla řeč. Ten už je dnes naprosto nepoužitelný. Kvůli Exploreru, Mozille a Opeře. Vše ostatní spadá do množiny neznámých prohlížečů. Kdyby existoval skutečný uznávaný standard, bylo by mé řešení zbytečné. Takový ale neexistuje a díky konsorciu
Co já osobně u www technologie postrádám, je možnost přenášet jen rozdíly mezi stránkami.
Autor: Leoš Ondra, v komentářích na Yuhůově weblogu o webuCo se týká možnosti přenášet jen rozdíly, tak to je opravdu obrovská slabina dnešních webových jazyků. Dodnes jsem nepochopil, proč že neexistuje html include na straně klienta. Je sice pár důvodů proti, nejčastěji chybovost výsledných stránek nebo datová kompletnost výsledných dokumentů, ale přijde mi to jako velmi málo prodiskutované téma.
Autor: Yuhů, v komentářích na Yuhůově weblogu o webu
Má reakce: Přenášení rozdílů je skutečně slabinou webu. Lidé z konsorcia měli návrh na nějaký include před nosem už několikrát, např. zde a zde. Rámce a značka <object> jsou prý dostačující.
Možné řešení: V Exploreru od verze 4 je možné využít XMLHttpRequest, v Mozille a Opeře už nyní také. Vyžaduje ovšem zapnuté skriptování a na to nejde spoléhat. Kéž by se informace o něm posílala v HTTP hlavičce.
Konsorcium se nad prosbami inovátorů přeci jen trochu smilovalo a do CSS 2 zavedlo vlastnost content: url('adresa'). Ta by teoreticky měla umožnit vložení čehokoliv před/za cokoliv. V žádném prohlížeči však takové spojení dvou dokumentů nefunguje.
Bylo by zřejmě i v rozporu s filozofií oddělení prezentační a logické části. Já osobně bych raději uvítal značku <include src="adresa">, už jsem si o ní napsal Ježíškovi. Ale asi se na mě vybodne, protože jsem nepsal po celý rok validní kód :-)
Já už se moc těším na XForms (taky bude konečně pořádný důvod pro použití XHTML), jenom to bude mnohem složitější pro začátečníky, kteří si chtějí jenom vytvořit jednoduchou stránku, ti asi zůstanou u staré dobré přechodné verze HTML. A taky si nejsem jist, jestli to MSIE bude umět dřív než za 10 let.
Autor: Pachollini, v komentářích na Yuhůově weblogu o webu
Má reakce: Proč čekat desetiletí na XForms? Pracovní skupina WHAT, jejíž členové jsou zaměstnanci Mozilly a Opery, připravuje vlastní specifikaci: Web Forms 2.0. Jednoduchá na pochopení, jednoduchá na použití. Ani vás nenutí k používání pomalého XHTML. Nativně bude implementována v Mozille i Opeře a se špetkou JavaScriptu poběží i v současných verzích Exploreru. Řekl bych, s trochou nadsázky, že konsorcium W3 dostalo pěknou facku od reality :-)
Těším se na další reakce.
