Krótka odpowiedź: nie.
Nigdy nie stwierdziłem, że Strict XHTML jest wart wysiłku.
Pierwszy problem polegał na tym, że wycofał wiele użytecznych funkcji HTML, a dla których nie było dobrych alternatywnych rozwiązań. Był to szczególny problem, jeśli potrzebna była kompatybilność wsteczna ze starszymi przeglądarkami (co oczywiście każdy robi). Specyfikacja Transisional nie wycofała tych funkcji, dlatego ludzie używają go raczej niż Strict.
Funkcje, które zostały wycofane zawarte tag <center> (alternatywy CSS nie były kompatybilne z różnymi przeglądarkami w tym czasie) i atrybut target dla <a> tag (który pozwala otworzyć link w nowym oknie, na karcie lub ramy; nadal nie ma innego sposobu, aby to zrobić, nikt nie przestał go używać, a HTML5 ponownie go wprowadził). Na tych samych liniach było sporo innych funkcji, ale minęło dużo czasu i nie pamiętam ich wszystkich.
Po drugie, został zaprojektowany, aby spowodować awarię przeglądarki, jeśli twój znacznik ma najmniejszy błąd. Brzmi świetnie w teorii, ale zawsze był skazany na niepowodzenie. Był to zasadniczo reakcyjny krok podejmowany przez twórców specyfikacji przeciwko rozprzestrzenianiu złej jakości kodu HTML, który był (i do pewnego stopnia nadal jest) poważnym problemem dla sieci. Ale zapomnieli o kluczowej zasadzie projektowania protokołów typu klient-serwer, czyli o tym, że serwer powinien być ściśle związany z tym, co wysyła, ale klient powinien być łagodny. Wszystkie udane protokoły klient-serwer są zgodne z tą zasadą.
Warto zadbać o to, aby Twój znacznik był ważny - w rzeczywistości jest bardzo ważny, niezależnie od tego, jaki (x) dialekt HTML, który piszesz - ale powinieneś sprawdzić, czy w fazie rozwoju, nie pozwalając przeglądarce użytkownika końcowego wykonać Twoją walidację. Jeśli jesteś dobrym programistą, powinieneś wiedzieć, że twój kod jest dobry, zanim znajdzie się w pobliżu użytkownika. I faktycznie, jeśli to spowoduje, że Twoja strona całkowicie złamie się przed użytkownikiem końcowym, to jest to katastrofa. W przypadku złamanego kodu HTML, nawet jeśli jest on bardzo poważnie uszkodzony, użytkownik może na ogół nawigować i czytać witrynę w stopniu wystarczającym do znalezienia danych kontaktowych umożliwiających zgłoszenie błędu. W przypadku przeglądarki, która respektuje ścisły typ dokumentu XHTML, niewielki błąd znaczników może spowodować, że witryna nie wyświetli niczego oprócz standardowego komunikatu o błędzie przeglądarki. Jest to bardzo kiepskie doświadczenie dla użytkownika.
Wreszcie nie dostarczył żadnych nowych funkcji. Jedyną rzeczą, której nie zrobiły starsze wersje HTML, było umożliwienie parsowania dokumentu jako dokumentu XML. To było dobre dla potwierdzenia, że dokument nie zawiera błędów, ale tak naprawdę nie osiągnął zbyt wiele. Można również osadzić inne formaty XML w dokumencie za pomocą przestrzeni nazw, ale to było skomplikowane i nie osiągnęło zbyt wiele nowych.
XHTML zawsze był idealistycznym marzeniem i na szczęście znika teraz, gdy HTML5 przejął rolę nowej i ekscytującej rzeczy.
Czy możesz podać kilka przykładów przydatnych przestarzałych funkcji? Wydawało mi się, że wszystkie funkcje mają dobre rozwiązanie zgodne z XHTML. – tskuzzy
@tskuzzy - ok, zredagowałem odpowiedź, aby uwzględnić dwie funkcje, które uniemożliwiły mi przejście na XHTML Strict w ciągu dnia. – Spudley