Devo scrivere documenti HTML5 Polyglot?

Question

Ho preso in considerazione la conversione dei miei documenti HTML5 correnti in poliglotta HTML5. Immagino che anche se venissero serviti solo come text/html, i controlli extra sulla scrittura di XML aiuterebbero a mantenere le mie abitudini di codifica in ordine e valide.

C'è qualcosa di particolarmente eccitante nello spazio solo HTML5 che renderebbe questa scelta poco saggia?

In secondo luogo, le specifiche sono un po 'confuse su come convalidare un documento poliglotta. Presumo le basi sono:

1. Nessun errore quando viene eseguito attraverso il W3C Validator come HTML5
2. Nessun errore quando attraversano un parser XML

Ma ci sono altre regole mi manca?

In terzo luogo, visto che si è un poliglotta, qualcuno sa ogni limitazione a servire come application/xhtml+xml ai browser di sostegno e text/html a quelli non-portante?

Edit: Dopo un po 'piccolo di sperimentare ho scoperto che le entità come   pausa nel XHTML5 (senza DTD). Quel parser XML è un po 'un'arma a doppio taglio, credo di aver già risposto alla mia terza domanda.

Answer 1

I lavori per definire come creare documenti HTML5 poliglotta sono attualmente in corso, ma vedere http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html per una bozza iniziale. È certamente possibile farlo, ma richiede una buona dose di disciplina di codifica e dovrai decidere se ne vale la pena. Sebbene creo documenti poliglotta HTML4.01/XHTML1.0, li creo utilizzando una catena di strumenti XML che garantisce la ben formata XML e un codice specializzato per garantire la compatibilità con elementi non vuoti HTML e caratteri XML validi. La codifica diretta delle mani sarebbe molto difficile.

Un problema corrente noto in HTML5 è l'attributo srcdoc sull'elemento iframe. Poiché il valore dell'attributo contiene markup, alcuni caratteri devono essere sottoposti a escape. Le specifiche del draft HTML5 descrivono come eseguire questa operazione per la serializzazione HTML, ma non (l'ultima volta che ho guardato) come farlo nella serializzazione XHTML.

Answer 2

Questa sembra una cosa molto difficile da fare. Una delle carenze di XHTML era che non era possibile governare con successo tra le richieste concorrenti di XML e HTML vintage.

Penso che se si scrive HTML5 e lo si convalida correttamente, si avrà un documento ordinato e valido come chiunque avrebbe bisogno.

Answer 3

Dato che la documentazione del W3C sulle differenze tra HTML e XHTML non è ancora finita, probabilmente non vale la pena dedicare del tempo a provare a fare poliglotta. Non ancora comunque ... dagli un altro paio di anni.

In ogni caso, solo nelle circostanze estremamente strette in cui si sta pianificando attivamente l'analisi del codice HTML come XML per uno scopo specifico, si dovrebbe investire il tempo supplementare in conformità XML. Non ci sono vantaggi di farlo esclusivamente per il consumo da parte dei browser Web - solo svantaggi.

Answer 4

Questo wiki ha alcune informazioni non presenti nel documento del W3C: http://wiki.whatwg.org/wiki/HTML_vs._XHTML

Answer 5

Sono in ritardo alla festa, ma dopo 5 anni la questione è ancora rilevante. Da un lato la chiusura di tutti i miei tag mi attrae fortemente. Per le persone che lo leggono, per un editing più semplice, per Great Justice. OTOH, guardando i dettagli cruenti della spec poliglotta - http://www.sitepoint.com/have-you-considered-polyglot-markup/ ha un sommario conveniente alla fine - mi è chiaro che non riesco a trovarlo tutto a destra a mano.

https://developer.mozilla.org/en/docs/Writing_JavaScript_for_XHTML fa luce anche interessante sul perché XHTML fallito: la scelta molto da usare tipo MIME XML ha diversi effetti collaterali in fase di run . Ormai dovrebbe essere di routine che un buon codice JS gestisca questi (ad esempio nomi di tag sempre in minuscolo prima di compararli) ma non voglio tutto questo. Ci sono abbastanza problemi tra browser per testare così com'è, grazie.

Quindi penso che ci sia una via di mezzo utile:

1. Per ora servono solo come text/html. Smettere di preoccuparsi che in realtà analizzerà esattamente lo stesso DOM con lo stesso comportamento di runtime in entrambe le modalità HTML e XML.

2. Solo sforzano che analizza come alcuni XML ben formato. Aiuta i lettori, aiuta gli editor, mi permette di usare parser XML sui miei documenti.

   Purtroppo, gli strumenti poliglotti sono rari da inesistente - è difficile per serializzare anche indietro XML in un modo che passa anche i requisiti HTML ...

   • No brainer: sempre auto tag di chiusura void (<hr/>) e separare separatamente i tag non vuoto (<script ...></script>).

   • Nessun brainers: utilizzare i tag minuscole e attr (ad eccezione di alcuni SVG ma il contenuto esterno utilizza regole XML in ogni caso) i valori, sempre citando attribuire, sempre di fornire i valori degli attributi (selected="selected" è più verboso di stanalone selected ma posso vivere con questo) .

   • Inline <script> e <style> sono più fastidiosi. Non riesco a utilizzare & o < all'interno senza interrompere l'analisi XML. Ho bisogno:

     <script>/*<![CDATA[*/ 
         foo < bar && bar < baz; 
     /*]]>*/</script> 
     

   ... e questo è tutto! Non preoccuparsi namespace XML o corrispondenza DOM implicita di HTML per le tabelle scende circa la metà delle regole :-)

3. attendono un futuro quando posso andare direttamente authoring XHTML, saltando polyglotness. I vantaggi sono che potrò dimenticare i limiti di chiusura del tag, sarà in grado di consumare direttamente e produrre con strumenti XML. Certo, trascurando gli spazi dei nomi xml e altre cose ora renderà il passaggio più difficile, ma penso che creerò più nuovi documenti in questo futuro rispetto a quelli esistenti.

   In realtà non sono del tutto sicuro di cosa mi impedisca di vivere in quel futuro in questo momento. È solo IE 8? Sono anche un po 'preoccupato per la gestione degli errori tutto o niente. Sto sperando che una futura specifica HTML possa trovare un modo per ridurre gli spazi vuoti tra HTML e XML, ad es. fai in modo che i browser accettino <hr></hr> e <script .../> in HTML, pur mantenendo la gestione degli errori HTML.

   Inoltre, strumenti.Avere librerie in molte lingue che possono essere serializzate in un markup di polyglot renderebbe fattibile per i programmi generarli. Avere gli strumenti per convalidare e convertire HTML5 < -> Polyglot < -> XHTML5 aiuterebbe. Altrimenti, è praticamente condannato.

Answer 6

In caso affermativo? Sì. Ma prima alcuni chiarimenti su un paio di punti.

L'invio dell'intestazione Content-Type: application/xhtml+xml significa solo che deve passare attraverso un parser XML, ma ha ancora tutti i vantaggi di HTML5 per quanto ne so.
proposito  , che non è definito in XML, l'unica entità carattere definisce i riferimenti XML sono lt, gt, APOS, quot, e amplificatore, sarà necessario utilizzare riferimenti a caratteri numerici per niente altro. Il codice per nbsp è   o  , personalmente preferisco esagono perché punti di codice unicode sono rappresentati in questo modo (U + 00A0).

L'invio di testa che utile per i test perché è possibile trovare rapidamente i problemi con il tuo markup come i tag non chiusi, tag finali randagi, testo che potrebbe essere interpretato come un tag, ecc, in pratica roba che può rompere l'aspetto o anche funzionalità del tuo sito.
Ancor più significativo, a mio parere, è se si consente l'input dell'utente e non riesce ad analizzare, questo significa che in genere non si sfuggì loro dati e sta lasciando soli aperta a una vulnerabilità. Analizzato come HTML, potresti non notare alcun problema fino a quando qualcuno non inizia a iniettare script per molestare i tuoi utenti o rubare dati.

Questa pagina è abbastanza buono a spiegare ciò che il markup è poliglotta: (! Ora HTML5 è una raccomandazione) https://blog.whatwg.org/xhtml5-in-a-nutshell