Co się stało z XHTML5?

http://www.w3.org/TR/html5/

Ta strona jest wersją roboczą zarówno dla xhtml5, jak i html5? Więc nie ma różnicy między tymi typami dokumentów?

W 2012 r. W momencie pisania było jasne, że W3C zdecydowało się zrezygnować z XHTML dla HTML 5. Decyzja ta została uzasadniona z kilku powodów:

• Tylko kilka osób naprawdę interesowało się XHTML. Większość stron została napisana zwykłym HTML.

• Jeszcze mniej naprawdę rozumiało, na czym polega XHTML i jak go używać. Zbyt wiele witryn, które udawały, że obsługują XHTML, używały niewłaściwych nagłówków zamiast Content-Type: application/xhtml+xml.

• Nawet jeśli w pełni rozumiesz, co to jest XHTML i jakie muszą być nagłówki, sprawa jest naprawdę trudna, gdy niektóre kiepskie przeglądarki nie akceptują / nie obsługują application/xhtml+xmltypu zawartości. Oznaczało to, że musiałeś zmienić nagłówek zgodnie z przeglądarką.

• Część XML XHTML również spowodowała dziwne sytuacje, które musieli rozwiązać programiści. Jednym z nich jest INVALID_STATE_ERR: DOM Exception 11komunikat pojawiający się, gdy przypisujesz tekst zawierający znaki HTML (jak é) do elementu na stronie XHTML. Kiedy napotkasz ten błąd i jego bardzo pomocny komunikat w dużej aplikacji internetowej po wykonaniu żądania AJAX, naprawdę nie masz pojęcia, czy to wina JQuery, AJAX, czy coś innego.

• Pisanie kodu HTML 5 nie oznacza mieszania tagów dookoła. Jeśli pasjonujesz się XML i XHTML, nadal możesz pisać kod HTML 5, który będzie wyglądał bardzo blisko XML.

• Na początku telefony komórkowe XHTML był interesujący dla urządzeń mobilnych, które nie były bardzo wydajne. Analiza XML jest znacznie łatwiejsza niż HTML. Teraz, w przypadku dwurdzeniowych urządzeń mobilnych, naprawdę nie ma znaczenia, czy muszą one parsować czysty poprawny XML lub brudny HTML pełen hacków i mieszanych tagów.

Specyfikacja z października 2014 r. Wspomina o składni XHTML . W tej chwili nie jest jasne, czy istnieje coś takiego jak nowy język XHTML (bez składni ), a jeśli tak, to jaka będzie pozycja XHTML, ani przyjęcie nowego standardu XHTML przez główne przeglądarki.

XHTML5 jest synonimem „HTML5 serializowanego jako XML”.

Istnieją różne konkretne składnie, których można użyć do przesłania zasobów korzystających z tego abstrakcyjnego języka, z których dwa są zdefiniowane w tej specyfikacji.

...

Druga konkretna składnia to składnia XHTML, która jest aplikacją XML. Gdy dokument jest przesyłany z typem XML MIME, takim jak application / xhtml + xml, jest on traktowany przez przeglądarkę internetową jako dokument XML, który ma zostać przeanalizowany przez procesor XML. Przypomina się autorom, że przetwarzanie XML i HTML różni się; w szczególności nawet drobne błędy składniowe uniemożliwiają pełne renderowanie dokumentu oznaczonego jako XML, podczas gdy byłyby one ignorowane w składni HTML. Ta specyfikacja definiuje wersję 5.0 składni XHTML, znaną jako „XHTML 5”.

• cytowany z http://www.w3.org/TR/html5/introduction.html#html-vs-xhtml ; uwaga, która mówi również: „Ta sekcja jest nienormatywna”.

Jest też fajny dokument na temat pisania poliglotów HTML5 (stron, które można serializować zarówno jako zwykły HTML5, jak i XML) tutaj:

http://dev.w3.org/html5/html-polyglot/html-polyglot.html#bib-HTML5

I nawet walidator!

http://html5.validator.nu/

Obecnie rzadko nazywa się go XHTML5 (i prawdopodobnie jeszcze rzadziej jest używany), ponieważ zasadniczo jest to HTML5, ale nadal tam jest.

Mówiąc prosto: każda zmiana specyfikacji HTML5 jest również domyślna, odpowiadająca zmianie w XHTML5.

HTML5 to de facto i de jure standard! XHTML jest tam również w standardzie.

HTML5 - Słownictwo i powiązane interfejsy API dla HTML i XHTML

Zalecenie W3C z 28 października 2014 r

Tytuł standardu zawiera ciąg „i XHTML” , więc mówimy o ostatecznej decyzji W3C o połączeniu HTML i XHTML w jeden pojedynczy standard ; i ten standard pokazuje, jak serializować plik HTML do pliku XHTML i odwrotnie.

XHTML części i ważne uwagi:

• typ MIME to application/xhtml+xml
• 2.2.4 Interakcje z XPath i XSLT
• 9. Składnia XHTML

Zrozumienie i korzystanie

Jak podsumował LF Sikos

XHTML5 to serializacja XML HTML5. Składnia jest opisana w specyfikacji HTML5. Nie należy jednak mylić, ponieważ XHTML5 jest aplikacją XML. Innymi słowy, HTML5 i XHTML5 mają identyczne słownictwo, ale różne reguły parsowania.

Dokumenty HTML5 mogą być również prawidłowymi dokumentami XML. Ten znacznik jest często nazywany językiem „polyglot”. Jest to język nakładania się dokumentów będących jednocześnie dokumentami HTML5 i XML. Serializacje HTML5 i XHTML5 są kompatybilne krzyżowo. Jednak XHTML5 ma surowszą składnię. Ponadto niektóre części XHTML5 nie są poprawne w HTML5, np. Instrukcje przetwarzania.

Tak więc, ściśle mówiąc (i podkreślone przez @vaxquis) „XHTML to tylko składnia do serializacji XML”, nie ma DTD ani innego rodzaju schematu XML .

Niektórzy ludzie nie lubią mówić „XHTML5 to XHTML”. Pytanie musi zostać podzielone na mini-FAQ na temat „kiedy mogę użyć go jako XHTML”. To jest WIKI, proszę poprawić, jeśli istnieje jakieś „nieporozumienie” ...

FAQ

Czy mogę używać XHTML5 jako „wersji standardu XHTML 2014”?

Występują pewne problemy związane z „idealną i ogólną konwersją HTML5 na XHTML5 / XHTML5 na HTML5”, musisz dokonać „osobistych wyborów” i utraconych informacji. W kontekście będą różne odpowiedzi:

• Luźno mówiąc : TAK. Istnieje wiele (prostych) przykładów, w których mapowanie jest idealne i odwracalne.

• Ściśle mówiąc : NIE. Zobacz także komentarz @vaxquis poniżej i stare odpowiedzi na tej stronie. Niektóre typowe problemy:

  • https://stackoverflow.com/a/16591582/287948
  • ... proszę wzbogacić o więcej przykładów ...

Czy mogę używać (nieustraszonej!) Serializacji XHTML5 z XSLT, XPath itp.?

Tak, możesz. Nawet serializowanie fragmentów.

Czy mogę sprawdzić poprawność XHTML5?

Tak, ale nie tak szybko i łatwo niż stare DTD ... Zobacz złożone walidatory, jak validator.nu

Czy mogę używać XHTML5 jako wyjścia nieterminalnego w łańcuchu XSLT?

Tak, możesz. Wyjaśnijmy, co możesz.

Niektóre frameworki, takie jak Cocoon , używają „ łańcuchów XSLT ”. Wyjścia HTML5 i XHTML5 mogą być użyte jako „ostatnie wyjście w łańcuchu” ... Oczywiście na etapach pośrednich nie można użyć HTML5, ponieważ nie jest on XML, ale można użyć XHTML5.

Ponownie pojawia się powyższy problem walidacji : nie ma silnej konwencji, więc czasami pojawia się mniej klarowność „standardowej struktury XHTML”. W tej sytuacji musisz zwracać uwagę na „własne konwencje” i być konsekwentnym.

Czy korzystając z DOMDocument strony HTML5, mogę użyć saveXML()metody?

Tak. Jest to typowa sytuacja, w której stosuje się zalecenia serializacji. Kod XML będzie prawidłowy, kod XHTML5 jest odwzorowany z oryginalnego stanu HTML5 i DOM ... Ale w niektórych strukturach niektóre informacje mogą zostać utracone, jak skomentowano powyżej.

Tak, niestety XHTML zniknął.

Dodając jeszcze jeden powód do doskonałej odpowiedzi MainMa:

Kiedy XHTML został utworzony, miał być wykorzystywany przez WebApps do dostarczania ustrukturyzowanej treści, która byłaby zrozumiała dla oprogramowania innego niż przeglądarka, która nie miałaby parserów HTML-tag-soup. Dla ScreenReaders XHTML jest nadal świetny, ale w przypadku każdego innego oprogramowania WebServices to odpowiada i najczęściej używają XML lub JSON. Sam SOAP ma swój własny schemat XML, prostszy niż XHTML i zorientowany na działanie.

O ile wiem, na świecie nie ma nawet jednej aplikacji internetowej, która obsługiwałaby ten sam komunikat HTTP zarówno w przeglądarkach, jak i innych klientach. Nawet architektura REST, która miała służyć tej samej reprezentacji treści w wielu typach treści w oparciu o preferencje klienta, nie jest używana do obsługi przeglądarek XHTML / feed.

Na przykład w Javie EE za pomocą Eclipse możemy wdrożyć unikalny plik wojenny zawierający serwlety + strony JSP do obsługi HTML oraz Axis2 do obsługi WebService. Po prostu łatwiej jest tworzyć oddzielne oprogramowanie przeznaczone dla przeglądarek i WebService niż mieć unikalne, złożone oprogramowanie, które obsługuje je wszystkie.

Głównym powodem odrzucenia usługi REST jest właśnie złożoność (i miała być prosta!) Opracowania serwera, który obsługuje tę samą zawartość dla dowolnego typu klienta, nie wiedząc o tym nic. Trudno jest również zaspokoić potrzebę szybkiego rozwoju sieci wraz z utrzymaniem stabilnej definicji, która nie zmusiłaby klientów innych niż przeglądarka do aktualizacji za każdym razem, gdy zmienia się XHTML, powiedzmy, że zachowuje poprawność XHTML, gdy jest zbudowany przez wiele różnych modułów.

W ten sam sposób bardzo trudno jest stworzyć klienta innego niż przeglądarka, który analizuje dokument XHTML, nawet jeśli jest on prawidłowy, ze względu na wszystkie te elementy XML, które mają na celu strukturę układu renderowanego w przeglądarce, a nie do przechowywania zawartości.

Jeśli osoby adoptujące REST już narzekają na złożoność XML SOAP, która jest DROGA prostsza niż XHTML przeznaczony dla przeglądarki, wyobraź sobie, jak trudno jest obsługiwać XHTML dla wielu typów klientów, po stronie serwera i po stronie klienta.

W praktyce: jeśli chcesz, używaj HTML-a, podobnego do XML-a, do tworzenia stron internetowych dla przeglądarek oraz wszelkiego rodzaju rozwiązań WebService dla klientów nieobsługujących przeglądarki.

ALE myślę też, że należy utworzyć XHTML5. XHTML 1.1 (ok, 1.0, 1.1 jest bezużyteczny) z HTML5 stanie się przestarzały, a my nadal potrzebujemy walidatora, który akceptuje elementy HTML5 i sprawdza poprawność XML.