Naprzód ku przeszłości
Czytam ostatnio zatrważające rzeczy dotyczące dyskusji o następnej wersji HTML, znanej jako HTML5. Wydaje mi się, że sprawy zaczynają iść w złym kierunku. Aha - aby nie zawieść stałych czytelników pod koniec artykułu zamieściłem kilka zdań przeciwko zwolennikom XHTML ;-)
Mała wiedza jest rzeczą niebezpieczną
Jak mniemam większość z nas jest świadoma, iż posiadanie małej wiedzy na jakiś temat może sprawić, że staniemy się niebezpieczni zarówno dla siebie, jak i dla innych. Wie się tyle, by móc się wtrącić do rozmowy, ale nie tyle by pojąć konsekwencje tegoż wtrącania się. Doświadczam tego nierzadko zarówno na forach, których tematyką jest webdesign, jak i w życiu codziennym. Ludzie chcą być pomocni odpowiadając na czyjeś pytanie, lecz nie mają świadomości tego co robią i jak bardzo ich odpowiedzi mogą byc czasem szkodliwie. Będąc tego świadomym zamierzam jednak opublikować ten artykuł bazując na maleńkiej dozie wiedzy na temat HTML5. Właściwie nazywanie tego wiedzą jest już lekkim nadużyciem. Prawdopodobnie zupełnie nie mam racji, jeśli chodzi o treści tu zawarte. Spójrzcie na to jak na coś w stylu deklamacji. Lub czegokolwiek…
Wiele osób uważa, iż powinienem stać się członkiem zespołu pracującego nad HTML5; przyczynkiem do takich stwierdzeń ma być moje podejście do wcześniejszych wersji HTML. Odmówiłem z kilku powodów: z siecią łączę się przez modem (mimowolnie); mam swoją pracę i inne zobowiązania; nie jestem z pewnością osobą mogącą tworzyć standardy. Jestem raczej typem człowieka, który potrafi zanalizować istniejący standard, wywnioskować co on oznacza i opisać te wnioski innym bardziej zrozumiałym językiem. Przynajmniej mając dobry dzień… Nie śledziłem bardzo dokładnie postępów grupy roboczej, ale wybrałem kilka smacznych kąsków będących przedmiotem dyskusji. Jest to mała porcja wiedzy, lecz na jej podstawie chcę dowieść niebezpiecznej i niesprawiedliwej gry jaka ma miejsce.
HTML5 - śliskie zbocze?
Jeśli dobrze zrozumiałem, to głównym celem grupy roboczej jest utrzymanie zgodności wstecz z wcześniejszymi wersjami HTML. Ów Święty Graal będzie precedensem podczas poprawiania semantyki, który to akurat obszar moim zdaniem potrzebuje rozwoju. Zgodność wstecz jest dobrą rzeczą. Oznacza to, iż nowe przeglądarki mogą parsować i wyświetlać stare dokumenty bez potrzeby rozgałęziania kodu, co z kolei prowadzi wprost do puchnięcia tegoż kodu. Kłopot w tym, że tę koncepcję można interpretować na różne sposoby. Jeśli dobrze zrozumiałem - podkreślam to jeśli - grupa robocza analizuje jak współczesne przeglądarki radzą sobie zarówno ze współczesną wersją HTML, jak i z wieloma typami błędnego kodu. Pozwoli im to na ustanowienie standardu, który pozwoli na radzenie sobie z błędnym kodem; jest to coś czego niewątpliwie brakuje w specyfikacji HTML4. Wydaje się, że to Dobra Wiadomość. Grupa bada także jak ludzie używali i nadużywali kodu, który uwielbiamy nienawidzić. Na pierwszy rzut oka to także wydaje się Dobrą Wiadomością. Analizując co autorzy kodu używają źle można napisać specyfikację mówiącą jasno o poprawnym zastosowaniu danego elementu. Ale wydaje się, że nie do końca o to chodzi grupie roboczej…
Wręcz przeciwnie, wydaje się iż chodzi tu o przedefiniowanie semantyki istniejących już elementów, aby stare dokumenty ze starych złych czasów były zgodne z nową specyfikacją! Szczerze wierzę, że popełniam w tym miejscu błąd. Bo jeśli nie, to grupa robocza znajduje się z pewnością na śliskim zboczu. Na przykład sugeruje się, aby znacznik ‘p‘ nie odnosił się już tylko do paragrafu w tekście, ale że powinien stać się pewnego rodzaju synonimem dla ‘div‘.
Ot ogólny element blokowy. Czemu? Ponieważ wielu ludzi nadużywało znaczników ‘p‘ dla treści innej niż paragrafy. Dlaczego robię z tego taki wielki problem? Ano dlatego, że elementy w HTML miały dobrze zdefiniowaną semantykę - poza kilkoma wyjątkami. Zmienianie semantyki jest policzkiem dla tych z nas, którzy próbowali na przestrzeni wielu lat tworzyć semantyczny HTML. Jeśli element ‘p‘ nie ma już wskazywać na paragraf w tekście, to znacznie trudniej będzie tworzyć oprogramowanie mające wydobywać semantykę ze stron internetowych. Zupełne przeciwieństwo tego, co W3C ustanowiło jako jeden ze swoich długookresowych celów.
W powieściach Terry’ego Pratchetta (seria “Świat Dysku”) władca Ankh-Morpork używa niecodziennej metody, aby zredukować przestępczość w mieście: pozwala mianowicie złodziejom i zabójcom zakładać swoje cechy, aby kradzieże, rozboje i zabójstwa trwały nadal, lecz legalnie. W wyniku tego wskaźniki przestępczości spadły bardzo wyraźnie. Mieszkańcy miasta wciąż byli napadani, ale przynajmniej dostawali rachunek. Grupa robocza HTML5 zdaje się snuć podobne teorie. Wystarczy zmienić semantykę już istniejących elementów, a liczba źle zakodowanych stron gwałtownie spadnie. Różnica jest taka, że literatura Pratchetta jest satyrą…
W3C zrewidowało specyfikację CSS 2 i zmodyfikowało ją, aby pasowała do rzeczywistych implementacji. Był to zapewne dobry ruch. Lecz kilka lat wcześniej zrobiono to samo z HTML. Wynikiem był HTML3.2; wersja, o której wiele osób chciałoby zapomnieć. Nie można forsować swoich wizji tylko dlatego, że wiele osób coś robi. Miliny twórców nadużywało HTML, głównie z powody ignorancji. Nie sądzę by wierzyli, iż elementy takie jak ‘legend‘ lub ‘input‘ mogły zastąpić paragraf; po prostu chcieli zastosować element blokowy jako linię rozdzielającą inne elementy i użyli pierwszego, który przyszedł im do głowy. Czy naprawdę jest to rzecz godna adaptacji w następnej generacji HTML? Moim zdaniem zmierzamy w ten sposób ku przeszłości. To jak powrót do przyszłości - tyle że na odwrót…
Mieć ciastko i zjeść je zarazem
Chciałbym zawrzeć w tym artykule jeszcze jedną obserwację, którą poczyniłem wiele razy, ale jak dotąd nie miałem okazji, by się nią podzielić z szerszym audytorium. Osoby czytające mój blog (www.autisticcuckoo.net) od dłuższego czasu wiedzą, że uważam używanie XHTML za bezcelowe. Fakt, iż jestem za to odpowiedzialny nie powstrzyma mnie od mówienia, że to śmieszne; traktuję to jako głos płynący z doświadczenia. Tak czy siak, jest wiele osób uważających, że XHTML to najlepsza rzecz od czasu krojonego chleba. Tak naprawdę go nie używają, ale myślą że jednak tak. Dwa najbardziej popularne argumenty za używaniem XHTML są następujące:
- wymusza zgodność nie pozwalając, by znaczniki pozostały niezamknięte;
- może być parsowany przez szybki i mało ważący parser XML, a nie przez wolny i opuchnięty parser HTML.
W porządku. Żaden z tych argumentów nie ma zastosowania, jeśli strona jest serwowana jako text/html, ale na chwilę zostawmy te detale na boku. Wielu krzykliwych członków wspomnianej powyżej grupy lamentuje nad drakońskim traktowaniem błędów przez owe szybkie, mało ważące parsery XML, które są tak pożądane. Uważają, że Złą Rzeczą jest wyświetlanie komunikatu błędu zamiast strony internetowej. Mają rację, ale ze złych powodów… Proponują, aby parsery XML - a przynajmniej te używane do parsowania dokumentów XHTML - podejmowały próbę otworzenia strony mimo błędów budując w zamian poprawne drzewo DOM. Tak samo jak te wolne, opuchnięte parsery HTML. Tym osobom nie przychodzi do głowy, że powodem szybkości działania parsera XML jest to, iż w odróżnieniu od parsera HTML nie musi tracić czasu na radzenie sobie z błędami. Parser XML zawsze oczekuje prawidłowego kodu, na podstawie którego może swobodnie budować drzewo DOM. Jeśli natrafia na coś niespodziewanego, to nie musi się tym zajmować. W rzeczy samej nie jest to od niego wymagane; musi przerwać parsowanie. Nie można mieć ciastka i go zjeść zarazem. Można mieć szybki, mało ważący parser albo parser tolerujący błędy. Ale nie można mieć obu…
PS: Tłumaczenie artykułu i publikacja za zgodą autora…
Skomentuj! niedziela, 27 maj, 2007 Do góry