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.
No cóż - jedna baza danych sprawdza się po raz kolejny. Sam osobiście, jak pewnie wiesz, jestem zauroczony kierunkiem, w jakim zmierza WHATWG. W3C za bardzo odchodzi od specyfiki Web’u. WHATWG oferuje to, co w Webie jest potrzebne.
Głos rozsądku. :)
Wydaje mi się, że wielu zwolenników XHTML popełnia dokładnie ten sam błąd co zwolennicy Flasha - próbują dostosować sytuację do technologii, a nie technologię do sytuacji.
A tak nawiasem mówiąc, HTML 4.01 jest nadal standardem i wcale się nie zdezaktualizował, W3C nie wymaga tworzenia wszystkich nowych dokumentów w XHTML. No chyba, że coś przeoczyłem, to proszę o poprawki.
Zgadzam sie z tym, ze nalezy uwazac, przy korzystaniu XHTML-a. Ale z drugiej strony jest to technologia przyszlosci i im wczesniej przestawimy sie na korzystanie z niej, tym lepiej dla sieci, prawda?
Co do HTML-a 5… coz, jesli dyskusja rozpocznie sie w tym roku, to skonczy sie za 2 lata, przez kolejne 2 lata specyfikacja bedzie poprawiana i moze za kolejne 2 lata beda to wspierac Firefoks i Opera ;)
1.
> 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.
Jak rozumiem ten fragment, chodzi w nim o to, że IE wyświetli stronę z błędnym kodem?
Pierwszy raz czytając ten tekst wydawało mi się, że wszystkie inne przeglądarki nie obsługują XHTML 1.1 ;)
2. O JavaScripcie nic nie wiem, ale wiem o generowaniu kodu strony po stronie serwera (np. którzy klienci obsługują application/xhtml+xml :) )
3. Nie przeganiam bynajmniej klientów starych przegladarek, ale kłopot wydaje mi się jest wprost odwrotnu. Strony są tworzone w stadardzie HTML-IE ;)
4.
> Co do HTML-a 5… coz, jesli dyskusja rozpocznie sie w tym roku, to skonczy
> sie za 2 lata, przez kolejne 2 lata specyfikacja bedzie poprawiana i moze
> za kolejne 2 lata beda to wspierac Firefoks i Opera ;)
Jestem większym optymistą, jeżeli chodzi o wspieranie w FF i Operze…
Trochę bardziej jestem sceptyczny co do HTML 5 - zapewnie nie będzie wspierany przez IE, a nie będzie miało otoczki ‘nowości’.
Pozdrawiam
Ładnych parę lat temu, jak poznawałem HTML-a, nie mogłem się nadziwić, że muszę pisać “głupi kod”, żeby ta sama strona wyglądała podobnie w różnych przeglądarkach, np. w dla jednej trzeba zapisać marginwidth=”0″, dla drugiej marginleft=”0″ - żeby nie mieć bocznych marginesów. Takich dziwnych przypadków jest cała masa. Pomyślałem wtedy - pewnie za parę lat to wszystko się wyjaśni, jeden standard będą szanować wszystkie przeglądarki i będzie łatwiej pisać kod.
Ładnych parę miesięcy temu z kolei zauważyłem, że panuje moda właśnie na XHTML z dodatkiem CSS, bez używania tabel. Kupiłem książkę, siadłem do komputera i zacząłem tworzyć stronę. Skoro style miały wszystko ułatwić, to fajnie. Niestety zrezygnowałem po paru godzinach, kiedy okazało się, że znowu trzeba stosować masę trików i sztuczek, żeby wymusić takie same reakcje przeglądarek. Nie jestem programistą, ale uważam, że kod musi być logiczny, wtedy łatwo się go uczy, używa i tworzy.
Zastanowiłem się po co to robię? Skusiłem się, że strony w samym CSS będą dużo lżejsze, ładnie czytane przez przeglądarki i będzie się to ładnie pisać. Dodatkowo pomyślałem coś w stylu “tak się teraz robi”, “taka jest moda”, “fajnie mieć na stronie ikonki zgodności…”, etc. Stwiedziłem, że nie ma sensu stosować czegoś na siłę, albo technologię, której się nie rozumie. W końcu serwis zrobiłem w HTML 4.01 i właściwie jedynym moim problemem jest po tym to, jak ta sama linia kropkowana może różnie wyglądać w wielu przeglądarkach… :)
html w chwili obecnej jest tym samym co html.
Sam przesiadlem sie na xhtml, ale przeciez nie ma roznicyDopieo layouty beztabelkowe wywolaly lawine problemow. Rowniez kilka razy wszystko wpuszczalem w smietnik, ale bylem uparty - i teaz juz wiem ze zrobie strone zgodna ze standardami, ladnie wyswietlajaca sie w kazdej przegladarce - lacznei z lynxem, strone ktora wlasciwie przeczytaja czytniki dla niewidomych. Nie trzeba stosowac jakichs strasznych hackow - sa w zasadzie 3 rzeczy, o ktorych ystarczy pamietac i nie stanowia zadnej trudnosci (box model i relacja z quirks mode, czcionki i em, max/min height/width i IE).
Srone nalezy robnic wg standardow i pod IE - wystarczy, aby wsedzie dzialalo prwidlowo. Kazda strone zrobie szybciej niz mialbym ja robic w tabelkach. Co wiecej, nie jest wazne, czy uzywam html czy xhtml - niezaleznie od specyfikacji mozna wykonac strone semantycznie poprawna, a to wlasnie jest najwazniejsze w tworzeniu stron…
Piszesz, ze klienta nie obchodzi co jest w kodzie. Wielokrotnie zagniezdzone tabelki tworza sieczke w czytnikach glosowych dla niewidomych. dodatkowo, css umozliwia latwa modyfikacje calego serwisu (www.csszengarden.com). pieniadze to czas, a czas na wykonanie strony w css jest znacznie mniejszy. Transfer to pieniadze - a strony css zuzywaja znacznie mniej zasobow i generuja mniej odwolan do serwera. A xhtml to dobry sposob na trzymanie poradku w kodzie i to wszystko… pomijajac mozliwosci parsowania.
warto sie uprzec i poznac mozliwoci jakie daje css, oraz korzystac z xhtml w celu oczyszcenia swojego kodu. To sie przyda:)
Pozdrawiam
A gdzie ja, na litość boską, napisałem, że strona ma być zrobiona na tabelkach?