Názory k článku Webové aplikace podle WHATWG

Jestli to vyjde, to zas bude uceni..

"W3C má na druhou stranu mnohem větší autoritu než "nějaká WHATWG". Případná specifikace od W3C tak snad bude více respektována ze strany velkých firem a organizací."

A odkud W3C bere autoritu? Proc by meli vyrobci prohlizecu jen tak imlementovat neco co vymysli W3C? A co budou respektovat ty velke spolecnosti? Navrh ke kteremu nebude implementace?

"(Je ovšem otázka, do jaké míry je toto potřeba a zda nestačí, aby specifikace podpořili výrobci prohlížečů a Google, což se v případě WHATWG vcelku určitě stane.)"

Urcite stane? Vzdyt se to jiz deje! Vyrobci prohlizecu to jiz dnes implementuji a je jim zcela jedno co si o tom W3C mysli.

Vtip je v tom, ze samotni vyrobci prohlizecu jsou ve W3C.

"Urcite stane? Vzdyt se to jiz deje! Vyrobci prohlizecu to jiz dnes implementuji a je jim zcela jedno co si o tom W3C mysli."

Jo? Mozna tak v minulosti...

"Vtip je v tom, ze samotni vyrobci prohlizecu jsou ve W3C."

Ano to je opravdu vtip. Jsou tam jen do poctu a pritom maji hlavni slovo v tom jak to pak skutecne funguje. Zmena W3C zevnitr byla nemozna a proto vzniklo WHATWG. Az ted se ledy hnuli, protoze uz je jasne ze W3C je bez vyrobcu prohlizecu uplne k nicemu.

"Jo? Mozna tak v minulosti..."

Ano minulost ukazala, jaka je realita a skutecna autorita W3C. A zatim se mi nezda, ze by novejsi verze prestali s implementaci nekterych prvku z WHATWG.

Vtip je v tom, že samotní výrobci prohlížeču jsou členy WHATWG :)

Už vidím, jak se budou řešit problémy s nekompatibilitami mezi prohlížeči a bugy. Toho jsme si užili (a užíváme) s css a javascriptem. Přitom se to celé dá řešit jinou cestou - externí DSL, které se transformuje do HTML + js.

Prohlížeč (FF, IE, Opera) je mimo kontrolu autora stránky. Parser na transformaci je v jeho moci. Myslím, že klienti (prohlížeče) již umí to, co mají umět. Tohle by měl vybojovat server.

Vidím, že si v nekoncepčnosti přímo libujete. Aktualizaci si aplikace nemá řešit sama, ale má ji řešit balíčkovací systém či jiné API operačního systému (distribuce). Představte si situaci, kdy uživatel nemá na daném počítači práva správce, což by mělo být samozřejmostí. Jak potom nainstalovaný prohlížeč aktualizujete? Jak jej jednoduše vzdáleně aktualizuje správce?

Jednoduse proto, ze neexistuje sjednocujici technologie typu KParts v ruznych OS. A domluva na vytvoreni takoveto technologie by byla jeste horsi nez domluva na html standardu. Prohlizece jsou proste takove sandboxy a je to i rozumne z hlediska bezpecnosti a prenositelnosti.

Z krátkodobého pohledu představují WebApplication pravděpodobně přínos, z dlouhodobého napáchají víc škody, než užitku, stejně jako tomu bylo u čtyřkových verzí dvou tehdy oblíbených prohlížečů. Návrh WebApplications mně přesně připomíná toto období, neboť se v něm nekoncepčně vedle sebe objevuje markup, DOM, ne-DOM, objekty prohlížeče, atd.

Více než dříve se ukazuje, že spoustu aplikací má podobné požadavky na technologie. W3C se snaží psát svá doporučení tak, aby vyhovovala co největšímu počtu těchto aplikací. Všimněte si, kolik doporučení převzal ODF, i když nebyla vytvářeny přímo pro něj. Možná je chybou, že některá z doporučení W3C nejsou modulární, takže mohou být implementovány buď plně, nebo vůbec, i když pro některé účely je jejich plná implementace zbytečná. Správným řešení však není vytvoření nové technologie, ale modularizace stávající.

Nechci znovu zažít válku, teď už ne webových prohlížečů mezi sebou, ale mezi webovými prohlížeči a ostatními aplikacemi. Možná to většině uživatelů a programátorů tak nepřijde a považují textový procesor a webový prohlížeč za zcela oddělené aplikace, které spolu nemají nic společného. Já však používám KDE, které obsahuje technologii KParts, takže pro prohlížeč nepředstavuje problém vykreslil vstupní prvek s funkcionalitou textového procesoru. Prostě si jej od textového procesoru "vypůjčí". Pro úspěšnou spolupráci různých "části" je zásadní, aby byly postaveny na nejlépe stejných technologiích.

Pro programátora je rovněž příjemnější, pokud může stejnou technologii použít na straně web serveru, ve webovém prohlížeči či při psaní maker do textového procesoru.

Myslím si, že technologie jako KParts představují budoucnost desktopu. Považuji proto za krátkozraké, když si každá aplikace definuje své vlastní technologie s ničím nekompatibilní. To je případ i WebApplications, které za hranice současných prohlížečů nedohlédnou. Důsledkem toho bude zpomalení rozvoje desktopu jako celku, až nakonec budou WebApplications zavrhnuty a nahrazeny novou technologií. Proč to tedy rovnou neudělat pořádně?

Zastavím se jenom u záležitostí týkajících se skriptování. Nemohu si pomoc, ale návrh mně připadá jako kodifikace bad practice.

Metoda document.write je z pochopitelných důvodů nepřípustná v XHTML. Existuje nějaký důvod, proč ji mít v HTML, aneb čeho díky ní v HTML dosáhnu a nedosáhnu v XHTML?

Metoda document.innerHTML je další zbytečnou metodou a úžasným zdrojem chyb. Co mně tato metoda umožňuje navíc oproti DOM (zejména ve vztahu k objektu DocumentFragment)?

Metoda document.getElementsByClassName představuje zbytečné nekoncepční rozšíření DOM. Její funkci lze pohodlně naprogramovat pár řádky přes mnohem mocnější objekt NodeIterator. (Mimochodem, může mně někdo prosím vysvětlit chování Mozilly a spol. u objektu NodeIterator, zejména ve srovnání s objektem TreeWalker?)

Chování objektu window nemá ve specifikaci WebApplication co pohledávat. Objekt window nikterak nesouvisí s typem dokumentu, který obsahuje, a jeho rozhraní by mělo být stejné pro všechny dokumenty (HTML, XHTML, SVG, ODT, atp.). Objekt window by proto měl být definován v úplně samostatné specifikaci.

To jste mě ne zcela pochopil. Není nutné, aby různá desktopová prostředí v různých OS měla stejnou či navzájem kompatibilní technologii typu KParts, i když by to bylo samozřejmě lepší. Důležité je, aby dokumenty obalené pomocí KParts (či podobné technologie) měly stejné rozhraní, jak komunikovat s rodičovským dokumentem.

Nevím, co si mám představit pod tím, že prohlížeče jsou sandboxy, můžete mně to prosím trochu rozvést? Každopádně přenositelnost prohlížeče není kvůli KParts (či podobné technologii) nikterak ohrožena. Stejně jako má Mozilla knihovnu Necko, která obaluje síťové záležitosti, tak může mít podobnou knihovnu, která bude obalovat KParts záležitosti. Nevyužívat možnosti OS/DE a vše si vytvářet znovu a po svém, považuji za zbytečné plýtvání sil programátorů.

Vám nevadí, že se prohlížeče často chovají z pohledu uživatelského rozhraní jinak, než zbytek desktopového prostředí? Mně velmi.

jenomze, co delat v pripade, kdyz nejpopularnejsi operacni "system" nema balickovaci system? to pak nezbyde nez si udelat vlastni reseni... (osobne jsem cekal, ze microsoft prijde ve vistach aspon s primitivnim balickovacim systemem treba na urovni slackwaru... cekat od nich neco v rozsahu debianu, by byla cira utopie... ale stacil by jenom nejaky pokrok... takto je to k uzoufani)

Kdepak, spravna aplikace se prizpusobi systemu => umi se aktualizoavat sama, ale umi se i podridit balickovacimu systemu. A co se prav tyce, nenili treba mit apliakci jinde nez v /home (jelikoz ji pouziva treba prave jen ten konkretni clovek), neni problem ani s pravy.

Chlapi, na mne moc teoretizujete. Co by kdyby ... Kam se to cely pohne tady nezmenite, takze zbyva jen delat weby, ktere prinasi lidem pridanou hodnotu, at uz je to na pozadi udelany jakkoliv.

Pokusím se načrtnout nějaké (ideální) příklady, snad má vize bude jasnější:

Komponenta obsahuje ODT dokument s odkazy, které potřebuji dále zpracovat v rodičovském dokumentu. ODT implementuje odkazy standardním způsobem přes xlink, takže mohu použít skript předpokládající xlink na odkazy. Jiná komponenta obsahuje SVG obrázek. I SVG implementuje odkazy pomocí xlink, takže opět mohu použít ten samý skript. Vlastně ani nemusím přesně vědět, co se v dané komponentě ukrývá, pouze mně stačí vědět, že odkazy se vždy implementují jako xlink. Je zde vidět, že technologie xlink je navržena tak, že vyhovuje různým aplikacím.

Mám ODT dokument s formulářovými daty, která potřebuji předat webové aplikaci. Zkopíruji část ODT dokumentu s formulářovými do komponenty, což automaticky předvyplní relevantní XForms políčka na webové stránce. Celé je to jednoduše možné proto, že jak webová stránka, tak ODT používají XForms pro práci s formuláři. XForms představují další široce využitelnou technologii.

Jak jsem již psal, WHATWG nedohlédne za hranice současných prohlížečů. Vymýšlení si vlastních doporučení nekompatibilních s doporučeními používaných v ostatních aplikacích povede k další válce prohlížečů, tentokrát však proti ostatním aplikacím.

Ad document.write: Skutečně by mě zajímal takový legitimní příklad použití. Podle mě neexistuje.

Ad innerHTML: Mnohem praktičtější a mocnější je DOM 3 Load and Save. Proč dávat přednost zastaralému a nebezpečnému innerHTML?

Ad getElementsByClassName: Zcela souhlasím s vašimi důvody, proč je tato metoda nekoncepční. Hrubě se však mýlíte ohledně metody getElementById, neboť tato metoda se neváže k žádnému konkrétnímu jménu atributu. Tato metoda se váže k atributu typu ID, jak jej definuje přímo XML. Metoda getElementById tak má smysl i v obecném XML dokumentu, metoda getElementsByClassName nikoliv, což je asi ten nejdůležitější důvod, proč je tato metoda nekoncepční. Mimochodem, pokud se prosadí atribut role, budeme vytvářet další metodu?

Ad window: Webový prohlížeč umí zpracovávat i jiné dokumenty než HTML, např. SVG, proto by objekt window neměl být specifikován jako součást rozšíření HTML.

Ano, hledám čistotu a elegenci, protože si pamatuji, jak se bez rozmyslu přilepovaly nové vlastnosti, když mezi sebou válčily čtyřkové verze IE a NN, a vím, kam to vedlo. Hack na hacku nepřestane být hackem na hacku jenom proto, že se sepíše. Spojení hack na hacku přesně vyjadřuje současnou nekoncepčnost v implementaci některých technologií v prohlížečích. WebApplication nejenže tuto nekoncepčnost kodifikují, ale ještě ji rozšiřují, to je ten problém! Náprava současného stavu spočívá v tom, že se nekoncepčnost odvrhne a implementuje se vše řádně podle doporučení.

Tak nějak. Ian Hickson je prostě natolik kontroverzní osoba, že nějaká rozumná dohoda vypadá dost nepravděpodobně. Já třeba taky nevím, co je lež nebo polopravda, protože jako velká většina lidí "zvenku" nevidím do osobních sporů lidí z W3C. Jsem zvědavý, co z toho nakonec vzejde.

Mě snad z osobních útoků na toho pána obviňovat nemůžete, přitom mé technické námitky zůstávají bez uspokojivé odpovědi a k základní námitce, která by se dala shrnout jako válka prohlížečů proti ostatním aplikacím, jste se nevyjádřil vůbec.

Ad innerHTML: Čeho dosáhnete pomocí innerHTML, toho dosáhnete i pomocí DOM, často mnohem elegantněji. Pro lidi, kteří DOM neumějí používat, se může jevit innerHTML jako srozumitelnější, i když ve skutečnosti je tomu přesně naopak. Co by podle vás měla udělat konstrukce HTMLDivElement.innerHTML = '</div>:<div>' v případě XHTML a v případě HTML? V případě XHTML se zdá toto chování nedefinované, neboť návrh připouští tuto metodu pouze na element třídy document, v případě HTML opravdu nevím a rád se nechám poučit.

Ad getElementsByClassName: A nemůže programátor chtít třeba také jen určité elementy (např. odstavce) s danou třídou? To je možná ještě častější situace. Jak to potom budete řešit? Já bych oba případy řešil shodně -- pomocí XPath, ve verzi 1.0 součást DOM 3. Narozdíl od "vámi" navrhované metody lze XPath použít na libovolný atribut, třeba i role. Snad nemusím dál psát, jakým mocným nástrojem XPath je. (Poznámka: Očekávané zacházení s nmtokens, kam patří i atribut class, je obsaženo bohužel až v XPath 2.0, přesto XPath jednoznačně považuji za mnohem lepší způsob, než přidávání ad-hoc funkcí.)

Ad kvantový skok: Nesouhlasím s vámi, není třeba dělat žádný kvantový skok, stačí postupně implementovat existující doporučení, jejichž implementace citelně chybí. Skupina WHATWG se však pouští do podivné lidové tvořivosti, která webovým vývojářům nakonec přinese víc starostí než radostí.

Já zcela souhlasím s Ritchiem.

ad getElementsByClassName - když se podíváme na vývoj JS frameworků/knihoven, je patrný jasný trend k využívání obecných "DOM query" dotazů na procházení DOM (viz jQuery, base2 atd.). Většinou se využívá syntaxe typu css, ale třeba jQuery používá i zjednodušený XPath. Přitom při využití XPath by toto bylo mnohem univerzálnější a robustnější. Když už taková specifikace existuje, proč vymýšlet další všelijaké obezličky?

Stejně tak DOM - tzv. HTML5 pracuje pokud vím pouze s DOM a připouští dva různé typy serializace (XML a HTML) - v tomto světle má metoda innerHTML ještě horší opodstatnění.

(btw: zajímavá je taky dnešní diskuse na toto téma na http://ajaxian.com/archives/proposal-for-the-w3c-to-adopt-html-5)

O prvním odstavci nemá smysl diskutovat, neboť každý máme jiné zkušenosti. Já se například bez zmiňovaných metod dokáži obejít.

Ad innerHTML: Změrně jsem uvedl příklad, kdy obsah innerHTML není fragmentem dokumentu, ale přitom validitu výsledného dokumentu nenaruší. Pokud by obsah innerHTML měl být tvořen fragmentem dokumentu, očekával bych metodu umožňující vytvořit fragment dokumentu z řetězce u objektu DocumentFragment. (Ve skutečnosti bych ji nechtěl vůbec, když je tu DOM 3 Load and Save, ale pro ilustraci, jak je metoda innerHTML nekoncepční, to snad stačí.)

Ad getElementsByClassName: Jmenujte mi prosím jediný důvod, proč chtít a používat tuto metodu, když lze používat XPath.

Akorat ze budeme muset cekat roky, nez budeme moci prejit (nekompatibilita se starsim prohlizeci).

Jo, ten globalni storage s moznosti predavat si promenne mezi servery vidim jako riziko neprijemnych bezpecnostnich chyb.

Nezlobte se na me, ale nechapu, co jste chtel touto vetou rici:

"Ano to je opravdu vtip. Jsou tam jen do poctu a pritom maji hlavni slovo v tom jak to pak skutecne funguje."

Jsou tam jenom do poctu, a pritom maji hlavni slovo, jak to funguje. Tak bud jedno nebo druhe.