attribute - Tipo de contenido para fragmentos HTML
title html attribute (3)
En lo que respecta a los fragmentos de documentos XML / HTML, aparte del w3.org/TR/xml-fragment referencia en los comentarios (ahora etiquetados como "ya no se mantiene"), no parece haber ninguna referencia explícita y oficial a los fragmentos de documentos y al encabezado de tipo de contenido . Sin embargo, algunos puntos a considerar:
La especificación de fragmentos xml trata los documentos completos y los fragmentos de la misma manera con respecto al tipo de
Content-Type.La documentación de MDN sobre tipos MIME no hace distinción entre documentos completos y fragmentos ( énfasis agregado):
Todo el contenido HTML debe ser servido con este tipo. Los tipos MIME alternativos para XHTML (como application / xml + html) son en su mayoría inútiles en la actualidad (HTML5 unificó estos formatos).
La especificación W3 8.4 Análisis de fragmentos HTML expone explícitamente los casos para manejar un fragmento de documento HTML. A menos que el analizador falle (llegue a un error del analizador), asume que la cadena dada es HTML. Además, los navegadores reciben un HTML inválido / parcial con mucha frecuencia, y se procesa en la mayor medida posible (en oposición a una falla correcta).
Las etiquetas mínimas requeridas para un documento HTML nulo completo son:
- El DOCTYPE:
<!DOCTYPE html>- declara el modo de documento, en particular la especificación los requiere " por razones heredadas " - El título:
<title>My Page</title>
La omisión de estos elementos requeridos no cambia la naturaleza del contenido. En un sentido práctico,
<p>hello worldse sigue interpretando casi universalmente como HTML, simplemente no es un documento válido.- El DOCTYPE:
El estándar RFC que define los tipos MIME solo define explícitamente
text/plain, aunque la especificación del encabezado RFCContent-Typereferencia atext/html. Obviamente, esto no proporciona una guía clara, pero tampoco define alternativas posibles.
Dado que la única referencia relevante del W3 indica que los documentos y los fragmentos XML completos se tratan de la misma manera (y HTML es un subconjunto de XML), el algoritmo de análisis de fragmentos W3 no hace una distinción (y supone que recibe HTML), MDN desaconseja el uso De todos los encabezados alternativos, y no hay alternativas ampliamente aceptadas (ni siquiera notables), el uso de text/html para fragmentos de documentos sería la opción clara. No pude encontrar ningún precedente para sugerir lo contrario, y el uso de algún tipo MIME personalizado probablemente causaría confusión (o peor).
Si realmente desea hacer una distinción en su aplicación entre documentos completos y fragmentos, puede envolverla en JSON o enviar un encabezado personalizado adicional desde su servidor (no pude encontrar referencias a ninguna práctica común con respecto a esto, y podría solo se confuso a otros desarrolladores).
Cuando un servidor envía una respuesta HTTP con un documento HTML en el cuerpo, usualmente usará el tipo de contenido de text/html . ¿El tipo de contenido debería ser diferente si la respuesta es un fragmento de HTML?
Por ejemplo, si la solicitud es AJAX de un script de cliente y el cuerpo de la respuesta completa es <div><p>New text</p></div> entonces la respuesta no es un documento HTML. ¿Debería la aplicación establecer el tipo de contenido en algo distinto al text/html para dichos fragmentos? ¿Entonces qué?
Es una preferencia personal. Si es solo tu aplicación, entonces no importa. Lo mantendría en text/html porque aún es una marca HTML, incluso si no es un documento completo.
Sí, también estoy en una solución para esto. Pero está perfectamente bien crear sus propios encabezados HTTP si no está completamente satisfecho con la asignación de uno existente a su caso de uso. En esa dirección, http://tools.ietf.org/html/rfc6648 "X-" encabezados basados ahora están en desuso. Básicamente, siempre que elijas un tipo mime suficientemente único y significativo, eres libre de inventar el tuyo. Pero como @Wrikken mencionó en su comentario, eso podría ser problemático. Por lo tanto, para evitar todo esto, puede retroceder en texto / html O hacerlo a través de una forma JSON, y no de una forma <div> . En un mundo ideal y escalable, el lado del servidor debe quedar libre de la creación de HTML / DIV