Pisa­łem o tym już nie­zli­czoną liczbę razy, także na tym blogu, ale widać, że nie­któ­rzy zako­chali się w XHTML do tego stop­nia, że są głusi na jakie­kol­wiek uwagi. Jak z każdą miło­ścią, pro­blem z zealo­tami XHTML polega na cał­ko­wi­tym zaśle­pie­niu uczu­ciem i miło­wa­niu nie fak­tycz­nego stan­dardu, a swo­jego o nim pojęcia.

Nie kry­ty­kuję XHTML, to bar­dzo dobry stan­dard, który porząd­kuje zupę tagów, jaką pozo­sta­wił po sobie HTML — który też jest bar­dzo dobrym for­ma­tem, tylko pozwala na zbyt dużą dowol­ność. Co wię­cej, jest tak dobry, że każdą dzia­ła­jącą dziś stronę, zbu­do­waną w XHTML, można bez więk­szych prze­szkód prze­ro­bić na HTML. Oczy­wi­ście, XHTML jest stan­dar­dem przy­szło­ści i ofe­ruje wiele roz­sze­rzeń, któ­rymi od lat szczycą się inne apli­ka­cje XML (a XHTML to rodzina takich wła­śnie aplikacji).

Pro­blem polega na tym, że żadna z nowych funk­cji nie jest wspie­rana przez więk­szość rynku. Jeśli uwa­żasz, że dopi­su­jąc do ele­men­tów swo­jego doku­mentu atry­but xml:lang="pl", zwięk­szysz dostęp­ność ser­wisu, to jesteś w błę­dzie. Prze­strze­nie nazw to spe­cy­fika apli­ka­cji XML i prze­glą­darki trak­tu­jące doku­ment jak text/html nie­wiele sobie z nich robią.

Oczy­wi­ście, takich pro­ble­mów jest wię­cej, ale naj­więk­szy z nich doty­czy tego, co jest jed­no­cze­śnie naj­więk­szą zaletą XHTML — ścisłe spraw­dza­nie popraw­no­ści doku­mentu. Pozwala na napi­sa­nie par­sera dla doku­men­tów dzie­siątki razy prost­szego i mniej skom­pli­ko­wa­nego niż dla doku­men­tów two­rzo­nych w HTML, pozwala też na edy­cję doku­mentu za pomocą dowol­nego wła­ści­wie narzę­dzia, jeśli to radzi sobie z doku­men­tami XML. Dwie wiel­kie zalety, ale zalety dla cie­bie i auto­rów prze­glą­da­rek. Klient i inter­nauta nie mają z tego abso­lut­nie nic. Zasta­nów się, jakie korzy­ści przy­nie­sie sto­so­wa­nie XHTML w danym, kon­kret­nym przy­padku.

Dla­czego? Ano dla­tego, że dla klienta waż­niej­sze są pie­nią­dze i zado­wo­le­nie inter­nau­tów (ze wska­za­niem na ich pie­nią­dze). Jeśli nagle okaże się, że musisz wspie­rać użyt­kow­ni­ków sta­rych wer­sji Safari, to sta­niesz przed pro­ble­mem — wali­da­cja albo obsługa (albo brzyd­kie hacki z uży­ciem Java­Script do osa­dza­nia mediów z uży­ciem dyna­micz­nie gene­ro­wa­nego obiektu <embed/>).

Dla­tego, że klient może kie­dyś zechcieć zmo­dy­fi­ko­wać swój ser­wis. Ile z pol­skich ser­wi­sów ofe­ru­ją­cych choćby sta­ty­styki jest w sta­nie wyge­ne­ro­wać kod zgodny z XHTML? Jeśli uży­łeś XHTML w wer­sji 1.1, to wła­śnie zro­bi­łeś klien­towi niedź­wie­dzią przy­sługę — patrząc na wyniki pod­łą­cze­nia licz­nika jest od dzie­się­ciu minut prze­ko­nany, że stan­dardy sie­ciowe dzia­łają tylko w IE, bo wszyst­kie inne prze­glą­darki koń­czą żywot na tajem­ni­czym żółtym ekra­nie z komu­ni­ka­tem o błę­dzie. Kiedy czy­tasz to zda­nie, on pew­nie wła­śnie kal­ku­luje straty, jakie przy­nio­sło to jego działalności.

Nie zro­zum mnie źle, XHTML nie należy uni­kać, ale pozo­sta­wie­nie klienta z takim kodem i bez wspar­cia wyrzą­dza sieci więk­sze straty niż korzy­ści. Jeśli chcesz sto­so­wać nowo­cze­sne tech­no­lo­gie, to upew­nij się, że wiesz o nich wszystko i zapew­nij wspar­cie swo­jej wie­dzy klien­towi. Gdyby była to broń, to chyba nie dał­byś jej dziecku z nadzieją, że wci­śnie wła­ściwy guzik?

Na koniec powiem tylko, że z coraz więk­szym zain­te­re­so­wa­niem przy­glą­dam się pra­com, toczą­cym się przy nie­ofi­cjal­nym pro­jek­cie HTML 5, nasta­wio­nym nie tylko na czy­telną skład­nię, ale na zapew­nie­nie — auto­rom opar­tych o sieć apli­ka­cji — nie­zbęd­nych obiek­tów do wygod­nego budo­wa­nia dyna­micz­nych ser­wi­sów. Spe­cy­fi­ka­cja (nie­ko­niecz­nie w ory­gi­nal­nej for­mie) ma być jesz­cze w tym roku dys­ku­to­wana na forum W3C, w ramach pro­jektu apli­ka­cji webowych.