Dlaczego XHTML to zły pomysł

Opublikowano: 6 listopada 2006 2006 19:46 w kategorii » (X)HTML/CSS, Standardy

Na początek wyjaśnienie: niniejszy artykuł jest swobodnym przekładem na język polski (polskawy?) artykułu Why XHTML is a bad idea Emila Stenströma, który prowadzi blog Friendly Bit. Jak powszechnie wiadomo (a może i nie) przekłady są jak kobiety: albo wierne, albo ładne :D Tłumaczenia dokonałem oczywiście za zgodą Emila. Miłej lektury:

Kiedy rozmawia się o różnego rodzaju standardach sieciowych, często wspominany jest XHTML. Wiele osób wierzy, że jest on przyszłością sieci. Jestem innego zdania i ten artykuł wyjaśnia moje rozumowanie.

Trochę historii HTMLa
XML wkracza na scenę
„Sprawmy, by HTML działał jak XML”
Problem z używaniem XMLa w sieci
Nie możemy oczekiwać by początkujący używali XHTMLa

Trochę historii HTMLa

Dawno temu, w 1990 roku, pierwsze części HTML weszły w użycie. Został stworzony specjalnie do dokumentów naukowych i nie zawierał żadnych elementów strukturalnych. Pomysł był taki, aby to właśnie użytkownik decydował jak powinien wyglądać dokument; ostatecznie raporty czyta się dla ich zawartości, nie dla ich wyglądu. Docelową „publicznością” dla HTMLa byli oczywiście naukowcy i inni obeznani z komputerami ludzie: w jakimś sensie programiści.

Wkrótce sieć wkroczyła do głównego nurtu. Wszyscy surfowali w sieci i wiele ludzi posiadało swoje strony WWW. Ale nikt nie dbał o jakość kodu i większość stron zawierała poważne błędy. Pomimo tych błędów większość stron „jakoś działała”, to znaczy, wyświetlało się to, co autor chciał pokazać. Wszystko dzięki obsłudze błędów w aktualnych przeglądarkach.

Rozgniewana społeczność programistów/webmasterów od początku narzekała na zły kod i domagała się, byśmy zmuszali ludzi to tworzenia kodu poprawnego. W przeszłości byłem częścią tej grupy.

XML wkracza na scenę

Około roku 1998 ukazała się specyfikacja języka XML. XML jest językiem, który ułatwia konstruowanie własnych języków. Pomyśl o nim jak HTMLu, gdzie tworzysz swoje własne tagi, ale nie dopuszcza się tworzenia błędów. Programiści bardzo go polubili i szybko rozpowszechnili.

XML ma bardzo precyzyjnie zdefiniowaną obsługę błędów (w przeciwieństwie do HTMLa): kiedy parser znajdzie coś niespodziewanego zatrzymuje się i wyświetla błąd. Daje to przede wszystkim dwie rzeczy. Pierwsza z nich sprawia, że edytowanie XMLa bliskie jest „prawdziwemu programowaniu” - jeśli popełnisz mały błąd program nie kompiluje się. Druga: ponieważ nie ma potrzeby programowania obsługi błędów, parser staje się szybszy i łatwiejszy do napisania. Programiści czuli się jak we własnym domu.

„Sprawmy, by HTML działał jak XML”

Założono konsorcjum W3C i programiści z rozgniewanej społeczności HTMLa wywarła na konsorcjum wrażenie. W3C postanowiło zrobić coś w sprawie nędznego kodu pisanego przez ludzi i ustandaryzowała nowy język dla sieci. XHTML wziął tagi z HTMLa ale dostosowano język tak, by był zgodny z XMLem. Wynikiem jest język który może być (i powinien) parsowany jako XML.

Zatem wszystko jest dobrze? Nie. Gdy rozejrzeć się dookoła można zauważyć, że cholernie ciężko jest uzyskać aby XHTML parsował się przy użyciu tego samego parsera co XML w aktualnych przeglądarkach. Pozwólcie, że to wytłumaczę: aby zadecydować, którego parsera użyć, trzeba wysłać poprawy typ MIME ze swojego serwera. Jeżeli korzysta się z PHP można to zrobić tak:

<?php
if ( stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml") ) {
   header("Content-type: application/xhtml+xml");
}
else {
   header("Content-type: text/html");
}
?>

Ten krótki skrypt pyta przeglądarkę, czy poradzi sobie z XMLem i jeśli tak, to wysyła XMLowy typ MIME “application/xhtml+xml”. Jeśli przeglądarka nie poradzi sobie (Internet Explorer 6 i 7 nie dają rady) to wysyłany jest typ MIME “text/html” (gdzie błędy są tolerowane i poprawiane).

Ale to nie jedyna zmiana jakiej potrzebujemy. Pod koniec roku 2004 Ian Hixie napisał Sending XHTML as text/html Considered Harmful (uwaga: techniczne :D). Wczytując się w ten tekst można zobaczyć, że trzeba zmienić dużo więcej niż tylko typ MIME, jeśli chce się, żeby XHTML pracował zgodnie z zamierzeniem. Krótko rzecz biorąc: zrobienie tego poprawnie jest trudne.

Problem z używaniem XML w sieci

XHTML trudno jest parsować w sposób zgodny z zamierzonym w aktualnych przeglądarkach. Zamiast tego ludzie używający go decydują się (albo nie wiedzą że można inaczej) na parsowanie go tak, jakby był to HTML. Ale czyż nie pozbawia nas to największego powodu do używania XHTMLa? Jedyna różnica pomiędzy HTML 4.01 a XHTML jest taka, że XHTML może być parsowany jak XML! Tak długo jak będziesz parsować swój kod jak HTML nie ma powodu, żeby używać XHTML.

Jeżeli spojrzymy na specyfikację XHTMLa jest tam mała tabelka przedstawiająca które wersje XHTMLa powinny być wysyłane z jakim typem MIME. Widać tam, że można wysyłać XHTML 1.0 jako „text/xhtml” (MAY - czyli MOŻNA). Ale patrząc dalej do późniejszych wersji widać, że NIE POWINNY (”SHOULD NOT” - zaznaczone na czerwono) być one wysyłane jako „text/html”. Tak więc już wkrótce parsowanie XHTMLa jako HTML nie będzie dozwolone jeśli chce się podążać za standardami. Pozostaje parsowanie go (XHTMLa) jako XML.

Wyobraźmy sobie jakąś dynamiczną stronę która pozwala jej użytkownikom na dodawanie treści. Dobrym przykładem są komentarze tej strony. Jeśli ja używam XHTMLa (i parsuje go poprawnie) i ktoś użyje niewłaściwego kodu w komentarzu strona powinna przestać działać. Kolejny użytkownik wchodząc na stronę otrzyma brzydki komunikat błędu z numerem linii i jakimś kodem. Totalnie nie do zaakceptowania. Zatem powinienem znaleźć sposób na parsowanie HTML w moich komentarzach i naprawić błędy, które mogą zepsuć stronę. Ok.

Następnie kopiuje-wklejam (copy-paste) jakiś tekst ze strony i chcę go wam zacytować. Kiedy publikuję artykuł otrzymuję obrzydliwy komunikat błędu, ponieważ strona, z której wkleiłem tekst używa innego kodowania znaków i to „rozwala” mój XHTML. Po zbadaniu problemu okazuje się, że można to naprawić parsując cały tekst z panelu administratora i upewnić się że jest on poprawnie zakodowany w UTF-8 zanim zostanie zapisany w bazie danych. Ok.

Następnie ściągam trochę JavaScriptu i próbuję użyć go na stronie. Ponownie ludzie otrzymują okropny komunikat błędu prosto w twarz w momencie wejścia na stronę. Wydaje się, że JavaScript obsługiwany jest bardziej ściśle w XHTMLu i wymaga to używania takich dziwnych znaczków CDATA na początku i końcu skryptu. Ok, to też naprawiłem.

I tak kontynuując, małe błędy w kodzie sprawiają, że strona co chwila się „wywala”; również błędy w parserach którzy pozwalają ludziom na psucie mojej strony poprzez komentarze. Mam wykształcenie informatyczne, więc prawdopodobnie mógłbym naprawić błędy i ciągle łatać stronę dopóki wszystko nie będzie działać. Ale czy tego chcę? Co złego jest w obecnych metodach naprawy błędów, które zauważam w trakcie walidacji? A co z wszystkimi nieprogramistami?

Nie możemy oczekiwać by początkujący używali XHTML

Jak przeczytaliście powyżej, cholernie ciężko jest uzyskać poprawny XHTML. Jednak W3C przepycha XHTML jako nowy standard sieciowy. Pomimo tego, że ciężko będzię początkującym uzyskać stan poprawny. Pomimo tego, że trzeba bedzie przenieść obsługę błędów na każdą ze stron, zamiast na przeglądarki. Pomimo tego, że XHTML nie ma prawie żadnej kompatybilności wstecz, więc niemalże wszystkie strony w sieci będą musiały zaktualizować swój kod.

Nie, nie będę parsował wszystkiego jako XML na stronach, które tworzę. XHTML był od początku złym pomysłem i prędzej skłaniałbym się do rozwoju nowej wersji HTML pod nazwą Web Applications 1.0 (znanym też jako HTML 5).

Mam nadzieję, że ten artykuł wyjaśnia, dlaczego tak wiele blogów webdeveloperskich używa HTML (wliczając Friendly Bit). Którego języka używacie?

Czerp radość z dzielenia się: These icons link to social bookmarking sites where readers can share and discover new web pages.

16 komentarzy to “Dlaczego XHTML to zły pomysł”

Sybskrypcja RSS dla wpisu Trackback

1 Krzysiek S. 7 listopada 2006 o godzinie 20:33

Nie rób z XHTML-a szatana ;-)

Prawdą jest, że XHTML w użyciu jest nieco kłopotliwy, ale rzeczywisty problem jest z pewną częścią społeczeństwa, która zastygła w „rozwoju” kilka lat temu. To nie XHTML jest złym pomysłem, to ludzie po prostu jeszcze do niego nie dorośli…
2 pl 7 listopada 2006 o godzinie 21:34

Krzysztofie! Ależ nie robię szatana z XHTMLa :D Nie muszę :D Sam już jest szatanem :D Po za tym artykuł nie jest mój, tylko jak pisałem na końcu Emila Stenströma

Problem z XHTML wynika nie tylko dlatego, że ludzie do niego nie dorośli. Nie dorosły do niego przede wszystkim przeglądarki (chodzi tu głównie o IE), które nie potrafią poprawnie go (XHTMLa) parsować.

Problemem jest nie tylko to, że branża jak to powiedziałeś „zastygła” - nie dorośliśmy nie tylko do XHTMLa, ale nawet do HTMLa - wystarczy spojrzeć jak wiele jeszcze stron posiada błędy semantyczne, ramki, tabelki do layoutu… Czy do tego został stworzony HTML? Nie sądze…
3 Piotrek 8 listopada 2006 o godzinie 2:42

Bardzo dobry tekst :). Wizja stron wykonanych w XHTML w obecnym stadium rozwoju przeglądarek jak i wiedzy twórców stron nie ma racji bytu. Nie twierdze że XHTML jest zły, problem leży tu raczej po stronie webkoderów i zbyt dużej czułości parserów na błędy. Osobiście tworze strony i wykorzystuje HTML 4, ale jednocześnie dla jednej z tych stron zmuszony byłem stworzyć własny parser XML’a. Po co ? ano tylko po to by był on idiotoodporny.

Mi jako twórcy nie zależy na tym żeby parsowany XML pokazywał błędy, XML (mam na myśli np źródła RSS) tworzą ludzie i to oni najcześciej zawodzą, w trakcie testów parsera przetestowałem około 1000 feedów napotykając co chwile na jakieś kwiatki, niezgodne ze specyfikacjami (można by o tym pisać godzinami).

W dzisiejszych czasach zalewa nas tak duża ilość informacji, że niemożliwością jest żeby choćby najlepszy i najszybszy admin jakiegoś tam portalu przetestowował każdą z nich w każdym miejscu do jakiego dociera.

Podsumowując XHTML, XML - TAK, ale na początku z mechanizmami idiotoodpornymi tak jak jest to w przypadku parserów HTML, + ewentualna możliwość włączenia raportowania błedów na żądanie. W innym wypadku bedzie to specyfikacja świetna i martwa. Wyłączenie raportowania błędów na pewno przyczyniło by się do popularyzacji XHTML’a, a umiejetności programistów z czasem osiągnęły by akceptowalny poziom.

Pozdrawiam Piotr Jóźwiak
4 Michał Stempień 10 listopada 2006 o godzinie 18:01

A tu druga strona medalu:
http://h3h.net/2005/12/xhtml-harmful-to-feelings/
5 pl 10 listopada 2006 o godzinie 19:40

@Michał Stępien: Ciekawy artykuł, wczytam się w niego dokładnie jak znajdę więcej czasu…

A tak przy okazji Michale widzę, że zmieniłeś swoją stronę :D Ciekawy, ascetyczny design…
6 Michał Stempień 10 listopada 2006 o godzinie 23:30

Szewc bez butów chodzi… i nazywam się Stempień, Michał Stempień :>
7 pl 10 listopada 2006 o godzinie 23:46

Co fakt, to fakt.. ja ze swoją stroną „bujam” się już chyba drugi rok :D

Co do nazwiska to przepraszam, bez okularów dzisiaj coś słabo widzę :D
8 pl 10 listopada 2006 o godzinie 23:49

A tak przy okazji, Michale: znasz jeszcze jakieś ciekawe strony z artykułami na temat (x)htmla?
9 ffreak 17 listopada 2006 o godzinie 18:19

Aż mnie skręcało w żołądku, że nie natrafiłem wcześniej na tą notkę :)

„Ale czyż nie pozbawia nas to największego powodu do używania XHTMLa?”
Nie.

„Jedyna różnica pomiędzy HTML 4.01 a XHTML jest taka, że XHTML może być parsowany jak XML!”
Bzdura!

XHTML od HTML różni się przede wszystkim X-em. Ten X to skrót od ‚eXtensible’. To ‚eXtensible’ sprowadza się do dodania atrybutu ‚xmlns’ w XHTML 1.0 i modularyzacji XHTML (w kolejnych wersjach/wariantach). To ‚xmlns’ oraz modularyzjacja to ogromna różnica w stosunku do HTML (i bynajmniej nie zanika ona jeśli parsujemy dokument jako HTML - to w niczym nie przeszkadza).

Ten ‚X’ pozwala nam tworzyć XHTML Host Lanuages (XHTML Basic, XHTML Print, nasze wlasne..), dodawać atrybuty których potrzebujemy (np. a aplikacjach), wplatać w kod XHTML zupełnie niezwiązane z nim języki, no i „last but not last” - pozwala(ł by) nam budować Sieć Semantyczną.

Parsowanie jako HTML to wręcz pomijalna w obecnych czasach zaleta.

XHTML2 to marzenie - naprawia prawie wszystko to, co tak drażni i nie pozwala pisać naprawdę logicznego kodu HTML.

To nieuzasadnione niczym poza ekonomią zachowawcze zachowanie Microsoftu w największym stopniu hamuje rozwój sieci.

„Wiele osób wierzy, że jest on przyszłością sieci. Jestem innego zdania i ten artykuł wyjaśnia moje rozumowanie.”

XHTML __JEST__ przyszłością sieci - nie można mieć innego zdania mając dobre wyobrażenie o tym czym XHTML jest i jakie możliwości daje.

Jak ktoś ma problem z napisaniem poprawnego syntaktycznie kodu XHTML, to powinien się zająć składaniem długopisów.
10 pl 18 listopada 2006 o godzinie 8:54

ffreak:
- primo: zanim zaczniesz toczyć pianę z ust przeczytaj jeszcze raz tekst w czerwonej ramce pod koniec niniejszego artykułu… Tak, to jest tłumaczenie artykułu… Artykułu, który niekoniecznie musi przedstawiać moje zdanie…
- secundo: zwróć uwagę jak często XHTML jest używany jako XML? większość firm/osób w „branży” używa go jedynie w celach marketingowych wstawiając button „XHTML VALID” na swoją stronę (chociaż często kod nie jest walidowalny) jedynie w celu przyciągnięcia klienta - robi się powoli hype jak na web2.0…
- tertio: o tym czym tak naprawdę jest XHTML i jak powinno się go używać wie naprawdę niewielki procent ludzi którym wydaje się że używają poprawnego XHTMLa… No właśnie - wydaje im się… W sieci istnieje tak wiele stron, które nie spełniają nawet wymogów specyfikacji HTML 4 - a co dopiero mówić o XHTMLu!
- quarto: generalnie jestem za dążeniem do standardów (nowych czy tych starszych - whatever) i podobnie jak Ty uważam, że XHTML __JEST__ przyszłością sieci - aczkolwiek nie jestem pewien czy webdeveloperzy dorośli już do tej przyszłości… Patrząc na strony w polskim (i nie tylko) internecie wychodzi mi, że ponad 90% branży powinno składać długopisy :D
11 ffreak 18 listopada 2006 o godzinie 11:28

Piotrze,

fragment o składaniu długopisów (to w tym momencie „toczę pianę”?) w najmniejszym stopniu nie miał dotyczyć Ciebie - chodziło o ludzi, którzy mają problem z napisaniem validującego się dokumentu.
Poza tym uważam, że kolejną bzdurą jest stwierdzenie, że ludzie by sobie nie poradzili… składnia XML-a jest banalna, validator opart na XML Schema (bo raczej nie DTD) mógłby wskazywać błędy bardzo precyzyjnie łącznie z podpowiadaniem jak powinno być dobrze - każdy byłby w stanie napisać validujący się dokument - z pewnością nawet moja mama. Problem mogliby mieć dopiero np. z JavaScriptem.
Hmm.. i chyba dochodzę do wnoisku, że to w sporej części wina W3C, że tak to nie wygląda…

Moje wykrzykniki z początku to zabieg stylistyczny.. im większa bzdura padała w tym artykule tym mocniej ją autor akcentował - tym mocniej akcentowałem swą ripostę ja.

Jeśli to nie Twój artykuł, to tym bardziej nie powinieneś brać tego do siebie :)

Ad. tercio: No c’mon… ludzie, którzy wiedzą jak używać nie wiedzą jak go tak naprawdę używać? ;)

Ad. quarto: faktycznie ta technoogia wciaż wygląda na młodą… niby wszystkie narzędzia są, ale powinny być lepsze, czyt. łatwiejsze, podobnie materiały szkoleniowe itd..

Podsumowując: może i konkluzja artykułu jest w jakiś sposób prawdziwa (nie licząc tych (imo) bzdurnych stwierdzeń z początku), ale artykuł daje złe wyobrażenie o tej technologii, błędne, jest naciągany… to szkodliwe, bo teraz ludzie zaczną się tego bać, a naprawdę nie ma czego…

Dobry XHTML 1.0 to poprostu validujący się dokument, w tej wersji XHTML-a można sobie odpuścić application/xhtml+xml (może i tak nie miało być, ale na tym obecnie staneło). Większość ludzi i tak nie będzie potrzebowało rozszerzać tego języka, więc niech poprostu piszą validujące się dokumenty - to na początek wystarczy.

Hmm.. trzebaby się zabrać za promocję tego języka jakoć mocniej :)

// A zacząć by od siebie…
12 pl 18 listopada 2006 o godzinie 12:03

ffreak: Wiem, że to nie do mnie :D Tłumaczenia tego artykułu dokonałem nie w celu przestraszenia, ale raczej w celu ostrzeżenia ludzi… Trzeba pokazywać nie tylko zalety ale i wady… Bo przecież wady, też są… Większość z nich wynika niestety z tego, że parsery przeglądarek nie potrafią dobrze go obsłużyć (w wersji „application/xhtml+xml”), nie posiadają dobrej obsługi błędów. XHTML to tak jak pisałeś przede wszystkim modularyzacja, a nie jak sądzi większość domorosłych „łepmasterów” kilka poprawnie wstawionych elementów i użycie buttona „VALID XHTML”… XHTML ma dużo większe możliwość niż jego starszy „brat” HTML… XHTML sam moim skromnym zdaniem o niebo lebszym standardem niż HTML - technologia sama w sobie jest dobra - to ludzie z niej korzystający robią to źle…
Jeżeli chodzi o tertio: chciałem napisać że większości WYDAJE się, że używają XHTML poprawnie ale się zamotałem :D

Jeżeli chodzi o probemy z XHTML to masz rację - dużo odpowiedzialność ponosi za to W3C - ale niemała w tym rola webdesignerów - zwłaszcza dużych agencji, firm, korporacji, które rzucają się na każdą nowość tylko po to, żeby wyciągnąć z tego kasę - podobnie jest z web2.0 i AJAXem i tak pewnie będzie z XHTML 2… Wciskaniu ludziom na siłę czegoś o czym ludzie nie mają pojęcia to kiepska droga do promowania standardów… A promować je trzeba - bo jak już wspomniałeś: przyszłość należy do XHTMLa… Czy tego chcemy czy nie :D Z tym tylko, że do promowania XHTMLa przydałyby się przykłady - a tych dobrych to ze świeczką szukać :D
13 void __fastcall nick(); 8 sierpnia 2007 o godzinie 14:42

nie zgadzam się z tym, że jest trudno tworzyć porawny xhtml - pomimo, że jestem programistą, czy teoretycznie mam pojęcie o tym co robię, to wcale nie uważam tego za jakieś szczegółne osiągnięcie - w3c validator dokładnie pokazuje błędy i można j bardzo szybko poprawić.
14 porneL 28 sierpnia 2007 o godzinie 22:35

Mała uwaga: modularyzacja XHTML nie opiera się o XML i przestrzenie nazw, tylko o DOCTYPE. Można by wziąć DOCTYPE od dowolnie zmiksowanej wersji XHTML, poprawić pare kosmetycznych różnic składniowych i użyć w HTML/SGML z takim samym rezultatem…
…czyli żadnym, bo przeglądarki są zmuszone traktować XHTML jako dokumenty XML standalone (biorąc encje z wewnętrznej biblioteki):
http://hsivonen.iki.fi/no-dtd/
15 porneL 28 sierpnia 2007 o godzinie 22:45

@void __fastcall nick():
Właśnie w tym problem, że Validator W3C nie sprawdza niczego pożytecznego w XHTML. XHTML, który przejdzie przez Validator może nadal być kompletnie uzależniony od interpretacji jako HTMLowa tagzupa.
Validator [X]HTML ma swoje ograniczenia wynikające z uwiązania do leciwego DTD, nie sprawdza Content-Type, nie ostrzega przed złym umieszczeniem stylów/skryptów, ani nie tknie kodu używającego DOM, a to w trybie XML łatwo zepsuć. Validator CSS też ci nie powie, kiedy twój arkusz jest niekompatybiny z trybem XML, a jeśli nie konfigurowałeś specjalnie serwera pod to, to pewnie trybu XML nawet nigdy nie widziałeś.

Pułapki wymieniam na: http://pornel.net/xhtml

BTW: void przy funkcji nick() jest mało przydatny :P

blog lepszy Internet