Dlaczego nie XHTML5?

Tak więc, HTML5 jest wielkim krokiem naprzód, jak mi powiedziano. Ostatnim krokiem, jaki zrobiliśmy, o którym jestem świadomy, było wprowadzenie XHTML. Korzyści były oczywiste: prostota, surowość, możliwość korzystania ze standardowych parserów i generatorów XML do pracy ze stronami internetowymi i tak dalej.

Jak dziwne i frustrujące jest to, że HTML5 cofa to wszystko: po raz kolejny pracujemy z niestandardową składnią; po raz kolejny mamy do czynienia z bagażem historycznym i złożonością parsowania; po raz kolejny nie możemy używać naszych standardowych bibliotek XML, parserów, generatorów ani transformatorów; i wszystkie zalety wprowadzone przez XML (rozszerzalność, przestrzenie nazw, standaryzacja itd.), że W3C spędził dekadę z dobrych powodów, zostały utracone.

No dobrze, mamy XHTML5, ale wygląda na to, że nie zyskał popularności tak jak kodowanie HTML5. Zobacz na przykład to SO . Nawet specyfikacja HTML5 mówi, że HTML5, a nie XHTML5, „jest formatem sugerowanym większości autorów”.

Czy moje fakty są błędne? W przeciwnym razie dlaczego jestem jedynym, który tak się czuje? Dlaczego ludzie wybierają HTML5 zamiast XHTML5?

Polecam przeczytać Jak się tu dostaliśmy? . Mark Pilgrim podaje doskonałą i krótką historię HTML aż do HTML5.

Zasadniczo jednak rozumiem, że wiele stron internetowych nawet nie korzysta z „X” XHTML, ponieważ nie określają dla niego odpowiedniego typu MIME.

Jeśli stworzysz HTML5 zgodny z XML, i wyślesz go z XML jako typ MIME, wówczas parser xml zostanie użyty, wszystkie dobre jazzy powrócą;)

EDYCJA: zobacz, aby uzyskać więcej informacji: http://wiki.whatwg.org/wiki/HTML_vs._XHTML

HTML5 to logiczny i nieunikniony wniosek przeglądarek stosujących prawo Postela („Bądź liberalny w tym, co akceptujesz”).

Gdy jedna przeglądarka z wystarczającym udziałem w rynku przyjmie tę zasadę, inne są zmuszone do pójścia w jej ślady, nie tylko liberalizując się poprzez przyjmowanie treści niezgodnych, ale także czyniąc to w ten sam sposób, co ich konkurenci. HTML5 jest logicznym wynikiem tej sytuacji: dostawcy przeglądarek zdecydowali, że skoro nie odrzucą żadnych treści jako nieprawidłowych (przynajmniej nie na poziomie HTML - JavaScript to inna sprawa!) Mogą równie dobrze usiąść zgłoś i uzgodnij interpretację wszystkiego, co autor może do nich wrzucić. W tym środowisku nie zareagowali uprzejmie na zwykłych maniaków, mówiąc im, że gdyby tylko odrzucili źle sformułowane treści od samego początku, nie wpakowaliby się w ten bałagan.

Więc ty i ja możemy krzyczeć z boku i powiedzieć producentom przeglądarek i ich użytkownikom, że świat byłby lepszym miejscem, gdyby nie uwierzyli Johnowi Postelowi, ale szkoda została wyrządzona i bardzo trudno ją cofnąć.

Specyfikacja HTML5 została znacznie ulepszona w stosunku do specyfikacji HTML4. W szczególności obsługa warunków błędów i nieprawidłowych znaczników jest w rzeczywistości znormalizowana, co oznacza, że ​​wszystkie przeglądarki, które poprawnie implementują standard, będą obsługiwać nieprawidłowe znaczniki w ten sam sposób.

HTML jest pisany przez ludzi częściej niż zwykle (zwykle w połączeniu z jakimś językiem szablonów), a ludzie popełniają błędy. Tak długo, jak wszystkie przeglądarki obsługują błędy składniowe w ten sam sposób, zasada „bądź liberalna w tym, co akceptujesz” jest całkowicie akceptowalna.

Naprawdę niewielka zaleta w tworzeniu prawidłowego XML, ponieważ narzędzia i biblioteki do obsługi HTML są (prawie) tak samo łatwo dostępne, a HTML jest łatwiejszy do napisania dla ludzi niż XML.

Zresztą nigdy nie uzyskasz korzyści z prostszego parsera lub standardowych narzędzi XML po stronie klienta.

Istnieją miliardy stron w Internecie w HTML, niektóre z nich są pisane przez ludzi dawno zmarłych, więc nigdy nie będą aktualizowane do XML. Jeśli więc chcesz utworzyć ogólnie przydatnego klienta, musisz i tak parsować staroświecki HTML. Prawdopodobnie XHTML wprowadza tylko dodatkową złożoność, ponieważ wymaga nowego trybu analizowania oprócz analizy HTML, którą już musisz obsługiwać.

Po stronie serwera nadal możesz korzystać z narzędzi XML, np. generowanie XHTML przy użyciu XSLT. Ale jeśli nie używasz specjalnie łańcucha narzędzi XML, nie ma korzyści z używania składni XML, a nie tylko HTML.

(Nie masz racji, że HTML jest składnią „niestandardową”. Składnia HTML jest szczegółowo określona w specyfikacji HTML5, więc jest tak samo standardowa jak składnia XML).