Jeśli decydujesz się na używanie XHTML, to wybierz wersję 1.0. Wszystko jedno, czy zdecydujesz się na wersję przejściową (transitional) czy ścisłą (strict), będzie to lepszy wybór niż wersja 1.1. Przeżyłem dziś starcie z jednym z naszych kontraktowych współpracowników (pisałem już, że ostatnio większość szablonów trafia do pocięcia na outsourcing) i chciałbym swoje argumenty przytoczyć również poniżej.
Powodów preferowania wersji 1.0 może być kilka, przede wszystkim XHTML 1.1 wymaga serwowania jako typ MIME application/xhtml+xml. Typ ten nie jest obsługiwany przez przeglądarkę Internet Explorer i powoduje w niej wyświetlenie kodu źródłowego dokumentu.
Po drugie, XHTML 1.1 wymaga ścisłej kontroli składni XML i jakikolwiek błąd zatrzymuje caly proces przetwarzania strony. O ile z naszego punktu widzenia (jako programistów), poprawna składnia języka jest jak najbardziej pożądana, o tyle różne systemy publikacji treści pozwalają końcowemu użytkownikowi na zepsucie kodu w większym lub mniejszym stopniu. Z punktu marketingowego nie wygląda to najlepiej - klient wkleja tekst z Worda i strona umiera, a u konkurencji wszystko działa. Szczerze mówiąc, boję się, że to właśnie będzie największy problem przy szerszej popularyzacji formatów opartych na XML - nie potrafią wybaczać błędów (świat byłby dziś rajem, gdyby było to regułą już przy pierwszych wersjach HTML).
Poza tym, jedyna przewaga wersji 1.1 nad poprzedniczką jest możliwość łatwego rozszerzania języka, co przy braku wsparcia ze strony powszechnie używanych agentów nie jest żadnym argumentem.
Mówiąc krócej - nie zawsze warto żyć na krawędzi i chwytać się wszystkich nowości, warto poczekać, aż dostęp do nich uzyska przynajmniej zadowalająca część z naszych potencjalnych odbiorców.
Ja bym jeszcze wspomniał o *błędach* w specyfikacji i DTD 1.1 - bo są…
Jeśli chodzi o DTD, to można zignorować, bo jako aplikacja XML, XHTML ma dużo lepsze narzędzia do kontroli semantycznej i syntaktycznej.
Na szczęście na stronach czysto amatorskich, jakimi najczęściej bywają blogi, nie ma to większego znaczenia. Można się bawić w co tylko się chce.
"klient wkleja tekst z Worda i strona umiera, a u konkurencji wszystko działa."
gdzie wkleja ? w kod ? a kto mu daje mozliwosc ?
wkleja w posta ? a kto tego nie przeparsuje ? ;)
steelheart:
Przeparsować na co? Klient włącza w swoim CMS edytor WYSIWYG, który korzysta z designMode przeglądarki. Jeśli przeparsowanie polega na usunięciu tagów, to idea WYSIWYG właśnie umarła. I nie, nie jest to wina samego edytora, bo ten może najwspanialszy kod generować - samej przeglądarki nie da się powstrzymać przed wklejeniem nieprawidłowego kodu. Tu pojawia się problem pisania intelignentnego parsera SGML.
Też do tego dziś doszedłem po lekturze webesteem…
Ano. Też się spotkałem z tym czymś. Nie rozumiem ludzi którzy używają 1.1 i nie są to potężne aplikacje Webowe. Nawet na blogach nie rozumiem.
@Patrys:
… i czy nie jest tak, ze strona zaczyna byc renderowana dopiero po sciagnieciu i przeparsowaniu calego xml?
m:
True, dla XML serwowanego jako application/xhtml+xml nie istnieje renderowanie progresywne, bo przed parsowaniem następuje kontrola składni dokumentu.
Patrys: a co szkodzi zacząć wyświetlać stronę i przestać w momencie napotkania błędu? Przecież są nawet walidujące parsery SAX (wiem, walidacja tu i tak nie wchodzi w grę).
To jest możliwa optymalizacja, która będzie mogła być stosowana jak już XML będzie obsługiwany prawidłowo.
geez jesli CMS tworzy kontent nie zgodny z xml to jaki sens robic dla niego warstwe prezentacji w tym ostatnim ?
a jesli cms tworzy kontent OK a user wkleja jako tresc cos co powstało poza i jest nie halo, to imo nalezy przeparsowac, zwalidowac i ew. poinformowac ze jest lama ;)
przeciez majac DTD mozna to latwo zrobic chyba kazdym parserem w javce
Argument z htmlem z Worda jest akurat średnio trafiony, bo istnieje Tidy dla PHP.
Natomiast reszta tekstu - świetna.
bo ludzie mysla, ze trzeba byc nowoczesnym i uzywac nowych zabawek, gdy stare sie znudza
mała poprawka:
ludzie w wiekszosci nie myślą…
Oh, jakże absolutnie nie zgadzam sie z tym tekstem.
Transistional to formalizacja zupy z tagów. Zupełnie bez sensu. Jeśli ktoś robi elegancki kod, to niech celuje w Strict. W przeciwnym wypadku syf XMLowy jest niewiele lepszy od syfu HTMLowego.
XHTML/1.1 nie *wymaga* serwowania jako application/xhtml+xml (SHOULD NOT != MUST NOT). To jest tylko zalecenie (silniejsze niż przy 1.0) z dopuszczeniem serwowania jako text/html, które zostało specjalnie zrobione pod kątem IE.
I tak żadna wersja XHTML nie ma sensu, jeśli robi się pod IE, bo w nim siłą rzeczy nie da się wykorzystać *niczego*, co daje XHTML (test: <script />)
*Wszystkie* wersje XHTML wymagają ścisłej kontroli składni, bo XML jej wymaga. To, że przeglądarki akceptują tagzupę podaną jako text/html to odrębna sprawa i nie należy na tym polegać (bo - patrz akapit wyżej).
Za możliwość zepsucia XHTML winny jest webmaster, który nie obchodzi się z XML jak należy. Henri Sivonen dobrze to opisuje - XML nie należy traktować jako text, a jako drzewo node'ów: http://hsivonen.iki.fi/producing-xml/ i wtedy żadna siła go nie popsuje. W PHP5 wyczyszczenie WYSIWYGa jet tak proste jak DOMDocument::loadHTML()->saveXML();
Wersja 1.1 nie wnosi wiele do rozszerzalności. Zobacz listę zmian - przeniesienie atrybutu lang do przestrzeni nazw XML i dodanie znaków ruby.
Z tą rozszerzalnością to głupawo jest - otóż żadna wersja XHTML opublikowana przez W3C w praktyce nie jest rozszerzalna! DTD jest bardzo ścisłe i nie dopuszcza żadnej "samowolki" (nawet trzeba oddzielne DTD dla MathML, SVG, nie można w sposób błogosławiony przez W3C dodać RDF, itd.). Potencjalna rozszerzalność jest w XML, ale póki DTD czuwa nad dokumentem, póty jest on nierozszerzalny (albo piszesz własny, który nie jest 'standardem w3c').
Semantyka XHTML/1.0 nie różni się *niczym* od HTML/4. Nawet nie ma sekcji specyfikacji XHTML odpowiedzialnej za semantykę! XHTML/1.1 wprowadza minimalne zmiany, które IMHO specjalnie semantyczniejsze nie są (usunięcie html id/ol start, blockquote i form tylko z blokową treścią…).
Dla XML istnieje wyświetlanie progresywne (zob. SAX events). Tylko Gecko cierpi na prowizorkę w implementacji (o czym piszą na mozilla.org). XML+CSS bez problemu może być wyświetlany progresywnie. Tylko XSLT nie może ze względu na XPath.
Kilka miesięcy temu dostałem zadanie przemodelowania strony na której byłem webmasterem. Teraz mogę się poszczycić tym że strona jest w xhtml1.1, serwowana jest jako application/xhtml+xml z negocjacją dla "starszych" przeglądarek, aktualizacja nie jest częsta, a jak już jest do dostaje stos plików ms-word i dokładne wytyczne. Do mnie należy wklejenie tych wordowskich tekstów na stronę. Takie strony można tworzyć, ale nie dla klientów którzy widząc "xhtml" myślą że ten x jest literówką.