Menu
The text/html content type is an Internet Media Type as well as a Multipurpose Internet Mail Extensions (MIME) content type. Using HTML in MIME messages allows the full richness of Web pages to be available in e-mail.
The Content-Type representation header is used to indicate the original media type of the resource (prior to any content encoding applied for sending). In responses, a Content-Type header provides the client with the actual content type of the returned content.
In regards to XML/HTML document fragments, other than the xml-fragment referenced in the comments (now labeled as "no longer maintained"), there don't appear to be any explicit, official references to document fragments and the content type header. However, some points to consider:
The xml-fragment spec treats full documents and fragments the same in regards to the Content-Type.
The MDN documentation on MIME Types makes no distinction between full documents and fragments (emphasis added):
All HTML content should be served with this type. Alternative MIME types for XHTML (like application/xml+html) are mostly useless nowadays (HTML5 unified these formats).
The W3 spec 8.4 Parsing HTML Fragments explicitly lays out cases for handling an HTML document fragment. Unless the parser fails (hits a parser error), it assumes the string given is HTML. Furthermore, invalid/partial HTML is received by browsers extremely frequently, and is rendered to the fullest extent possible (as opposed to out right failing).
The minimum tags required for a full void HTML document are:
<!DOCTYPE html> - declares the document mode, notably the spec requires them "for legacy reasons"<title>My Page</title>
Omission of the these required elements does not change the nature of the content. In a practical sense, <p>hello world is still nearly-universally interpreted to as HTML, it is just not a valid document.
The RFC standard defining MIME types only explicitly defines text/plain, although the RFC Content-Type header spec references text/html. This obviously provides no clear guidance, but also defines no possible alternatives.
Given the only relevant reference from the W3 states full XML documents and fragments be treated the same (and HTML is subset of XML), the W3 fragment parsing algorithm does not make a distinction (and assumes it's receiving HTML), MDN advises against the usage of any alternative headers, and there's no widely accepted (or really even any notable) alternatives, using text/html for document fragments would be the clear choice. I could find no precedent to suggest otherwise, and using some custom MIME type would probably just cause confusion (or worse).
If you really wanted to make a distinction in your application between full documents and fragments, you could wrap it in JSON, or send an additional custom header from your server (I could find no references to any common practice in regards to this, and may just be confusing to other devs).
It's a personal preference. If it is only your app, then it doesn't matter. I would keep it text/html because it is still HTML markup, even if not a complete document.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With