Pisałem o tym już niezliczoną liczbę razy, także na tym blogu, ale widać, że niektórzy zakochali się w XHTML do tego stopnia, że są głusi na jakiekolwiek uwagi. Jak z każdą miłością, problem z zealotami XHTML polega na całkowitym zaślepieniu uczuciem i miłowaniu nie faktycznego standardu, a swojego o nim pojęcia.
Nie krytykuję XHTML, to bardzo dobry standard, który porządkuje zupę tagów, jaką pozostawił po sobie HTML - który też jest bardzo dobrym formatem, tylko pozwala na zbyt dużą dowolność. Co więcej, jest tak dobry, że każdą działającą dziś stronę, zbudowaną w XHTML, można bez większych przeszkód przerobić na HTML. Oczywiście, XHTML jest standardem przyszłości i oferuje wiele rozszerzeń, którymi od lat szczycą się inne aplikacje XML (a XHTML to rodzina takich właśnie aplikacji).
Problem polega na tym, że żadna z nowych funkcji nie jest wspierana przez większość rynku. Jeśli uważasz, że dopisując do elementów swojego dokumentu atrybut xml:lang="pl", zwiększysz dostępność serwisu, to jesteś w błędzie. Przestrzenie nazw to specyfika aplikacji XML i przeglądarki traktujące dokument jak text/html niewiele sobie z nich robią.
Oczywiście, takich problemów jest więcej, ale największy z nich dotyczy tego, co jest jednocześnie największą zaletą XHTML - ścisłe sprawdzanie poprawności dokumentu. Pozwala na napisanie parsera dla dokumentów dziesiątki razy prostszego i mniej skomplikowanego niż dla dokumentów tworzonych w HTML, pozwala też na edycję dokumentu za pomocą dowolnego właściwie narzędzia, jeśli to radzi sobie z dokumentami XML. Dwie wielkie zalety, ale zalety dla ciebie i autorów przeglądarek. Klient i internauta nie mają z tego absolutnie nic. Zastanów się, jakie korzyści przyniesie stosowanie XHTML w danym, konkretnym przypadku.
Dlaczego? Ano dlatego, że dla klienta ważniejsze są pieniądze i zadowolenie internautów (ze wskazaniem na ich pieniądze). Jeśli nagle okaże się, że musisz wspierać użytkowników starych wersji Safari, to staniesz przed problemem - walidacja albo obsługa (albo brzydkie hacki z użyciem JavaScript do osadzania mediów z użyciem dynamicznie generowanego obiektu <embed/>).
Dlatego, że klient może kiedyś zechcieć zmodyfikować swój serwis. Ile z polskich serwisów oferujących choćby statystyki jest w stanie wygenerować kod zgodny z XHTML? Jeśli użyłeś XHTML w wersji 1.1, to właśnie zrobiłeś klientowi niedźwiedzią przysługę - patrząc na wyniki podłączenia licznika jest od dziesięciu minut przekonany, że standardy sieciowe
działają tylko w IE, bo wszystkie inne przeglądarki kończą żywot na tajemniczym żółtym ekranie z komunikatem o błędzie. Kiedy czytasz to zdanie, on pewnie właśnie kalkuluje straty, jakie przyniosło to jego działalności.
Nie zrozum mnie źle, XHTML nie należy unikać, ale pozostawienie klienta z takim kodem i bez wsparcia wyrządza sieci większe straty niż korzyści. Jeśli chcesz stosować nowoczesne technologie, to upewnij się, że wiesz o nich wszystko i zapewnij wsparcie swojej wiedzy klientowi. 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ększym zainteresowaniem przyglądam się pracom, toczącym się przy nieoficjalnym projekcie HTML 5, nastawionym nie tylko na czytelną składnię, ale na zapewnienie - autorom opartych o sieć aplikacji - niezbędnych obiektów do wygodnego budowania dynamicznych serwisów. Specyfikacja (niekoniecznie w oryginalnej formie) ma być jeszcze w tym roku dyskutowana na forum W3C, w ramach projektu aplikacji webowych.