Quindi cosa è successo a XHTML5?
Quella pagina è una bozza sia per xhtml5 che per html5? Quindi non c'è differenza tra questi doctype?
Nel 2012 al momento della stesura, era chiaro che il W3C ha deciso di abbandonare XHTML per HTML 5. Questa decisione è stata motivata da diversi motivi:
Solo poche persone erano davvero interessate all'XHTML. La maggior parte dei siti Web è stata scritta in HTML semplice.
Ancora meno capiscono cosa sia XHTML e come usarlo. Troppi siti web che pretendevano di pubblicare XHTML utilizza intestazioni errate anziché Content-Type: application/xhtml+xml .
Anche quando comprendi pienamente cosa sia XHTML e quali debbano essere le intestazioni, la cosa è davvero complicata con alcuni browser schifosi che non accettano / supportano il tipo di contenuto application/xhtml+xml . Ciò significava che dovevi cambiare l'intestazione in base al browser.
Anche la parte XML di XHTML ha causato alcune strane situazioni che gli sviluppatori dovevano risolvere. Uno è il messaggio INVALID_STATE_ERR: DOM Exception 11 visualizzato quando si assegna il testo contenente caratteri HTML (come é ) a un elemento all'interno della pagina XHTML. Quando incontri questo errore con il suo messaggio molto utile in una grande applicazione web dopo aver fatto una richiesta AJAX, non hai davvero idea se è colpa di JQuery, AJAX o qualcos'altro.
Scrivere un codice HTML 5 non significa mescolare i tag tutto intorno. Se sei appassionato di XML e XHTML, puoi ancora scrivere codice HTML 5 che apparirà molto vicino a XML.
All'inizio dei telefoni cellulari, XHTML era interessante per i dispositivi mobili che non erano molto potenti. L'analisi XML è molto più semplice di HTML. Ora, con i dispositivi mobili dual-core, non importa se devono analizzare un XML valido o un HTML sporco pieno di hack e tag misti.
Le specifiche di ottobre 2014 menzionano la sintassi XHTML . Per il momento, non è chiaro se esista qualcosa come la nuova lingua (non sintassi ) XHTML, e se esiste, quale sarà la posizione di XHTML, né l'adozione del nuovo standard XHTML da parte dei browser tradizionali.
XHTML5 è un sinonimo di "HTML5 serializzato come XML".
There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification.
...
The second concrete syntax is the XHTML syntax, which is an application of XML. When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is treated as an XML document by Web browsers, to be parsed by an XML processor. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent a document labeled as XML from being rendered fully, whereas they would be ignored in the HTML syntax. This specification defines version 5.0 of the XHTML syntax, known as "XHTML 5".
Inoltre, c'è un bel documento sulla scrittura di poliglotti HTML5 (pagine, che possono essere serializzate sia come normali HTML5 che XML) qui:
E anche un validatore!
Al giorno d'oggi è raramente chiamato XHTML5 (e probabilmente usato anche più raramente), dato che è fondamentalmente ancora HTML5, ma è ancora lì.
In poche parole: ogni modifica alle specifiche HTML5 è anche una modifica implicita e corrispondente a XHTML5.
HTML5 è un di fatto e de jure standard! XHTML è presente anche come standard.
Raccomandazione W3C 28 ottobre 2014
Il titolo dello standard contiene la stringa "e XHTML" , quindi stiamo parlando di una decisione finale del W3C di unire HTML e XHTML in un unico standard ; e questo standard mostra come serializzare un file HTML in un file XHTML e viceversa.
XHTML parti e note importanti:
application/xhtml+xml
Come riassunto da LF Sikos
XHTML5 is the XML serialization of HTML5. The syntax is described by the HTML5 specification. However, one shouldn’t be confused since XHTML5 is as an application of XML. In other words, HTML5 and XHTML5 have identical vocabulary but different parsing rules.
HTML5 documents might also be valid XML documents. This markup is often referred as a “polyglot” language. It is the overlap language of documents which are HTML5 and XML documents at the same time. HTML5 and XHTML5 serializations are cross-compatible. However, XHTML5 has a stricter syntax. Furthermore, some parts of XHTML5 are not valid in HTML5, e.g., processing instructions.
Quindi strettamente parlando (ed enfatizzato da @vaxquis) "XHTML è solo una sintassi per la serializzazione XML", ci sono no DTD o altro tipo di schema XML .
Alcune persone non amano dire "XHTML5 è XHTML". La domanda deve essere suddivisa in una mini-FAQ su "quando posso usarlo come XHTML". Questo è un WIKI, per favore correggi se ci sono "incomprensioni" ...
Ci sono alcuni problemi in una "conversione HTML5-to-XHTML5 / XHTML5-to-HTML5 perfetta e generica", devi fare "scelte personali" e informazioni perse. Poiché il contesto sarà risposte diverse:
In silenzio : SÌ. Ci sono molti (semplici) esempi in cui la mappatura è perfetta e reversibile.
In senso stretto : NO. Vedi anche il commento @vaxquis qui sotto e le vecchie risposte in questa pagina. Alcuni problemi tipici:
Sì, puoi. Anche serializzare i frammenti.
Sì, ma non così veloce e semplice rispetto al vecchio DTD ... Vedi i validatori complessi, come validator.nu
Sì, puoi. Spieghiamo cosa puoi.
Alcuni framework, come Cocoon , usano " Catene XSLT ". Gli output HTML5 e XHTML5 possono essere utilizzati come "ultimo output nella catena" ... Naturalmente, nei passaggi intermedi, HTML5 non può essere utilizzato perché non è XML, ma è possibile utilizzare XHTML5.
Il problema sopra di validazione riappare qui: non esiste una convenzione strong, quindi, a volte, meno chiarezza della "struttura standard XHTML" appare. In quella situazione devi prestare attenzione nelle "tue convenzioni" ed essere coerente.
saveXML() ? Sì. Questa è una situazione tipica in cui vengono utilizzate le raccomandazioni di serializzazione. L'XML sarà valido, il codice XHTML5 è mappato dallo stato originale HTML5 e DOM ... Ma, in alcune strutture, alcune informazioni possono essere perse, come commentato sopra.
Sì, sfortunatamente XHTML è sparito.
Aggiunta di un altro motivo alla grande risposta di MainMa:
Quando XHTML è stato creato, era pensato per essere utilizzato da WebApps per offrire contenuti strutturati che sarebbero compresi da software non-browser, che non avrebbero parser HTML di tag-soup. Per ScreenReader XHTML è ancora ottimo, ma per qualsiasi altro tipo di software, i servizi Web soddisfano questa esigenza e utilizzano principalmente XML o JSON. Lo stesso SOAP ha il suo schema XML, più semplice di XHTML e orientato al funzionamento.
Finché so, non c'è nemmeno 1 WebApp al mondo che serva lo stesso messaggio HTTP sia per i browser che per gli altri client. Anche l'architettura REST, che doveva servire la stessa rappresentazione di un contenuto in più tipi di contenuto in base alle preferenze del cliente, non viene utilizzata per servire i browser XHTML / feed.
In Java EE, ad esempio, utilizzando Eclipse possiamo implementare un file war unico con Servlets + JSP per servire HTML, insieme ad Axis2 per servire un WebService. È semplicemente più semplice sviluppare software separati per browser e WebService che avere un software unico e complesso che li serva tutti.
Il motivo principale per cui il REST viene rifiutato è esattamente la complessità (e doveva essere semplice!) di sviluppare un server che offra lo stesso contenuto per qualsiasi tipo di client senza sapere nulla al riguardo. Ed è anche difficile gestire la necessità del Web di evolversi rapidamente, insieme a mantenere una definizione stabile che non impone l'aggiornamento dei client non browser ogni volta che cambia un XHTML, diciamo per mantenere l'XHTML valido quando è costruito da molti moduli diversi.
Allo stesso modo, è molto difficile sviluppare un client non browser che analizzi un documento XHTML, anche se è valido, a causa di tutti quegli elementi XML che sono pensati per strutturare il layout reso dal browser e non destinati a tieni il contenuto.
Se gli utenti REST già lamentano la complessità XML di SOAP, che è più semplice di un XHTML pensato per un browser, immagina quanto sia difficile gestire XHTML per più tipi di client, server e lato client.
In pratica: usa HTML, tipo XML se vuoi, per costruire WebSites per browser e qualsiasi tipo di soluzione WebService per client non-browser.
BUT, penso anche che XHTML5 debba essere creato. XHTML 1.1 (ok, 1.0, 1.1 è inutilizzabile) diventerà obsoleto con HTML5, e abbiamo ancora bisogno di un validatore che accetti gli elementi di HTML5 e convalidi la wellformedness XML.