Dlaczego nie XHTML5?


53

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?


6
+1 Widzę, że nie tylko jestem sfrustrowany utratą wszystkich zalet XML w HTML5.
Arseni Mourzenko

Dobre pytanie, dobrze postawione.
Konrad Rudolph

1
Mam nadzieję, że nie jestem jedyny, który cieszy się z utraty wszystkich wad XML w HTML5. Na przykład porównajmy poprawny HTML5 z poprawnym XHTML. HTML5 <!DOCTYPE html>Hello World<?xml version="1.0" encoding="iso-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd"><html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><title></title></head><body>Hello World</body></html>
:,

@zzzzBov, zdecydowanie nie jesteś jedynym, który się cieszy, i dlatego zadałem to pytanie w pierwszej kolejności. Ponadto: nie napisałbyś serio <!DOCTYPE html>Hello World, prawda? Wypróbuj to na tym walidatorze .
jameshfisher

1
@eegg, najwyraźniej nie czytałeś spec na opcjonalnych tagów startowych , bo ciężko byłoby napisać <!DOCTYPE html>Hello World!, jak to jest całkowicie poprawny HTML5. Krótsze dokumenty oznaczają mniejsze obciążenie sieci, co oznacza znaczne oszczędności dla dużych firm (czy widziałeś, co Google wysyła na www.google.com?).
zzzzBov

Odpowiedzi:


25

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.


18
Tak. Moje streszczenie tej historii brzmiałoby: „Hej, nikt nie jest zgodny ze specyfikacją. Być może moglibyśmy sprawić, by dostosowali się do specyfikacji, określając, że ludzie mogą popełniać dowolne błędy. W końcu wszystkie nasze dokumenty będą wolne od błędów i zgodny ze standardami ”. Pisanie specyfikacji przy założeniu, że nikt nie szanuje specyfikacji, nie może wynikać z niczego.
jameshfisher

1
@eegg, twój ostatni wiersz pokazuje twoją ignorancję wobec rzeczywistości. Wiele rzeczy już przyszło, zakładając, że nikt nie jest doskonały . Zamiast tego, mówiąc: „jeśli popełnisz jakiś błąd, wszystko się zepsuje”, zamiast tego mówi: „jeśli popełnisz [tego typu błąd], wtedy [ten wynik] powinien się zdarzyć”. Ile książek byłoby na naszych półkach, gdyby musiały mieć w 100% poprawną pisownię, interpunkcję i gramatykę, aby mogły zostać opublikowane?
zzzzBov

6
@zzzzBov, twoja analogia do opublikowanych książek jest dziwna. Dlaczego parser HTML miałby być bardziej wybaczający niż analizator składni dla [dowolnego innego języka tutaj], gdzie występuje błąd składniowy z komunikatem o błędzie? Wyobraź sobie chaos, w którym znaleźlibyśmy się, gdyby nasze kompilatory C starały się w milczeniu ponownie zinterpretować zepsutą składnię.
jameshfisher

@eegg, mogę sobie wyobrazić, co by się stało, gdyby parser dla dowolnego innego języka zareagował na błędy składniowe w bardziej wybaczający sposób: spędzilibyśmy mniej czasu na szukaniu źle umieszczonych nawiasów i brakujących średników, a więcej na pisaniu kodu funkcjonalnego. Nie twierdzę, że dobrzy programiści wciąż nie poprawiliby swoich programów, ale z pewnością pomogłoby to przeciętnym programistom pisać działający kod. CProgram będzie prawdopodobnie w końcu wygląda znacznie bardziej podobny do Pythonprogramu tym, że średniki i uchwyty mogłyby przeważnie znikają, a co będzie w lewo jest ważny kod.
zzzzBov

„Żądany zasób /past.htmlnie jest już dostępny na tym serwerze i nie ma adresu do przekazywania dalej.”
Marco

6

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


Zdefiniuj „dobry jazz”. AFAIK nie ma żadnej korzyści z parsowania HTML jako XML. Generowanie i przekształcanie to inne sprawy, mogą być wygodne, ale samo parsowanie nie ma zalet, a jedynie wady (powoduje, że błędy kosmetyczne są śmiertelne).
Joeri Sebrechts

3
@Jeri Fakt, że parsowanie jest o wiele łatwiejsze, jest zaletą w mojej książce z wielu powodów (ścisłe parsowanie ułatwia wykrywanie błędów, lepsze wsparcie narzędzi, ponieważ narzędzia są łatwiejsze do pisania, łatwiejsze dezynfekowanie danych wejściowych itp.).
Konrad Rudolph

Możesz także podać niektóre funkcje niedostępne w standardowym HTML, takie jak micin xhtml z innymi treściami xml, i ogólnie używać wszystkich funkcji xml, przestrzeni nazw dla przykładu. parser HTML jest w stanie naprawić zły kod źródłowy - kosmetyczne błędy, jak je wywołujesz - ale te poprawki mają swoją cenę. Cena polega na tym, że przeglądarka musi wiedzieć, co może znaleźć w kodzie, ograniczając w ten sposób dostępne funkcje.
deadalnix

3

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ąć.


3
Opowieść o niechlujstwie przeglądarek jest prawdziwa. Ale o to chodzi: właśnie dlatego maniacy standardów istnieją. Gdyby wszystkie przeglądarki od samego początku wprowadzały ścisłe i wąskie zasady, organizacje takie jak W3C nie musiałyby tu być, aby zachować kontrolę. Istotą norm jest kontrola szkód; poddanie się przez organ normalizacyjny i zaakceptowanie niechlujstwa przeczy jego celowi.
jameshfisher

1
@eegg: HTML5 redefiniuje reguły analizowania, aby wszystkie dane wejściowe były prawidłowe i nadal miały przewidywalne konsekwencje. Jeśli błędy składniowe są niemożliwe, od początku wykluczana jest cała klasa błędów. Zdolność XML do błędów analizy jest wadą projektową i powinna zostać uznana za taką.
Joeri Sebrechts

1
@Joeri, twoja pozycja wydaje się być taka, jak w specyfikacji HTML5, do jej szalonego logicznego wniosku. „HTML5 redefiniuje reguły analizowania, aby wszystkie dane wejściowe były prawidłowe” - tak nie jest. Koncepcja błędów analizowania nadal istnieje. „Jeśli błędy składniowe są niemożliwe, od początku wykluczana jest cała klasa błędów” - może to parodia? Tę logikę sarkastycznie sparafrazowałem w swoim komentarzu do odpowiedzi @pthesis. Tak, klasa błędów składniowych została usunięta i zastąpiona większą klasą błędów korekcji składni w przeglądarce .
jameshfisher

2

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.


Ponad specyfikacją HTML4 tak. Ale chodzi mi o to, że XHTML1.1 już to poprawił. Narzędzia / biblioteki do obsługi HTML wydają się być jak BeautifulSoup - chociaż są wspaniałymi narzędziami, powinny umrzeć wraz ze stronami, które zostały przeanalizowane.
jameshfisher

1

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).

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.