¿Debo escribir documentos HTML5 de Polyglot?

Question

He estado considerando la conversión de mis documentos HTML5 actuales a HTML5 políglotas. Me imagino que incluso si solo se sirven como text/html, las verificaciones adicionales de escribirlo en XML ayudarían a mantener mis hábitos de codificación ordenados y válidos.

¿Hay algo particularmente emocionante en el espacio de solo HTML5 que haría de esta una elección imprudente?

En segundo lugar, las especificaciones son un poco confusas sobre cómo validar un documento políglota. Asumo que los fundamentos son:

1. No hay errores cuando se ejecuta a través de la W3C Validador como HTML5
2. No hay errores cuando se ejecutan a través de un analizador XML

Pero ¿hay otras reglas que me faltan?

En tercer lugar, ya que es un políglota, ¿alguien sabe alguna advertencias para servir como application/xhtml+xml a los navegadores de apoyo y text/html a los no-apoyo?

Editar: Después de un poco de experimentación, encontré que entidades como   se rompen en XHTML5 (sin DTD). Ese analizador XML es un arma de doble filo, creo que ya he respondido mi tercera pregunta.

Answer 1

Trabajar para definir cómo crear documentos políglotas HTML5 está actualmente en curso, pero vea http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html para obtener un borrador inicial. Sin duda es posible hacerlo, pero requiere una gran cantidad de disciplina de codificación, y tendrá que decidir si vale la pena el esfuerzo. A pesar de que creo documentos HTMLLogglot HTML4.01/XHTML1.0, los creo usando una cadena de herramientas XML que garantiza la buena formación de XML y un código especializado para garantizar la compatibilidad con elementos HTML no válidos y caracteres XML válidos. La codificación manual directa sería muy difícil.

Un problema actual conocido en HTML5 es el atributo srcdoc en el elemento iframe. Debido a que el valor del atributo contiene marcado, ciertos caracteres deben ser escapados. El borrador de la especificación HTML5 describe cómo hacer esto para la serialización HTML, pero no (la última vez que lo busqué) cómo hacerlo en la serialización XHTML.

Answer 2

Esto suena como algo muy difícil de hacer. Una de las fallas de XHTML fue que no fue posible dirigir con éxito entre las demandas competitivas de XML y HTML vintage.

Creo que si escribe HTML5 y lo valida con éxito, tendrá un documento tan ordenado y válido como sea necesario.

Answer 3

Dado que la documentación del W3C sobre las diferencias entre HTML y XHTML ni siquiera está terminada, probablemente no valga la pena intentar hacer polyglot. Todavía no de todos modos ... dale otro par de años.

En cualquier caso, solo en las circunstancias extremadamente limitadas en las que está planeando analizar su HTML como XML para algún propósito específico, debería invertir el tiempo adicional en cumplimiento de XML. No hay beneficios de hacerlo exclusivamente para el consumo de los navegadores web, solo inconvenientes.

Answer 4

Este wiki tiene alguna información no está presente en el documento del W3C: http://wiki.whatwg.org/wiki/HTML_vs._XHTML

Answer 5

llego tarde a la fiesta, pero después de 5 años, la pregunta sigue siendo relevante. Por un lado, cerrar todas mis etiquetas me atrae mucho. Para las personas que lo leen, para una edición más sencilla, para Great Justice. OTOH, mirando los detalles sangrientos de la especificación políglota - http://www.sitepoint.com/have-you-considered-polyglot-markup/ tiene un resumen conveniente al final - está claro para mí no puedo obtenerlo todo a mano.

https://developer.mozilla.org/en/docs/Writing_JavaScript_for_XHTML arroja también luz sobre por qué XHTML falló: la elección misma de usar el tipo MIME XML tiene varios efectos secundarios en el momento de ejecución . En este momento, debe ser una rutina para un buen código JS manejar estos (por ejemplo, nombres de etiquetas siempre minúsculas antes de comparar), pero no quiero todo eso. Hay suficientes problemas entre navegadores para probarlos tal como están, gracias.

así que creo que es un camino intermedio útil:

1. Por ahora sólo sirven como text/html. Deja de preocuparte de que realmente analizará exactamente el mismo DOM con el mismo comportamiento de tiempo de ejecución en los modos HTML y XML.

2. Sólo se esfuerzan que analiza como algunos XML bien formado. Ayuda a los lectores, ayuda a los editores, me permite usar el analizador XML en mis propios documentos.

   Desafortunadamente, herramientas políglotas son raros de inexistente - que es difícil incluso serializar volver XML de una manera que también pasa los requisitos HTML ...

   • obviedad: siempre auto etiquetas de cierre de huecos (<hr/>) y separa por separado las etiquetas no válidas (<script ...></script>).

   • No hay que pensarlo: utilizar etiquetas minúsculas y attr (excepto algunos SVG pero el contenido externo usa reglas XML de todos modos), siempre hay que indicar los valores de atributos, siempre proporcionan valores de atributos (selected="selected" es más detallado de lo Stanalone selected pero puedo vivir con eso) .

   • En línea <script> y <style> son las más molestas. No puedo usar & o < dentro sin romper el análisis de XML. Necesito:

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

   ... y eso es todo! Sin preocuparse por los espacios de nombres XML o el DOM implícito de HTML correspondiente para las tablas, se reduce la mitad de las reglas :-)

3. Esperando un futuro cuando puedo ir directamente a la creación de XHTML, omitiendo la políglota. Los beneficios son que podré olvidarme de las limitaciones de cierre de etiquetas, podré consumir directamente y producir con herramientas XML. Claro, descuidar los espacios de nombres xml y otras cosas ahora hará que el cambio sea más difícil, pero creo que crearé más nuevos documentos en este futuro que convertir los existentes.

   En realidad, no estoy del todo seguro de lo que me impide vivir en ese futuro en este momento. ¿Es solo IE 8? También estoy un poco preocupado por el manejo de errores de todo o nada. Estoy esperando que una futura especificación HTML encuentre una forma de reducir las brechas HTML vs. XML, p. haga que los navegadores acepten <hr></hr> y <script .../> en HTML, mientras aún retienen el manejo de errores HTML.

   Además, herramientas.Tener bibliotecas en muchos idiomas que puedan serializar a marcas políglotas lo haría factible para que los programas lo generen. Tener herramientas para validar y convertir HTML5 < -> polyglot < -> XHTML5 ayudaría. De lo contrario, está bastante condenado.

Answer 6

¿Lo debería usted? Sí. Pero primero algunas aclaraciones sobre un par de puntos.

Enviando el encabezado Content-Type: application/xhtml+xml solo significa que debe ir a través de un analizador XML, todavía tiene todos los beneficios de HTML5 hasta donde yo sé.
Acerca de  , que no está definido en XML, las únicas referencias de entidades de caracteres que XML define son lt, gt, apos, quot y amp, necesitará usar referencias de caracteres numéricos para cualquier otra cosa. El código para nbsp es   o  , personalmente prefiero hexadecimal porque los puntos de código Unicode se representan de esa manera (U + 00A0).

Enviar el encabezado es útil para probar porque puede encontrar problemas rápidamente con su marcado como etiquetas no cerradas, etiquetas de finalización, texto que podría interpretarse como una etiqueta, etc., básicamente cosas que pueden romper el aspecto o incluso la funcionalidad de su sitio.
Más importante en mi opinión, es que si permite la entrada del usuario y no puede analizar, eso generalmente significa que no escapó de sus datos y se está exponiendo a una vulnerabilidad. Analizado como HTML, es posible que nunca note un problema hasta que alguien comience a inyectar scripts para hostigar a sus usuarios o robar datos.

Esta página es bastante bueno sobre explicando qué es marcado políglota: (ahora HTML5 es una recomendación) https://blog.whatwg.org/xhtml5-in-a-nutshell