Další polemika okolo W3C

16. října 2006

•

V několika posledních měsících se podstatně zrychlil vývoj událostí v nitru standardizátora webu, organizace W3C, což způsobilo také přiostření bojů okolo organizace W3C samotné. Roznětkou, která odpálila spor, jenž přesáhl omezený okruh pracovních skupin W3C a přitáhl pozornost dokonce i laické veřejnosti, se stal nestandardní postup pracovníků W3C při standardizaci normy SVG 1.2. Vznikla široká diskuse okolo principů a smyslu W3C, do níž se zapojila řada odborníků z různých oblastí. Redakce Intervalu vám proto přináší překlad článku Davida Barona, o němž se domnívá, že poskytuje výborný vstupní bod do těchto diskusí, které mohou určit budoucnost W3C, a zároveň prezentuje méně obvyklý, ale o to hodnotnější názor na tuto problematiku.

Nedávno vypukla docela slušná polemika kvůli znepokojení komunity okolo prohlížečů z přesunu SVG Tiny 1.2 ze specifikace na Candidate Recommendation (což je název, který W3C používá pro implementační stadium). Ian Hickson (dlouholetý vývojář webových standardů a muž stojící za WHATWG) protestoval proti duplikování prvků mnoha jiných webových standardů. Boris Zbarsky (vedoucí vývojář pro Gecko/Mozilla) protestoval, že skupina nedokázala vyjasnit základní principy a nepostupovala podle postupu W3C, a řekl, že si už nemyslí, že pracovní skupina SVG koná v dobré víře, a že již dále nebude se skupinou SVG spolupracovat. Maciej Stachowiak (vedoucí vývojář pro WebKit/Safari) protestoval proti přidání vlastností textových vrstev do SVG, které ve velké míře, ale s podstatnými rozdíly, duplikují vlastnosti, které již v HTML a CSS existují, a řekl, že si už nemyslí, že má pro výrobce prohlížečů smysl účastnit se na vývoji SVG ve W3C. Ian Hickson také protestoval proti SVG specifikaci, která přidává nový způsob zpracování skriptu, přičemž tento způsob je nekompatibilní s tím, který se používá v HTML na webu. Robert O’Callahan (další vedoucí vývojář pro Gecko/Mozilla) protestoval proti tomu, že v SVG je pro target u odkazů zvoleno chování, které je spíše kompatibilní s WebCGM než s HTML, přestože by měla pro standard zamýšlený pro web být důležitější kompatibilita s HTML. Björn Höhrmann (častý a velmi erudovaný komentátor mnoha webových standardů) popsal podrobně své formální námitky a údajné porušení postupů ve W3C, kvůli kterým byly ignorovány.

Technické připomínky v těchto zprávách jsou jen ty nejposlednější ve velmi dlouhém seznamu připomínek, jsou tucty nebo stovky technických problémů podobného významu. Ale frustrace z celého procesu byla tentokrát vyjádřena mnohem otevřeněji, než tomu bylo v minulosti.

Přibližně ve stejnou dobu vyjádřili znepokojení nad nedostatkem pokroku ve W3C prominentní jednotlivci z komunity webových vývojářů. Jeffrey Zeldman kritizoval W3C za nedostatek zájmu o potřeby webových vývojářů. Eric Meyer (význačný autor CSS) se k těmto obavám přidal a poukázal na to, že Molly Holzschlag při vyvracení Zeldmanovy kritiky vlastně akceptovala jednu z jeho hlavních námitek.

Ačkoli se zpočátku může zdát, že tyto dvě oblasti kritiky spolu nesouvisí, myslím, že spolu vlastně souvisí velmi těsně. Ale vysvětlit jak, to vyžaduje porozumění způsobu, jak W3C vlastně pracuje.

W3C dnes

Základním faktem o W3C, kterému je třeba porozumět, je, že je to konsorcium. Přes 400 společností platí za členství ve W3C, což jim dovoluje podílet se na mnoha činnostech W3C. W3C má přes šedesát technických zaměstnanců, kteří pracují na věcech, za které členové platí.

První věc, která možná čtenáře překvapí, je těch 400 členských společností. Weboví vývojáři se asi podiví, jestli je tolik společností, které dělají prohlížeče nebo webové nástroje? Nebo je zde mnoho středně velkých webdesignérských firem? Ani jedno z toho. A to by mohlo docela jasně vysvětlit to, co Molly Holzschlag nazvala „hrozivá nevšímavost W3C ke skutečným potřebám každodenního světa webu“. Jestliže většina členských společností platí W3C za práci na jiných věcech, pak W3C pravděpodobně skončí tak, že bude na těchto věcech pracovat.

Takže co vlastně členové W3C chtějí? Pro začátek se podívejme na šest oblastí, do kterých W3C rozděluje svou práci: Architektura, Interakce, Kvalita, Technologie a společnost, Všudypřítomný web a Iniciativa pro přístupnost na webu. Dvě z těchto šesti (Kvalita a Přístupnost na webu) se zabývají z velké části úpravami technologií vytvořených v jiných doménách. Z těch zbývajících čtyř jsou věci okolo prohlížečů většinou v Interakci a Architektuře a je to především Interakce, kam se soustřeďuje zájem o vytváření nových standardů platných pro prohlížeče. Takže se zaměřím na to, co členové W3C chtějí od sekce Interakce.

Sledovat cestu peněz je často dobrým způsobem, jak zjistit něčí motiv. Proč by společnosti chtěly být členy W3C? Protože to pomáhá jejich obchodu. Například:

Společnost, která vyvíjí nástroje pro tvorbu webu, může chtít, aby W3C vytvořilo formát, který tyto nástroje mohou produkovat, v naději, že webové prohlížeče tento formát naimplementují a autoři budou jejich nástroje kupovat (zvláště je-li těžké ten formát vytvořit ručně). Podobně společnosti, které prodávají konzultační služby. Jakmile je formát jednou vytvořen, mohou takové společnosti chtít použít W3C k tomu, aby vynutilo implementaci tohoto formátu v prohlížečích.
Velká společnost (nebo skupina firem), které používají webové technologie jako součást svého podnikání, ale ne na webu, mohou chtít ovlivnit standardy, aby vznikly pro ně použitelnější technologie, takže pak mohou při podnikání použít webový software.
Normální konkurenční odvětví, jako výroba software pro mobilní telefony, kde významný počet firem píše software pro výrobce mobilů, může potřebovat fórum pro standardizaci toho, jaké technologie budou pro zasílání obsahu do mobilních telefonů používány. W3C je jedna z organizací vyvíjejících standardy pro toto (hodně význačné) podnikání a některé pracovní skupiny, se kterými jsem přišel do styku, jsou asi ovládané firmami z mobilního průmyslu.
Firma, jejíž podnikání je těsně spojeno s webem (sem bych zařadil některé výrobce prohlížečů a jen několik dalších členů W3C), by mohla mít zájem na zlepšení prožitku uživatelů nebo tvůrců na webu. Obchodní zájmy výrobců prohlížečů nejsou nutně spojeny s vylepšováním webu pro uživatele a tvůrce. Někteří mají alternativní technologie, které webu konkurují, někteří propagují implementace standardů, které jsou použity v jejich prohlížečích pro účely jiné než webové (s konkurujícími požadavky), a někteří mohou mít obchodní zájmy spojené jen s uživateli nebo jen s autory (nevím však o nikom z výrobců prohlížečů, kdo by do poslední skupiny spadal).

Tyto motivy vedou skupiny uvnitř W3C k tomu, aby strávily významnou dobu na věcech, které webu nepomáhají. Například firma, která používá webové technologie v newebovém prostředí, může protlačit problémy, které nastanou v jejím prostředí, na pořad jednání na schůzkách své pracovní skupiny. Vlastně platí W3C, aby experti na technologii (pracovní skupina) vyřešili jejich problémy. A tihle experti jsou často docela ochotní, protože možnost rozšířit svůj vynález na více míst apeluje na ješitnost vynálezce.

Toto je jen drobný problém ve srovnání s časem stráveným nedávnými boji mezi pracovními skupinami a komunitami, s nimiž jsou spojeny. Největší takové dohady panují obecně mezi lidmi zabývajícími se prohlížeči pro osobní počítače (z nichž některé také fungují na mobilních zařízeních) a prohlížeči vyvinutými primárně pro mobilní zařízení. Ačkoli toho o podnikání v oboru mobilních telefonů moc nevím, obecně mám dojem, že mají zájem poskytovat prohlížení webu (avšak kvůli plánovaným cenám se asi bude používat málo a tak pravděpodobně nebude až tak ziskové). Nicméně ale dodavatelé mobilů poskytují spoustu obsahu, který je součástí jejich sítě – obsah, z něhož mohou získat peníze přímo. Jednu dobu požadovali na mobilech software, které podporovalo WML, aby mohli svůj obsah dodávat jako WML, a také chtěli povolit přístup k WML na internetu v naději, že by se vyvinula oddělená síť (web) pro mobily. Pravděpodobně díky kombinaci pomalého rozvoje tohoto Mobilního webu, zvyšujících se schopností hardware mobilních telefonů a politického tlaku organizací jako je W3C, které chtěly raději jeden web než dva (z nichž na jednom by se nedostaly k byznysu se standardizací), se firmy rozhodly přejít k používání webových standardů na svých mobilech, s možná až příliš vysokým cílem skutečné kompatibility s webem.

Kompatibilita je ve skutečnosti v detailech. Vývojáři webových prohlížečů vědí, že být schopen zobrazovat webové stránky vyžaduje být kompatibilní s ostatními prohlížeči nejen podporováním stejných standardů, a chovat se podle toho, co standardy říkají (nebo, aby v některých případech všichni fungovali stejným způsobem odlišně od toho co říkají standardy ), ale i kompatibilitou v drobných detailech, které nejsou ve standardech zmíněny (obzvlášť ve špatně napsaných standardech). Dokonce i když by tato úroveň kompatibility byla dosažena, stále tu jsou velké problémy přinutit ty samé webové stránky, aby fungovaly na desktopech i na mobilních zařízeních, která mají velmi rozdílné klávesnice, keypady, pointery nebo jiná vstupní zařízení.

Jinými slovy, velká část mobilního odvětví používá software, který implementuje některé webové standardy, ale zdaleka není s obsahem webu kompatibilní natolik, aby ho byl schopný používat. Nicméně, oni ve svých ohrazených zahrádkách stále vyvíjejí další obsah. A protože tohle funguje, pohání to jejich vývoj. Udělat to tak, aby to fungovalo přes různé implementace, vyžaduje standardizaci toho, jaké standardy jsou požadovány pro prohlížeče mobilního webu, a standardizování spousty toho detailního chování, které je pro kompatibilitu potřeba. Problém je, že oni nemají moc v úmyslu zvolit chování, které je kompatibilní s obsahem na webu. Nebo něco takového – já vlastně nerozumím těm detailům, ale viděl jsem výsledky.

A tak máme svět, kde mobilní prohlížeče implementují některé z těch samých standardů jako desktopové prohlížeče (HTML, CSS), avšak celkově ne tak dobře, a kde také implementují některé odlišné standardy (například SVG), možná i lépe. Úroveň interoperability mezi těmito dvěma světy není dost vysoká na to, aby se dal snadno vytvářet obsah, který funguje dobře v obou. A tak, přirozeně, když by byly ponechány samy sobě, tyto dva světy by se rozešly do dvou odlišných souborů pravidel pro zpracování nejasností ve standardech, pravidel pro obvyklé „bugy“ (kde by všechny implementace nesouhlasily se standardy stejným způsobem) a případně (nebo možná již) odlišných souborů podporovaných standardů. Jinými slovy, používání technologie založené na stejných základních specifikacích jak pro mobily tak pro desktopy není vlastně nijak užitečné, jestliže implementace těchto specifikací nespolupracují. Avšak vedení W3C a politika W3C zkouší obě strany přinutit ke konvergenci, dokonce i když takovou konvergenci žádná ze stran vlastně nechce. Obecně postup W3C vynucuje použití standardů dokonce i když tyto standardy jsou nevhodné. Takže ať kterákoli strana sporu (desktop CSS nebo mobilní SVG nebo v některých případech jiné komunity uvnitř W3C) jako první sepíše pravidla, na kterých závisí interoperabilita, pak se předpokládá, že to bude oficiální způsob jak řešit nejasnost podle W3C. Takhle je to podle pravidel W3C, ačkoli ani jedné straně se to nelíbí. Z tohoto důvodu jedna strana útočí na druhou a snaží se blokovat pokrok ve specifikacích druhé strany.

Tento obrázek by měl objasnit příčiny obou druhů kritiky popsané výše. Komunita webových prohlížečů musí zastavit ty věci v SVG, které jsou nekompatibilní s webem nebo nejsou pro web vhodné, protože když to nezastavíme, nebudeme nikdy ve W3C schopni chování webu standardizovat. Za druhé, komunita webových prohlížečů příliš nepokročila se standardy relevantními pro web, protože tráví všechen čas bojem s větší komunitou Mobilního webu.

Ideální standardy pro web

Jestliže chceme vyřešit tyhle problémy, měli bychom si rozmyslet, co web opravdu od standardů potřebuje.

Jeden z důvodů, proč chceme standardy, je získat interoperabilitu – situaci, kdy více různých klientů a více různých serverů může spolu komunikovat, či různí autoři a různí čtenáři si všichni mohou přečíst, co bylo napsáno. Interoperabilita může být snadněji dosažena kopírováním než standardizací. Ale standardizace má před kopírováním několik výhod:

Může produkovat interoperabilitu rychleji než kopírování, protože všichni účastníci mohou implementovat ve stejnou dobu a je vyplýtváno méně času na reverse-engineering.
Může zvýšit konkurenčnost trhu redukováním nákladů na vstup (čtení standardů versus reverse-engineering).
Může vylepšit konkurenčnost trhu rozdělením břemene oprav bugů na všechny účastníky, spíše než vložením této zátěže na následovníky vůdce trhu.
Může zvýšit konkurenceschopnost tím, že (pokud se to udělá určitým způsobem) poskytne ochranu proti některým druhům problémů se zákony, jako jsou patentové žaloby.

Abychom získali na webu interoperabilitu, potřebujeme dobře napsané specifikace s jasnými požadavky na konformitu a jasnými požadavky na zpracování chyb. A potřebujeme dobré testy, které ty specifikace důkladně prověří. Web už mnohokrát utrpěl, když špatně napsané nebo špatně testované specifikace způsobily ztrátu interoperability.

Další důležitá věc, kterou je třeba zvážit, je, abychom chtěli vybrat to správné chování pro standardizaci (to není spojeno s tím, proč chceme standardy, chceme to správné chování ať standard existuje či ne). To znamená, že chceme uvažovat potřeby všech účastníků. Pro formáty dokumentů to znamená autory, uživatele a implementátory nástrojů, které používají. (Postup W3C v současnosti spoléhá na implementátory, že reprezentují ty další dvě skupiny. A to ne vždycky moc dobře funguje, někdy dostávají autoři větší zastoupení, jindy naopak.) To zahrnuje i získání vstupů od expertů na záležitosti jako je internacionalizace a přístupnost, které ovlivňují některé uživatele.

Jestliže by web měl mít prospěch z používání stejných standardů, které jsou použity jinde, pak by stálo za to zvážit potřeby dalších potenciálních uživatelů těch samých standardů. Avšak web je dost velký a dost důležitý, takže je nepravděpodobné, že by výhody, které by mohlo přinést přilákání dalších uživatelů (větší uživatelská základna, další nástroje), byly tak velké jako nevýhody (technologie, které jsou pro web méně vhodné).

Jak dál?

Dříve jsem se domníval, že by se W3C mělo zaměřit na věci, které jsou kompatibilní (v pojmech jako architektura, interoperabilita a údržba existujících neproměnných dat) s tím, co je již na webu a je navrženo primárně pro zlepšení webu. Toto přesvědčení mě vedlo ke stížnosti na fragmentaci specifikací formátů a stížnosti na výsledky práce W3C. Nicméně toto přesvědčení není mnoha členy W3C sdíleno a není na pozadí za většinou standardizačního byznysu, který chce W3C dostat, aby získalo nové členy.

Myslím, že takové zaměření je nezbytné, když předpokládáme, že standardy W3C mají být implementovány v prohlížečích – předpoklad, o kterém vedení W3C a někteří členové vehementně tvrdí, že je pravdivý. Je to kombinace tohoto předpokladu (který někteří lidé zastávají) a nedostatek (u ostatních lidí) důvěry v toto úzké zaměření, co vedlo k mnoha nedávným kontroverzím okolo specifikací W3C, včetně těch o SVG, které jsem zmínil výše. Tyto kontroverze pak redukují zdroje pro vývoj toho, co je skutečně důležité pro vývojáře webu.

Výše zmíněné zaměření je také nezbytné k tomu, aby se zajistilo, že všechny specifikace W3C mohou být implementovány společně se zajištěním interoperability. Například, jestliže dvě komunity (řekněme Web a Mobilní web) pracují na stejné základní technologii (řekněme podmnožina CSS používaná v SVG), ale používají různé specifikace (řekněme zbytek CSS nebo SVG), potom obsah vytvořený s použitím jedné z těchto specifikací by mohl záviset na nejasnostech v CSS, které byly vysvětleny určitým způsobem, či na tom, že tam jsou nějaké bugy a obsah tvořený s použitím jiné specifikace, který může záviset na jiných nejasnostech nebo buzích. Toto vytváří prostředí, kde někdo, kdo musí implementovat jak zbytek CSS, tak SVG nad spornou podmnožinou CSS v SVG, nemůže zajistit interoperabilitu s oběmi sadami existujícího obsahu. Což způsobuje, že zmiňované dvě komunity (Web a Mobilní web) se rozcházejí a nakonec třeba ani nepožadují, aby byly implementovány stejné standardy. Jinými slovy, tento úzce zaměřený model funguje jedině tehdy, když W3C produkuje nové specifikace dostatečně pomalu, tak, aby každý, kdo je zainteresován, je mohl implementovat všechny. A toto se do byznys modelu W3C nehodí.

A tak jsem začal věřit v opak. Jinými slovy, vzhledem k šířce záběru aktivit ve W3C nemůžeme dále předpokládat, že všechny specifikace W3C jsou součástí jednoho plánu. Skupinám uvnitř W3C by mělo být dovoleno tvořit specifikace, jejichž vlastnosti se mohou překrývat s ostatními specifikacemi W3C. Žádný člen W3C by neměl být povinen implementovat jakékoli specifikace, nebo kritizován za neúspěch při implementaci jen proto, že specifikace, kterou neimplementoval, je W3C Recommendation. Místo toho by si měly specifikace svými přednostmi u implementátorů, autorů a uživatelů konkurovat.

Přijmout tuto myšlenku vyžaduje, abychom se vzdali něčeho, co někteří považují za významné – možnosti tlačit na Microsoft, aby implementoval ty standardy W3C, které jsou už interoperativně implementovány v Mozille, Opeře a Safari, jako například mnoho částí CSS a DOM. Nebo spíše schopnosti vyvíjet tento tlak na Microsoft na základě toho, že tyto věci jsou standardy W3C. Microsoft uznává legitimitu W3C, protože W3C byla vedoucí organizací pro webové standardy od doby, kdy se Microsoft snažil porazit svého konkurenta, vedoucí sílu trhu, Netscape. Nemyslím však, že by se mělo tlačit na implementaci standardů jen proto, že jsou to standardy W3C, ale spíše kvůli tomu, že vyhovují potřebám autorů a uživatelů. A nemyslím si, že přijetím myšlenky, že by W3C bylo širší než web, nám bere možnost stěžovat si na bugy v existujících implementacích, přinejmenším u specifikací, u kterých již ostatní implementátoři předvedli, že jsou s webem kompatibilní. Nakonec, je potřeba, aby tlak na implementaci nových specifikací skutečně přicházel od autorů, kteří používají ty nové vlastnosti, které implementují Mozilla, Opera a Safari, což znamená, že se tyto enginy stávají interoperabilnějšími, snadněji se pro ně píše a tak získávají větší podíl na trhu. (Navíc, velké organizace budou váhat méně [možná kvůli zákonům?] implementovat nové specifikace vytvořené organizací, kterou již znají, než specifikace vytvořené jinde.)

V žádném případě si nemyslím, že W3C může dál zkoušet být jak úzce zaměřená, tak široká organizace. Myslím, že teď zkouší být obojí najednou, a to přináší technické nevýhody obou přístupů, technické výhody ani jednoho z nich a finanční výhody toho druhého. Přijal jsem fakt, že W3C nebude úzce zaměřená organizace, i když by se mi to líbilo. Vzhledem k tomu si myslím, že W3C a komunita okolo si potřebuje plně uvědomit důsledky toho, že jde o širší organizaci.

Je čas, aby komunita webových prohlížečů přestala útočit na specifikace, které nás z hlediska implementace nezajímají. Jeden z důvodů, proč je tak malý pokrok ve standardech používaných webovými prohlížeči, je, že jsme strávili většinu času prací na standardech bojem proti návrhům ostatních – návrhům, které nezapadají do webu – nebo prací na vylepšení návrhů od ostatních, které nejsou pro autory a uživatele webu nejvyšší prioritou. Měli bychom tvořit a implementovat standardy, o kterých si myslíme, že jsou pro webové prohlížeče vhodné, a zbytek ignorovat. Měli bychom trávit náš čas vylepšováním toho, co weboví vývojáři a uživatelé chtějí, a ne plýtvat jím na méně důležité věci nebo kritiku toho, na čem se nebude pracovat. To vyžaduje, abychom na vedení zvážili, co je důležité, než se do toho zahrabeme – něco, co není vždy snadné a snadno se na to zapomíná. Ale měli bychom to udělat, abychom pracovali na tom, co má smysl.

Informace o překladu

Původní článek: More W3C Controversy (David Baron, 18. 8. 2006)
Překlad: Sušňová, Eva.
Odborná a jazyková spolupráce: Málek, Vilém.
Přeloženo se svolením autora (další překlady).

About translation

Original article: More W3C Controversy (David Baron, 18. 8. 2006)
Translation: Sušňová, Eva.
Language and expert collaboration: Málek, Vilém.
Language of translation: Czech (for readers from Czech and Slovak republics)
Translated with the permission of the author (other translations).