Nie róbcie tego w domu!

Kiedyś w stosie kaset u mojego starszego kuzyna znalazłem „Kasetę do czyszczenia głowic magnetofonowych typ C-1″. Naturalne pytanie, które powstaje w głowie młodego informatyka w takiej sytuacji brzmi „Jak wygląda kaseta C-2?”. Moja ciekawość niestety nie została zaspokojona ale dowiedziałem się, że za „starych dobrych czasów wszystko musiało być jakiegoś typu i spełniać jakąś normę”. Mam wrażenie, że podobne „normatywne” podejście do życia ma W3C.

Doceniam ich trud w stworzeniu specyfikacji HTML, XHTML i CSS, które są całkiem przyzwoite. Unormowanie XMLa i pochodnych, który stał się standardem (choć osobiście go nie lubię) też miało/ma ręce i nogi. PNG jest w użyciu, SOAP do pewnego stopnia też. Jednak prawie wszystkie pozostałe przedsięwzięcia tej organizacji pozostawiają dużo do życzenia.

Pierwszym momentem, w którym zacząłem się zastanawiać nad sensownością działa W3C był artykuł na A list Apart To hell with WCAG2. Bezlitośnie wypunktowywał mnóstwo niedociągnięć, nowomowę i sprzeczności wewnętrzne:

Curiously, though, and perhaps due to meticulous editing over the years, the big stuff is well camouflaged and, to an uninformed reader, WCAG 2 seems reasonable. It isn’t, and you as a working standards-compliant developer are going to find it next to impossible to implement WCAG 2.

Drugą rzeczą, która przykuła moją uwagę, to fakt, że znaczna część rzeczy „które mogłyby być ustandaryzowane” nie pochodzi z rąk W3C. JavaScript został opisany przez Ecma International, XMPP (zwany też Jabberem) przez XMPP standard foundation i przyjęty przez Internet Engineering Task Force, czy wreszcie JSON żyjący samodzielnie. Flash też de facto jest już standardem. Dzięki temu można powiedzieć, że ponad połowa życia webmastera odbywa się bez wkładu W3C.

Za to W3C wyprodukowała mnóstwo dokumentów „standaryzujących” rzeczy nie będące w użyciu. Ot chociażby: MathML, SMIL czy Timed-text. O reszcie kulturalnie nie wspomnę.

Ostatnia radosna twórczość W3C zaczyna mi powoli przeszkadzać. O ile Emotion Markup Language obchodzi mnie tyle, co zeszłoroczny śnieg, to już los Wigedts 1.0 jest dla mnie jako webdevelopera ważny. Mam więc szczerą nadzieję, że ten standard umrze śmiercią szybką i bezbolesną.

Błędy w założeniach

I nie dlatego, że w jego twórcach nie ma dobrej woli, czy odpowiedniej wiedzy. Po prostu sposób tworzenia tych „standardów” jest zły z założenia.

Jeśli kiedykolwiek projektowaliście API, schemat bazy danych czy jakikolwiek format pliku, wiecie ile z tym jest roboty. Trzeba bardzo dobrze poznać dziedzinę, w której się człowiek obraca, całość zaprojektować i przetestować. Zawsze w pierwszej wersji znajdą się błędy, więc trzeba nanieść poprawki i cały proces powtórzyć. Po wielu żmudnych iteracjach powstaje projekt, który jest coś wart.

Tworzenie specyfikacji powinno odbywać się w identyczny sposób. Najpierw tworzy się jakąś pierwszą wersję, potem ją implementuje, sprawdza czy całość ma ręce i nogi, potem tworzy kolejną wersję, implementuje… i tak aż do skutku. No, to która ze specyfikacji tak powstała?

Tak właśnie ewoluuje HTML, który od wersji 3.2 do wersji xhtml 1.1 zmienił się zdecydowanie na lepsze. Szkic specyfikacji html5 ma jak najbardziej ręce i nogi. W planach jest np. jednoznaczne parsowanie błędnej składni, które rozwiąże wiele problemów. W opracowywaniu tych standardów uczestniczą ludzie z firm jak Apple, Microsoft, Opera i Google oraz członkowie Mozilla Foundation — słowem ludzie mający doświadczenie w tworzeniu stron i przeglądarek.

Jeśli zaś zerkniemy na specyfikację Widgets 1.0, okaże się, że podpisały się pod nią same uczelnie. MIT, Ecrim, Keio i QUT. Nie zauważyłem, by pracował w zespole Widgets ktokolwiek kto rzeczywiście zaprogramował Widgety na szeroką skalę. Ekhm.. Google? Yahoo? Ze świecą by ich szukać. I nie chodzi o to, że na uczelniach nie ma mądrych i dobrych ludzi — ale nie ma tam ludzi z doświadczeniem w tworzeniu rozwiązań przemysłowych.

Z przyjemnością powitałbym jeden wspólny format Widgetów dla wszystkich stron internetowych. Tak, bym jako programista mógł stworzyć widget, który będzie mógł być umieszczony zarówno na iGoogle, jak i na prywatnym blogu bez konieczności wprowadzania jakichkolwiek zmian. No i by mój widget mógł być na tyle inteligentny, by dostosować się do warunków w których został umieszczony.

Przykładowo: tworzę zegar. Jeśli zostałby umieszczony na blogu, mógłbym na tarczy w okolicach godziny 10 umieścić link do komentarza, który się o tej porze pojawił. Na iGoogle zamiast komentarza byłby link do strony na którą wtedy wszedłem z wyników wyszukiwania, wraz z zapytaniem.

Myślicie, że coś takiego jest uwzględnione w specyfikacji? No to ją przeczytajcie. Myślicie, że ludzie z W3C zaimplementują cokolwiek z tego o czym piszą? Pewnie walidator. Zrobią przykładowy widget? Tak w sekcji “non-normative example”. Widget zaś będzie na tyle mały, by nie sposób było natknąć się na problemy skali przemysłowej, które zmuszą autorów do przemyślenia własnych rozwiązań.

Obserwuję na codzień zmagania trójki doświadczonych programistów (dwóch z nich pracuje w technologiach webowych od dziesięciu lat, trzecia osoba pracowała wcześniej w skomplikowanych projektach badawczych) jak próbują stworzyć pewne API. Dyskusje na temat nazewnictwa, metod, sposobu przekazywania parametrów do i z API nie mają końca. Trwa to tak odkąd tylko podjąłem pracę w Google’u. Całość poprzeplatana jest gorącymi okresami implementacji i sprawdzania rozwiązań, intensywnego testowania i przeprojektowywania wielu ważnych elementów. Trzy osoby, pełny etat, 8h dziennie od trzech miesięcy.

W odróżnieniu w cytowanym już wcześniej artykule proces tworzenia WCAG2 opisywany jest tak:

The process is stacked in favour of multinationals with expense accounts who can afford to talk on the phone for two hours a week and jet to world capitals for meetings.

Lista dyskusyjna, dwie godziny telekonferencji co tydzień i spotkania raz na trzy miesiące to być może jest dość, by stworzyć coś tak prostego jak XML. Być może jest to dość, by ustalić format pliku, jeśli ktoś będzie prowadził odpowiednie badania w międzyczasie. Jest to jednak zdecydowanie za mało, by stworzyć rozsądne API, czym przecież specyfikacja Widgetów ma być. Albo język opisu emocji. Albo DOM.

W3C primarily pursues its mission through the creation of Web standards and guidelines. Since 1994, W3C has published more than ninety such standards, called W3C Recommendations.

Rzecz w tym, że standardów da się tworzyć. One tworzą się same. Organicznie, poprzez doświadczenie, ścieranie się konkurencyjnych rozwiązań i walkę na rynku. Tak powstał HTML w obecnej formie (odkąd MSIE i Netscape wkroczyły do walki), tak też powstał CSS. Ewoluowały, dostosowywały się do wymagań rynku i potrzeb webmasterów. Z tego wyrósł standard, który w3c uporządkowało i opisało. Co prawda niewiele przeglądarek jest w stanie tej poprawionej wersji poprawnie obsłużyć, ale jest pewien wspólny mianownik i jest na czym się opierać w dyskusjach.

Co do Widgetów - w tej chwili jest ich tak mało, że tworzenie jakiegokolwiek standardu nie ma sensu. Bo albo się nie przyjmie, albo okaże się, że jest niedostosowany do wymagań i firmy zaczną go ulepszać na lewo i prawo. Lepiej poczekać, zobaczyć co powstanie na rynku i stworzyć dla tego wspólny mianownik. Za rok, półtora. Teraz jeszcze za wcześnie. A wspólny mianownik niech obejmie funkcjonalność Apple Widgets, Yahoo Widgets, iGoogle, Mapplets i co tylko jeszcze zostanie w ciągu tego czasu wynalezione. Strukturalnie zaś niech odda najpopularniejsze z tych rozwiązań, porządkując jego niedociągnięcia i poddając rozsądnej krytyce.

O EmotionML już wypowiadać się nie chcę, bo to już naprawdę czyste science-fiction. Chyba, że EmotionML ma porządkować emotikony ;)