Cosa è successo a XHTML5?
Quella pagina è una bozza sia per xhtml5 che per html5? Quindi non c'è differenza tra questi doctypes?
Cosa è successo a XHTML5?
Quella pagina è una bozza sia per xhtml5 che per html5? Quindi non c'è differenza tra questi doctypes?
Risposte:
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 a XHTML. La maggior parte dei siti Web sono stati scritti in HTML semplice.
Ancora meno capiscono veramente di cosa tratta XHTML e come usarlo. Troppi siti Web che fingevano di servire XHTML usavano intestazioni sbagliate, invece di Content-Type: application/xhtml+xml
.
Anche quando capisci perfettamente cos'è XHTML e quali devono essere le intestazioni, la cosa è davvero complicata con alcuni browser scadenti che non accettano / supportano il application/xhtml+xml
tipo di contenuto. Ciò significava che dovevi cambiare l'intestazione in base al browser.
La parte XML di XHTML ha anche causato alcune strane situazioni che gli sviluppatori hanno dovuto risolvere. Uno è il INVALID_STATE_ERR: DOM Exception 11
messaggio che appare quando si assegna il testo contenente caratteri HTML (come é
) a un elemento all'interno della pagina XHTML. Quando si verifica questo errore con il suo messaggio molto utile in un'applicazione Web di grandi dimensioni dopo aver eseguito una richiesta AJAX, non si ha davvero idea se sia colpa di JQuery, AJAX o qualcos'altro.
Scrivere codice HTML 5 non significa mescolare tag tutto intorno. Se sei appassionato di XML e XHTML, puoi comunque 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 di XML è molto più semplice dell'HTML. Ora, con i dispositivi mobili dual-core, non importa davvero se devono analizzare XML validi o HTML sporchi pieni di hack e tag misti.
Le specifiche di ottobre 2014 menzionano la sintassi XHTML . Per il momento, non è chiaro se esiste una cosa come il nuovo linguaggio XHTML (non sintassi ), e se c'è, quale sarà la posizione di XHTML, né l'adozione del nuovo standard XHTML da parte dei browser tradizionali.
XHTML5 è sinonimo di "HTML5 serializzato come XML".
Esistono varie sintassi concrete che possono essere utilizzate per trasmettere risorse che usano questo linguaggio astratto, due delle quali sono definite in questa specifica.
...
La seconda sintassi concreta è la sintassi XHTML, che è un'applicazione di XML. Quando un documento viene trasmesso con un tipo MIME XML, come application / xhtml + xml, viene trattato come un documento XML dai browser Web, per essere analizzato da un processore XML. Si ricorda agli autori che l'elaborazione per XML e HTML differisce; in particolare, anche errori di sintassi minori impediranno il rendering completo di un documento etichettato come XML, mentre verrebbero ignorati nella sintassi HTML. Questa specifica definisce la versione 5.0 della sintassi XHTML, nota come "XHTML 5".
Inoltre, c'è un bel documento sulla scrittura di poliglotti HTML5 (pagine, che possono essere serializzate sia come HTML5 normale che XML) qui:
http://dev.w3.org/html5/html-polyglot/html-polyglot.html#bib-HTML5
E anche un validatore!
Al giorno d'oggi viene raramente chiamato XHTML5 (e probabilmente anche più raramente utilizzato), dal momento che è praticamente ancora HTML5, ma è ancora lì.
In poche parole: ogni modifica alle specifiche HTML5 è anche una modifica implicita, corrispondente a XHTML5.
HTML5 è uno standard di fatto e di diritto ! XHTML è presente, anche come standard.
Raccomandazione del W3C del 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 file XHTML e viceversa.
XHTML
parti e note importanti:
application/xhtml+xml
Come riassunto da LF Sikos
XHTML5 è la serializzazione XML di HTML5. La sintassi è descritta dalla specifica HTML5. Tuttavia, non si deve essere confusi poiché XHTML5 è come un'applicazione di XML. In altre parole, HTML5 e XHTML5 hanno un vocabolario identico ma regole di analisi diverse.
I documenti HTML5 potrebbero anche essere documenti XML validi. Questo markup viene spesso definito un linguaggio "poliglotta". È il linguaggio di sovrapposizione dei documenti che sono contemporaneamente documenti HTML5 e XML. Le serializzazioni HTML5 e XHTML5 sono cross-compatibili. Tuttavia, XHTML5 ha una sintassi più rigorosa. Inoltre, alcune parti di XHTML5 non sono valide in HTML5, ad esempio le istruzioni di elaborazione.
Quindi, a rigor di termini (e sottolineata da @vaxquis) "XHTML è solo una sintassi per la serializzazione XML", non ci sono nessun DTD o altro tipo di schema XML .
Ad alcune persone non piace dire "XHTML5 è XHTML". La domanda deve essere suddivisa in una mini-FAQ su "quando posso usarlo come XHTML". Questa è una WIKI, per favore correggi se ci sono dei "malintesi" ...
Ci sono alcuni problemi in una "conversione HTML5-XHTML5 / XHTML5-HTML5 perfetta e generica", devi fare "scelte personali" e perdere informazioni. Poiché il contesto sarà risposte diverse:
Parlare liberamente : SÌ. Ci sono molti (semplici) esempi in cui la mappatura è perfetta e reversibile.
A rigor di termini : NO. Vedi anche il commento @vaxquis di seguito e le vecchie risposte in questa pagina. Alcuni problemi tipici:
Si, puoi. Persino frammenti di serializzazione.
Sì, ma non così facile e veloce rispetto ai vecchi DTD ... Vedi validatori complessi, come validator.nu
Si, 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 XHTML5 può essere utilizzato.
Il problema di convalida di cui sopra riappare qui: non esiste una convenzione forte, quindi, a volte, appare meno chiarezza della "struttura standard XHTML". In quella situazione devi prestare attenzione alle "convenzioni di te stesso" ed essere coerente.
saveXML()
metodo?Sì. Questa è una situazione tipica in cui vengono utilizzate le raccomandazioni di serializzazione. L'XML sarà valido, il codice XHTML5 è mappato dallo stato HTML5 e DOM originale ... Ma, in alcune strutture, alcune informazioni possono essere perse, come commentato sopra.
Sì, sfortunatamente XHTML è sparito.
Aggiungendo 1 motivo in più alla grande risposta di MainMa:
Quando è stato creato XHTML, era destinato a essere utilizzato da WebApp per servire contenuti strutturati che sarebbero stati compresi da software non browser, che non avrebbero avuto parser HTML tag-soup. Per ScreenReaders XHTML è ancora eccezionale, ma per qualsiasi altro tipo di software, i servizi Web si adattano a tale esigenza e utilizzano principalmente XML o JSON. SOAP stesso ha un proprio schema XML, più semplice di XHTML e orientato al funzionamento.
Per quanto ne so, non esiste nemmeno 1 WebApp al mondo che offra lo stesso messaggio HTTP sia ai browser che agli 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, usando Eclipse possiamo distribuire un file di guerra univoco contenente Servlet + JSP per servire HTML, insieme ad Axis2 per servire un WebService. È semplicemente più semplice sviluppare software separati rivolti a browser e WebService che avere un software unico e complesso che serve tutti.
Il motivo principale del rifiuto di REST è esattamente la complessità (e doveva essere semplice!) Di sviluppare un server che serve lo stesso contenuto per qualsiasi tipo di client senza saperlo. Ed è anche difficile gestire la necessità del Web di evolversi rapidamente, insieme a mantenere una definizione stabile che non costringerebbe i client non browser ad essere aggiornato ogni volta che cambia un XHTML, dicendolo per mantenere valido l'XHTML quando è costruito da molti moduli diversi.
Allo stesso modo, è molto difficile sviluppare un client non browser che analizza un documento XHTML, anche se è valido, a causa di tutti quegli elementi XML che hanno lo scopo di strutturare il layout renderizzato dal browser e non di contenere il contenuto.
Se chi adotta REST si lamenta già della complessità XML di SOAP, che è SEMPRE più semplice di un XHTML per un browser, immagina quanto sia difficile gestire XHTML per più tipi di client, server e lato client.
In pratica: utilizzare HTML, come XML, se lo si desidera, per creare siti Web per browser e qualsiasi tipo di soluzione WebService per client non browser.
MA, 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 le buone prestazioni di XML.