Názory k článku WHATWG - budoucnost webu?
-
Ritchie (neregistrovaný)Důrazně se ohrazuje proti tomu, že weboví vývojáři nechtějí, nepotřebují etc. XHTML 2.0 a XForms. Jako weboví vývojář bych právě implementaci těchto standardů v prohlížečích uvítal. Napište rovnou, že vývojáři prohlížečů nechtějí, neumějí etc. tyto standardy implementovat, ale nezaštiťujte se prosím tím, co chtějí nebo nechtějí vývojáři webu.
Nesystémově látat nedostatky HTML formulářů jistě nějaký čas vydrží, ale z dlouhodobého pohledu je to jen odsouvání řešení. -
Ritchie (neregistrovaný)Ad XForms. Především bych uvítal oddělení formulářových dat od prvků formuláře (element instance). Velice to zjednodušuje vytváření formulářů. Elementy help a alert poskytují elegantní možnost, jak uživateli s vyplněním formuláře pomoci. Velice užitečný je prvek switch pro vícestránkové formuláře. Kontrola vkládaných dat je v XForms vyřešena IMO podstatně lépe než ve WebForms. Atribut relevant by se též hodil.
Většinu chybějících věcí lze řešit javascriptem přes DOM, ale nová generace formulářů je tu přece proto, abych DOM musel využívat co nejméně, jinak můžu zůstat u HTMLForms, neboť i ty ve spojení s DOM umožňují prakticky to samé co WebForms. Jako vývojář webu očekávám, že nová generace formulářů bude šetřit můj čas, že nebudu muset psát zbytečný javascript a zbytečné XSLT. WebForms na rozdíl od XForms mé očekávání nenaplňují.
Ad XHTML 2. Používání XForms pro odesílání formulářů. ;-) XHTML 2 je zatím bohužel příliš nezralé, ale pár věcí, které se mi líbí: nové elementy (nl, blockcode, l), řešení nadpisů přes section-h, atribut role. -
Ja rikam jen to, ze se resi picovin*.
to co je, je podle me ok, delam weby a moc mi toho nechybi, formulare staci. jenze nejakej blbec si vymysli, ze neni html ale xhtml a ze se to bude delat jinak. vysledek ? podle me zadnej, stejne je to porad html, tak co resit.
omlouvam se, ale me to ser*, kazdy o tom pise a cetl jsem uz clanek od blbecka z CNN ktery si mysli, ze AJAX je XML a JAVA, opakuji JAVA -
počkejte pár let, vývoj směřuje zpět k "terminálovému" režimu a meta-dokumenty zmizí. UI bude standalone aplikace z kódem přenášeným ze serveru (sandbox apod.), později na serveru poběží vše
idea built-in unifikovaných (s nějakou vizuální a funkční customizací) kontrol v browserech je podle mého názoru obchodně mrtvá. -
N/A (neregistrovaný)vzdyt ten kalendar napisete jednou a volani uz je ten *jeden* prikaz, ktery chcete. zrovna tak validace formularu.
jen je to bohuzel zavisle na skriptovani na strane klient. rekl bych, ze to je ta killer feature, ktera zapricinuje vznik web forms X.0, xforms, atd.
jinak mi pripada, ze vysledkem toho vseho bude, ze browser bude _muset_ podporovat javascript (nebo jiny skript), zatimco ted nemusi. z meho pohledu je uplne jedno, jestli ten validacni skript napise vyvojar browseru, nebo vyvojar webu. -
Implementace Web Forms 2.0 by se měla objevit ve Firefoxu 3.0 (resp. renderovacím jádru Gecko 1.9). Příslušný bug: https://bugzilla.mozilla.org/show_bug.cgi?id=344614 -
Tomáš Pokorný (neregistrovaný)1. Ian Hickson za svou kariéru doslova vděčí W3C. Právě díky práci pro W3C mu bylo nabídnuto zaměstnání v Opeře a později i v Google, což jsou všechno členové W3C.
2. Ian Hickson byl a stále je aktivním členem W3C. Přímo odpovídá za správu CSS Test Suite a do značné míry vede vývoj CSS3. Je tedy spoluodpovědný za stav W3C a jím vydávaných doporučení.
3. WHATWG nevznikla po žádném selhání snahy "o změnu zevnitř W3C", nýbrž jako přímý důsledek kompetenčních sporů mezi skupinou vyvíjející HTML/XHTML a CSS. Část vývojářů CSS pod vedením Iana Hicksona prostě vyžadovala, aby se vývoj HTML/XHTML podřídil jejich představám o tom, jak by měla vypadat spolupráce těchto jazyků s CSS, a odmítla naslouchat jakýmkoli argumentům kohokoli jiného.
4. W3C je sdružením, jehož členy jsou i firmy či sdružení vyvíjející všechny současné prohlížeče. W3C pracuje na základě konsensu, kde výsledek má možnost ovlivnit každý zúčastněný. (Členem W3C je také Google - Ian Hickson, jakožto jeho zaměstnanec, zastupuje zájmy Google ve W3C a nese přímou zodpovědnost za práci W3C.) WHATWG je soukromý podnik Iana Hicksona, kde výsledek záleží výhradně na soukromém rozhodnutí Iana Hicksona... -
1) Nebyl jsem u rozhodování o přijetí Hixieho ani do Opery ani do Googlu, ale předpokládám, že byl přijat na základě jeho znalostí a zkušeností. Ty získal mimo jiné i prací na technologiích Mozilly a to již od roku 1998. Před prací pro Operu byl také zaměstnán u Netscape jako součást QA týmu pro webové standardy.
2) Nejsem si jistý, zda je Ian právě *členem* W3C. Jako přizvaný odborník působí ve W3C CSS Working Group. Není-li členem W3C, není a nemůže ani být spoluodpovědný za stav W3C. Tím méně za doporučení připravenými jinými pracovními skupinami W3C.
3) I taková interpretace je možná.
4) Ian opět nemůže nést přímou zodpovědnost za práci W3C, neboť W3C neřídí a ani jeho významnou část. -
Tony (neregistrovaný)1) Hickson sam na svem blogu jednoznacne priznava, ze nejprve zacal pracovat pro W3C a v dusledku toho pak v ruznych dalsich organizacich.
2) Terminem "prizvany odbornik" je oznacovan kazdy clen pracovni skupiny, ktery neni technickym zamestnancem konsorcia, ale napriklad zamestnancem organizace, ktera je clenem konsorcia. Tedy Hickson je "prizvanym odbornikem", protoze momentalne zastupuje ve W3C zajmy Google, ktery je clenem W3C. V dobe vzniku WHATWG platila Hicksona Opera za vyvoj CSS pro W3C.
4) W3C je konsorciem, v jehoz ramci mohou jeho clenove pracovat na projektech, ktere si sami urci. Zastupci clenu take urcuji celkovou politiku konsorcia. Hickson je zodpovedny za stav a politiku W3C, protoze je clenem ridicich struktur W3C. -
Adam už výše víceméně napsal, co jsem chtěl napsat i já, takže jen doplnění.
K titulku: Žádné informace jsem záměrně nezamlčoval, článek je o WHATWG, ne o Ianu Hicksonovi, proto tam není posána jeho kariéra atd. Ano, historie sporů uvnitř W3C je popsána poměrně stručně, ale stojím si za tím, že dostatečně výstižně a přesně (natolik, jak je to možné pro člověka, který nemá možnost nahlédnout přímo "pod pokličku", tj. do privátních mailing-listů W3C apod.).
Ad 4. Vývoj specifikací WHATWG má možnost ovlivnit každý a je to *mnohem* jednodušší, než u W3C - stačí se přihlásit do mailing listu nebo být na IRC kanálu. Ian je sice ten, kdo nakonec rozhoduje, ale to nevadí. Naopak: Jako on rozumí HTML a prohlížečům na světě málokdo a je dostatečně otevřený naslouchat relevantním argumentům. Podle mě je tento model vývoje mnohem lepší než "design by committee" v podobě W3C.
BTW, WHATWG není rozhodně Ianova soukromá iniciativa, stojí za ní výrobci prohlížečů a Google - který ho za práci na WHATWG i platí. -
Tony (neregistrovaný)Ad "soukrome" mailing-listy: Archivy mailing-listu jsou verejne. Aktualni mailing-listy jsou pristupne vsem, kteri se registruji. Jak se registrovat popisuje Hickson na svem blogu.
Ad vyvoj specifikaci: Jaky je rozdil mezi postupem WHATWG a W3C? V obou pripadech je pracovni postup stejny, lisi se jen jeho zaver - ve W3C je prace prohlasena za hotovou tehdy, kdyz se na tom shodnou clenove skupiny, ktera tu praci dela, zatimco ve WHATWG konci vse ve chvili, kdy Hickson rekne "stop". Nerekl bych, ze to je otevrenejsi nebo efektivnejsi postup. I kdyby Hickson byl sam pan Buh, nemuze o prohlizecich vedet vse.
Za W3C stoji vyrobci prohlizecu a stovky dalsich organizaci, ktere "tvori" internet - vyrobci hardware, OS, software, vysoke skoly, vyzkumne ustavy... Za WHATWG stoji Hickson a jeho pratele. Soukrome. Google neplati Hicksona za praci pro WHATWG, pouze ho nechava pro WHATWG pracovat v casti casu vyhrazeneho zamestnancum Google pro rozvoj vlastnich projektu. Google sam je ovsem clenem W3C a zde ho take Hickson zastupuje ve sve pracovni dobe... -
Na odkazy do member-only mailing listů jsem narazil mnohokrát, např. u Daniela Glazmana http://tinyurl.com/35cwe2. Ano, nová HTML WG má list veřejný, ale to je záležitost cca posledního měsíce. Pokud vím, předtím vývoj probíhal vpodstatě za zavřenými dveřmi (pro veřejnost) a v jiných pracovních skupinách tak probíhá i nadále.
Ad postup vývoje WHATWG: K posouzení efektivity se stačí podívat na výstup po dvou letech práce, otevřenost je zjevně větší než u W3C. Každá připomínka ke specifikacím vznesená v mailing listu je nebo bude Hixiem zodpovězena. A že rozhoduje on sám mi nevadí, naopak, zatím vede specifikacedle mého názoru správným směrem. (Stejně tak mi nevadí, že Linus rozhoduje o kernelu, Guido o Pythonu, apod.)
Jinak mám pocit, že Hixie dělá na WHATWG víc než oněch Googlích 20% času na své projekty, ale jistě to nevím. -
Tony (neregistrovaný)WHATWG zatim pouze popisuje a "standardizuje" stavajici DOM modely HTML/XHTML dokumentu v existujicich prohlizecich. (Sama specifikace HTML5/XHTML5 ma formu rozdiloveho dokumentu vuci standardu W3C.) To je podstatne rychlejsi a jednodussi prace, nez vymyslet neco noveho a specifikovat, jak to ma fungovat. Podivejte se na efektivitu vyvoje CSS3, ktere ma Hickson take pod palcem, a srovnavejte...
WHATWG ma velice jednoduchou pozici - zabyva se jednim jedinym problemem, otazkou zpracovani HTML/XHTML v existujicich prohlizecich. W3C pracuje na mnoha ruznych projektech, pricemz musi tyto projekty navzajem koordinovat, protoze spolu souvisi casto takovymi zpusoby, ktere vubec nejsou na prvni pohled zrejme - a o kterych lide, uzce zamereni na jeden problem, nemaji ani tuseni.
WHATWG neni ekvivalentem W3C, ale neplnohodnotnym ekvivalentem jedne pracovni skupiny. Neplnohodnotnym proto, protoze na rozdil od pracovnich skupin W3C dela jen na tom, na cem se mu zachce, a na ostatni ohled nebere. To je jako vymyslet si vlastni dopravni predpisy, resici situaci na mistnim sidlisti a ignorujici dopravni provoz ve meste, o zbytku sveta ani nemluve... -
Nemáte pravdu: Narozdíl od Web Forms 2.0 není specifikace Web Applications 1.0, která definuje (X)HTML5, psána formou rozdílového dokumentu, ale úplně od začátku. Nekodifikuje pouze stávající věci z HTML/DOM, ale přidává i spoustu nových (jak uvidíte v pokračování článku). A troufnu si říct, že kodifikace existujících funkcí (tj. reverse-engineering implementací) spolu s návrhem nových funkcí tak, aby řešily nejčastější přání tvůrců dokumentů a aplikací a zároveň byly co nejlépe zpětně kompatibilní a pkud možno implementovatelné pomocí JavaScribtu/XBL/IE behaviors i ve stávajících prohlížečích, je minimálně srovnatelně těžká práce jako nárh nějakého standardu "na zelené louce".
Analogie s dopravními předpisy je docela výstižná, ale s dodatkem, že v tom místním sídlišti žije 95% lidí ve městě a poslední dopravní předpisy, které byly vydány, jsou z doby Rakouska-Uherska a myslí především na koňská spřežení. Panuje tedy anarchie. A zdá se, že "ty nahoře" to nijak netrápí. Je v takové chvíli možné lidem vyčítat, že se iniciativně pokusí vymyslet předpisy svoje? -
Kendy (neregistrovaný)Vágní popis některých výstupů několika programů není žádný reverse-engineering, nenechte se vysmát. Reverse-engineering by to byl, kdyby Hickson popisoval algoritmy, kterými ony programy ke svým výstupům došly, a to tak, aby byly použitelné kýmkoli jiným.
To ovšem Hickson dělat nemusí, protože přinejměnším v případě Opery (jakožto spoluautor) a Gecka má k dispozici přímo zdrojové kódy.
A nemusel by to dělat vůbec nikdo, kdyby vývojáři prohlížečů respektovali standardy W3C, které úspěšně ignorují už téměř deset let, místo aby si organizovali vlastní truckonzorcia a trucstandardy. -
kalmir (neregistrovaný)K budoucnosti HTML, resp. plánům W3C, se na svém blogu vyjadřuje Tim Berners-Lee.
-
noname (neregistrovaný)bohužel mají webforms jednu ohromnou nevýhodu - nejsou všechny zpětně kompatibilní a velmbi blbě se pak řeší formulář tak, aby se použil webform v případě, že je v prohlížeči dostupný a jinak aby se použil javascript (když vynechám test, jestli se jedná o operu verze 9, což je nesystémové.
Uvítal bych, jestli někdo znáte řešení jak toho dosáhnout, v každém případě je ale blbé, že prostě do té doby, než to bude podporovat velká trojka (což bude minimálně několik let), tak webforms bez js nevyužijete a s js pak už zas webform nepotřebujete.
A pak jsou tam drobnosti, které mi vadí jako designérovi - že nelze vše stylovat. Třeba si vezměte input type="datetime-local" a představte si, že chcete změnit mezeru mezi date a time, nebo dát time před, nebo pod ... -
Možným řešením je knihovna, která bude WF2 v prohlížečích, které tuto specifikaci nepodporují, implementovat pomocí JavaScriptu. Z pohledu tvůrce formuláře to znamná jeden tag <script> navíc. Při vývoji specifikace se k možnosti tohoto řešení přihlíželo, ale netroufám si tvrdit, že pomocí JS půjdou ve všech prohlížečích nasimulovat úplně všechny funkce WF2.
Nějaké projekty rozvíjející tento směr se dají najít na http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers, ale osobně jsem je ještě příliš nezkoumal (to se asi změní při tvorbě prvních stránek, kde se mi nějaké funkce z WF2 budou hodit).
Se stylováním je to pravda, ale totéž platí i pro některé prvky současných formulářů. -
Lukas Nevosad (neregistrovaný)ad stylovani: podle mne je to spis vyhoda, prohlizec automaticky vybere format data a casu podle lokalniho nastaveni. Predevsim pro vicejazycne weby je to doslova spasa. Stylovat to zrejme do jiste miry pujde, ale z pohledu usera je spis vyhodou, kdyz UI vypada na vsech strankach stejne...
ČLÁNKY DO MAILU