Vlákno názorů k článku Webové aplikace podle WHATWG od anonym - Vaše námitky zůstávají bez mé odpovědi jednoduše proto,...
-
Vaše námitky zůstávají bez mé odpovědi jednoduše proto, že se na věci zřejmě díváme z dost rozdílného úhlu a vzájemně se nejspíš o ničem nepřesvědčíme. Přijde mi trochu zbytečné tu opakovat víceméně to samé.
K té idei o prohlížečích a aplikacích: Příklady, které jste napsal o vlákno vedle, mi přijdou příliš abstraktní - nemám představu, co přesně máte na mysli (krom obecného "znovuvyužívání XML-based specifikací") a jak by to pomohlo uživateli/programátorovi. Krom toho, jakákoliv široká integrace vyžaduje spolupráci všech zúčastněných - a to je v cross-platformním prostředí s mnoha produkty mnoha výrobců problém. Buďme rádi, že je jistá snaha se shodnout na dalším vývoji aspoň na poli webových prohlížečů. -
ad innerHTML: pak by innerHTML nebylo nic jiného, než zkratka, zjednodušený zápis ekvivalentní operace s DocumentFragment & spol. Zkratka pro často používané operace je praktická, DOM jako takové je dost ukecané a kód se stává nepřehledným.
ad getElementsByClassName: funkce může vnitřně používat XPath, nicméně musí také ošetřit vstupní řetězec a poskládat z něj požadavek pro XPath. V praxi bude kód srozumitelnější, jednodušší a méně náchylný k chybám, když se použije hotová funkce nazvaná getElementsByClassName, než opakování sekvence operací s voláním XPath.
Nevnímám innerHtml a getElementsByClassName jako něco, co nelze řešit před DOM. Naopak. Jde ale také o přehlednost kódu a pohodlí programátora. -
Ritchie (neregistrovaný)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. -
karf (neregistrovaný)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.
-
karf (neregistrovaný)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) -
Richie, zcela chápu vaše výhrady k innerHTML & document.write() z pohledu čistoty návrhu systému. Jenže mrška zkušenost říká, že čisté, nebo řekněme akademické řešení, bývají pohříchu nepraktické. Takže neškodí se pokusit dohlédnout za hranice, které vytváří současná představa o ideálním DOM, a nenechat se jí omezovat.
Svým způsobem ve světě ideálního DOM nemá jeho reprezentace ve formátu HTML místo - vyžaduje generování na straně serveru a poté parsování na straně prohlížeče, umožňuje zápis vadných dokumentů, atd. Přesto tu HTML je a je nesmírně populární. A pokud připustíme HTML, nechme žít HTML a DOM v úzké vazbě. Třeba přes document.write nebo innerHTML. Totiž document.write není vlastně nic jiného, než psaní HTML v textovém editoru (přeneseně - jednou píše webdesigner, podruhé skript).
Zcela souhlasím s tím, že obsah vkládaný přes innerHTML by měl být wellformed, tedy '</div>:<div>' by bylo nepřípustné. Je to ale čistě věcí dohody a implementátoři to pouze uvítají.
ad getElementsByClassName - opět je lepší se zbavit "XML klapek" na očích. Jasně, getElementsByClassName nemá smysl v obecném XML, jenže v praxi smysl má jak noha. A není to pak spíš problém XML? Je 100% abstrakce skutečně spásou? A nepopírá XML samo sebe, když definuje i ryze neabstraktní atribut lang?
Nechci tímto otevírat polemiku, nemusíte odpovídat, jen jsem nahlas uvažovat, třeba to někoho bude inspirovat. -
Ritchie (neregistrovaný)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í. -
innerHTML: Protože je to jednoduše pochopitelné a všude to funguje? Jasně, není to čistý způsob, ale innerHTML je jedna z věcí, která se dle mých zkušeností při psaní větších aplikací čas od času opravdu hodí. K DOM3 Load and Save se nechci vyjadřovat, protože toho o této specifikaci nevím dost, abych posoudil její praktičnost.
getElementsByClassName: Máte pravdu s typem v DTD, třída je obyčejný CDATA, ale to není věc, na kterou kouká tvůrce aplikace. Pro tvůrce aplikace je u elementu důležitý především název, ID a třídy. Třeba v selektorech CSS jsou tyto věci postaveny na jednu úroveň. V DOM se doposud dalo vyptávat na elementy jen podle názvu a ID, podle třídy ne, a to je z praktického hlediska asymetrie, kterou specifikace řeší. Z pohledu tvůrce aplikace lze klidně za nekoncepční považovat současný stav.
Pokud bude atribut role ve skriptech používán srovnatelně intenzivně jako dnes class, pak bych proti příslušné metodě asi nebyl.
Ano, jednou možná dojde ke "kvantovému skoku" do stavu s nižší energií, kterým bude nějaká čistější a elegantnější infrastruktura webu. Problém je, že energie nutná k tomuto skoku je velmi vyská a není zdaleka jasné, že se to celkově vyplatí. Navíc se to určitě nevyplatí z krátkodobého pohledu jednotlivým účastníkům, a to má v tržní ekonomice velkou váhu.
Otázkou také je, zda by jakákoliv jiná infrastruktura pod tlakem evoluce a trhu nebyla zdeformována do něčeho podobného dnešnímu stavu. Mám pocit, že to je osud každé technologie, která je reálně používána a vyvíjena. (Takový softwarový druhý termodynamický zákon.)
Viz také http://www.jwz.org/doc/worse-is-better.html -
Ritchie (neregistrovaný)
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í.
-
document.write: Je to legacy věc, ale pravděpodobně existují i legitimní use-casy, které nejsou vyřešit jinak (na konkrétní příkald si teď bohužel nevzpomenu, ale třeba mě někdo, kdo s document.write běžně pracuje, doplní). Tím neříkám, že je to hezká funkce, naopak.
innerHTML: Oproti DOM umožňuje navíc kratší kód a vložení kusu HTML vygenerovaného serverem přímo do stránky (častá věc u AJAXových aplikací). Praktické.
getElementsByClassName: Nevím, v čem je to nekoncepční - tím, že se funkce váže ke konkrétnímu atributu a jeho sémantice (seznam tříd)? To by mohlo být nekoncepční taky getElementById. Tahle metoda se často implementuje, její zařazení do specifikace je IMO správným krokem v duchu "simple things easy, difficult things possible".
window: Opět legacy. Objekt s typem dokumentu souvisí, leckteré jeho vlastnosti nemají smysl mimo webový prohlížeč, a tedy ani v jiných formátech.
Celkově mám pocit, že hledáte ve Web Applications čistotu a eleganci, které tam ale příliš není. Specfikace je právě o akceptaci současného stavu a toho, že se hned tak nezmění, byť je to často hack na hacku. Jediná cesta vpřed za takové situace je kodifikace současné praxe a inkrementální vývoj (tam už snha oeleganci význam samozřejmě má). -
Ritchie (neregistrovaný)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.
