Uważaj na XHTML
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.
15 grudnia 2005 o 21:08:29
Ja wolałbym XSLT używać, ale to ma jeszcze mniej przeglądarek.
15 grudnia 2005 o 21:11:17
XSLT się używa po stronie serwera, a nie przeglądarki.
15 grudnia 2005 o 21:12:52
hm, pierwsze słyszę... Może XSL, dalej nie wiem, czym one oba sie różnia ;)
15 grudnia 2005 o 21:14:50
Nie, to właśnie XSL jest po stronie agenta i służy do definiowania wyglądu aplikacji XML. XSLT służy do przetwarzania jednej aplikacji w drugą, np. dokumentu OASIS na stronę XHTML.
15 grudnia 2005 o 21:18:04
Właśnie o to mi chodziło ;) Jednak chyba oba są po stronie agenta, ja używałem tego do szablonów, musiałem rezygnować, bo Opera nie umiała sobie poradzić i tekst wyświetlała.
15 grudnia 2005 o 21:23:58
W HTML 5 chciałbym zobaczyć np. vbox/hbox (podobne do tego w XUL-u). Pewnie mogę sobie pomarzyć :)
15 grudnia 2005 o 21:26:18
Właśnie przez XSLT można transformować stronę po stronie serwera. Patrys i mnie oświecił na ten temat jakiś czas temu (przy okazji jakiegoś wpisu Enletha, gdzie powiedział, ze wysyłanie komuś XML i XSL to tak jakby wysłać komuś PHP i powiedzieć "wygeneruj sobie HTML samodzielnie"), choć jeszcze tego w praktyce nie stosowałem (zresztą nwet nie wiem czy i jakie w PHP są funkcje do realizacji tego).
15 grudnia 2005 o 21:27:23
Wikipedia twierdzi, że XSLT jest częścią XSL, odpowiadająca za transformacje dokumentów XML'owych na inne formaty.
15 grudnia 2005 o 21:31:27
XSL vs XSLT:
http://java.sun.com/webservices/jaxp/dist/1.1/docs/tutorial/xslt/1_intro.html
@Patrys:
Fajny tekst. btw, jakoś mi nieswojo, jak nazywasz plik XML aplikacją ;)
15 grudnia 2005 o 21:32:27
Ta, można, jednak można też wygenerować po stronie przegladarki.
Po stronie serwera z PHP:
$xslt = xslt_create();
$result = $xslt_process($xslt, 'xml.xml', 'arkusz.xsl');
echo $result;
15 grudnia 2005 o 21:40:20
XSLT po stronie przeglądarki przydaje się jak chcesz np. wysłać komuś jakieś dane w XML-u, ale na wypadek, jakby ktoś użył przeglądarki, to żeby sobie przetransformowała do HTML. Jak w Subversion ;-)
Przydałaby się możliwość dodawania kilku nagłówków <?xml-stylesheet ?> z informacją, *do* jakiego typu transformuje dana transformacja, żeby sobie przeglądarka wybrała. Może już tak jest?
15 grudnia 2005 o 21:44:31
Jak zwał tak zwał, ważne jest, że większość osób dość dziwnie reaguje po przejrzeniu źródła takiej stronki ;)
16 grudnia 2005 o 16:34:35
> "standardy sieciowe" działają tylko w IE, bo wszystkie inne przeglądarki kończą żywot na tajemniczym żółtym ekranie z komunikatem o błędzie.
*Bardzo nie lubie* gdy ludzie ograniczają scenę przeglądarek do IE i Gecko.
1. Konqueror też wyświetli stronę mimo że ta ma błąd w kodzie
2. Opera wyświetli biały komunikat o błędzie. Wszystkie inne phi, świat nie kończy się na FF, zapamiętajcie to raz na zawsze.
16 grudnia 2005 o 18:36:40
Na małe ego są chyba jakieś tabletki. Konqueror i Opera to nie są mainstreamowe przeglądarki, a wpis nie jest o przeglądarkach.
16 grudnia 2005 o 18:40:22
W takim razie pewnie mam jakieś problemy z rozumieniem tekstu czytanego jeśli nie rozumiem wyrazów "wszystkie inne przeglądarki"
16 grudnia 2005 o 22:43:27
Flash jest niezgodny z duchem XHTML, więc jeśli ktoś chce z niego korzystać, to raczej nie będzie mu zależało na tym, aby strona była napisana w XML. Argument o wstawianiu <embed> dla starszych przeglądarek jest więc średnio trafiony.
17 grudnia 2005 o 13:38:08
Opera ma taką właściwość, że często potrafi wyświetlić część kodu aż do wystąpienia błędu, potem daje czarną linię i info o błędzie.
17 grudnia 2005 o 13:41:20
Oj, źle się wyraziłem, miało być ,,wyrenderować część kodu'' :-)
17 grudnia 2005 o 19:39:36
Nerf:
A odkąd Flash jest niezgodny z XHTML? To zwykły element <object/>.
17 grudnia 2005 o 19:42:19
Technicznie on może być zgodny, ale jeśli ktoś korzysta z tego zamkniętego formatu, to raczej nie będzie mu zależało na dostępności i przenośności strony, a tym samym nie będzie miał po co korzystać (na dzień dzisiejszy) z XHTML.
18 grudnia 2005 o 15:30:43
Nie bardzo rozumiem - Flash (jak każdy obiekt) się bardzo ładnie degraduje i można treść dostarczyć też w wersji tekstowej.
23 grudnia 2005 o 00:27:05
> "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."
Zupełnie nie :-). Oczywisie stosowanie xml:lang zwieksza diametralnie dostepnosc serwisu a przynajmniej pownno "trąbią" o tym wszystkie możliwe rekomendacje, notki i porady WAI.
> "przestrzenie nazw to specyfika aplikacji XML"
Tutaj wkradł się dosyć spory błąd. xml: nie ma nic wspólnego z przestrzenią nazw. xml:lang to predefiniowany atrybut, ktory nie jest w obrzarze zadnej z przestrzeni nazw, bo jest tylko well-formed a nie valid. Tak na marginesie to wtedy gdy to było wymyślane to nawet xmlns nie istniało. Rozumiem, że to przekłamanie wynika z lektury WHATWG, tam faktycznie taką bzdurę sugerują ale to nieprawda (jak zreszta wiekszość rzeczy w tych "specyfikacjach"). Wystarczy otworzyc specyfikacje dowolnej wersji XML-a i zobaczyc czym jest predefiniowany atrybut.
>"przeglądarki traktujące dokument jak text/html niewiele sobie z nich robią."
To prawda, co nie znaczy, że robią to zgodnie ze standardami.
>"Specyfikacja (niekoniecznie w oryginalnej formie) ma być jeszcze w tym roku dyskutowana na forum W3C, w ramach projektu aplikacji webowych."
Nie pierwszy i nie ostatni :-) Kilka razy już była odrzucana i teraz też bedzie. Jak zwykle trochę się pośmiejemy i wszystko wróci do stanu poprzedniego :-).
28 grudnia 2005 o 22:43:58
Nie rozumiem... Moim zdaniem to jest po prostu zestaw licencjonowanych bredni...
wirtualna polska, mylog.pl, ownlog.pl - strony z flashem, XHTML, javascript i (w większości) ze znaczkiem XHTML 1.1 VALID...
Co do obsługi XHTML przez przeglądarki... Praktycznie każda licząca się (FF, Opera, NAWET badzIEw) a NAWET konqueror poprawnie i bez krzyków renderują XHTML.
Polecam zvalidować ponownie swój pogląd na ten temat... :)
29 grudnia 2005 o 01:05:12
Internet Explorer nie renderuje XHTML, dla niego to jest nieznany typ dokumentu.
29 grudnia 2005 o 11:07:15
@Nerf: nie do końca - IE nie renederuje dokumentów o MIME Type application/xhtml+xml. XHTML1.0 może(may) być serwowany jako text/html, więc taki, jak najbardziej poprawny XHTML renederuje bez problemów. Natomiast jeśli chodzi o XHTML1.1 który powinien(should) być wysyłany jako application/xhtml+xml to nie jest on rozpoznawany przez IE który (chyba) nie ma parsera XML, podobnie jak Konqueror, jednak ten, mimo że zgodnie z w3c powinien przemielić kod parserem XML, nie robi tego, a parsuje kod jako tag zupę.
29 grudnia 2005 o 19:44:15
Outi:
IE poprawnie wyświetla tylko HTML. XHTML wyświetla się na ogół poprawnie tylko dlatego, że IE mylnie bierze go za HTML 4.
Żeby sprawdzić, proponuję spróbować zacząć stronę od prologu XML i zobaczyć, co się stanie.
Druga zabawa może polegać choćby na wysłaniu jakiegokolwiek skryptu jako sekcji CDATA.
Po trzecie - IE nie usuwa komentarzy przed przeparsowaniem dokumentu, co jest wymagane w przypadku XML.
05 stycznia 2006 o 23:18:32
O ile to wszystko dobrze rozumiem, to kod napisany zgodnie ze standardem xhtml, ale wysłany z mime text/html jest i powinien być we wszystkich przegladarkach traktowany jako html (chyba, że ktoś na sztywno ustawi coś innego). Co więcej jest to zniekształcony html (bo chodźby z pododawanymi niepotrzebnymi w html slashami przy pustych elementach).
A XSLT zawiera się oczywiście w XSL i służyć może zarówno po stronie serwera, jak i klienta. Z tym, że z pewnością fatalnym pomysłem jest wysyłać stronę jako XML z dołączonym arkuszem XSLT (a ktoś tam wspomniał, że marzy mu się taka sytuacja).
A jak to jest z obsługą XSLT w przeglądarkach z systemów innych niż Windows?
06 stycznia 2006 o 12:14:46
A jeszcze jedno..
Czy naprawdę widujesz tak wiele stron przesyłanych jako aplikacja xhtml? Bo osobiście to nawet jeśli w kodzie strony widzę jakieś wynikające z niewiedzy i ignorancji 'application/xhtml+xml', pełny prolog XML, z którego też wynika, że jest to XHTML1.1, to i tak strona przesyłana jest jako text/html. Podsumowując: ja nie spotkałem się z takim problemem o jakim mówisz.
06 stycznia 2006 o 18:25:06
ffreak: Dlaczego "fatalnym pomysłem jest wysyłać stronę jako XML z dołączonym arkuszem XSLT"?
Przeglądarki z systemów innych niż Windows? Epiphany, Galeon i kilka innych korzysta po prostu z Gecko i XSLT obsługuje, KHTML nie obsługuje XHTML, XSLT też nie. Opera tak samo jak pod Windows. Safari - niby na KTML/WebKit, ale co do niej to nie mam pojęcia.
06 stycznia 2006 o 19:15:46
mcv:
Jeśli to ma być strona WWW, to powinna być wysyłana jako taka. XSLT może posłużyć jako dodatek do "uczytelnienia" danych, które są przeznaczone do przetwarzania przez automatykę (jak choćby RSS).
Jeśli chodzi o WWW, to XSLT powinno być przetwarzane po stronie serwera. Ograniczanie grona odbiorców przez własną arogancję to nienajlepsza metoda na robienie biznesu.
19 stycznia 2006 o 18:41:44
xhtml... no niestety standardy sa nie do przegryzienia, ja uzywam swf`yów;D moze nie dojdzie do ich zaglady
my site: http://cannabis.fr.pl
27 maja 2006 o 11:34:19
Hmm. no ja mam swój hołmpejdż w 100% zgdony z XHTML 1.1 i za pomocą komentarzy warunkowych postarałem się, żeby IE wyświetlało go poprawnie. Tak więc nie wydaje mi się, żebym robił w ten sposób jakąś szkodę...
03 lipca 2006 o 17:24:58
a ja jestem załamana, kurde, bo nie zdążyłam html'a opanować, a tu xhtml - a ja nic z niego nie rozumiem - to czego mam się uczyć, html'a czy xhtml'a? Bo już sama nie wiem... :(
can you help me?
28 grudnia 2006 o 18:31:33
to prawie jedno i to samo.
nauczysz się jednego, poczytasz z godzinę i umiesz drugie...
06 kwietnia 2007 o 00:26:22
Tak szczerze? Jak ktoś się nauczy HTML'a, to przejście na XHTML'a zajmuje dłużej niż godzinkę. Naprawdę. Jednak jak ktoś pozna XHTML, to przejście na HTML to są dwie minuty. Do przyswojenia dwie kwestie: Nie zamykać pustych tagów (<br />, <th /> itp.) i usunąć prolog xml oraz zmienić DOCTYPE. Reszta poprawnie napisanego XHTML'a będzie poprawnym HTML'em (choć o ile się nie mylę zamknięcie tagów br, th itp. nie jest błędem w HTML'u, ale dawno nie używałem, to głowy nie dam).
02 lipca 2007 o 14:25:28
> 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.
Dla programów czytający tekst to jest (będzie) spora podpowiedz. Twierdzisz że w 'dostępności' nie zawiera się dostępność dla osób niewidomych?
> Dwie wielkie zalety, ale zalety dla ciebie i autorów przeglądarek. Klient i internauta nie mają z tego absolutnie nic.
Mniej kodu -> mniej błędów
Mniej kodu -> mniejszy program
Twierdzisz że program zajmujący mniej pamięci/CPU i mający mniej błędów to żadna korzyść dla internauty?
> 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.
A HTML 5 będzie wspierany przez starsze przeglądarki? Jakie niby korzyści daje HTML 5 nad XHTML dla przeglądarek które ich nie obsługują? Starsze wersje Safari będą ja obsługiwały(przykład z tekstu)? IMHO przeczysz sobie.
> ze wysyłanie komuś XML i XSL to tak jakby wysłać komuś PHP i powiedzieć "wygeneruj sobie HTML samodzielnie")
Tak - ile czasu zajmie ci wydobycie potrzebnych danych (choćby przez ECMAScript) z XML a ile z HTML? Przy XML możesz spokojnie użyć gotowych rozwiązań i zmieniać kod w jednym miejscu a nie w 10 różnych (naruszenie SPOT)
11 września 2007 o 21:08:38
Ja osobiście uważam, że XHTML to bardzo dobry standard. XHTML to efekt końcowy przy cięciu grafiki internetowej - webdesign, .psd do XHTMLa i CSS.
25 stycznia 2008 o 12:48:28
o bożę... ludzie, od kogo wy takie bzdury zasłyczeliście...? Sami też nie piszcie bzdur! Co ma XSLT do przeglądrki! Transformacja jest niezależna od tego jaki jej efekt zostanie przesłany do przeglądarki (jako rezultat). Poza tym XSLT nie jest jakąś alternatywą dla HTML/XHTML/xHTML(ten ostatni to typowy dla windowsiarzy z IE) tylko jest doskonałym rozszerzeniem możliwości przy tworzeniu aplikacji XML. Większość może niech zacznie też od zrozumienia czym jest xml, a czm jest zwykły tekst. I dlaczego XHTML NIE JEST ABSOLUTNIE I NIE BĘDZIE OBSŁUGIWANE przez Internet Exploitera (i przy okazji przez google). Jeśli ktoś twierdzi że jego strona XHTML działa w Internet Exploiterze to znaczy że strona nie jest ani poprawnym xhtml, ani też html... Internet Explorer stronę XHTML nie tylko zignoruje (nie wyświetli) ale potraktuje jako niebezpieczny zasób pobierany z Internetu (application/xhtml+xml), do tego nie pytając specjalnie użytkownika o zdanie zapisze plik z niezrozumiałym dla siebie kodem "gdzieś tam"... Poza tym, jaki jest problem w tym aby używać HTML 4.01 z CSS2.1/3.0??? Żaden, i efekt nie będzie wcale gorszy niż z XHTML (o ile nawet nie lepszy)...
25 stycznia 2008 o 12:54:50
Aha - validator kodu html/xhtml można sobie rozbić o kant przysłowiowej d... skoro nie rozumie się co on tak na prawdę sprawdza, a czego nie jest w stanie sprawdzać (bo widać że wielu nie tylko nadużywa znaku Glidera, ale ślepo wierzy w treść beznadziejnie tłumaczonych książek z Helionu itp.).
06 lutego 2008 o 20:07:55
Mój aktualny projekt jest wykonany w całości w XHTML1.1, i działa poprawnie we wszystkich normalnych przeglądarkach od IE5.5 po Safari 3 czy Operę 9.5. Fakt, że IE nie korzysta z zawartości application/xhtml, ale pozostałe, normalne przeglądarki to robią. Więc jedna lewa encja czy błędny tag i piękny żółty ekranik powodujący że poprawiam buga w momencie w którym się pojawił. Brakujące elementy (jak iframe, target, rel) dopisałem sobie w DTD, co jest z resztą zgodne ze specyfikacją. Ktoś zainteresowany magicznym DTD? :) Pisać... (Co do projektu, to startujący portal internetowy, aspirujący do roli "gracza" w swojej tematyce)
16 lutego 2008 o 11:52:11
To się nazywa być skoncentrowanym naprocesie a nie na wyniku
03 kwietnia 2008 o 11:23:30
Się zmieniły realia od 2005 roku ;)
06 września 2010 o 21:23:53
Prorok normalnie.