Hacker News new | past | comments | ask | show | jobs | submit login

This page is delivered with the media type of text/html, not application/xhtml+xml. So it's not even using XHTML.



Wasn't there some issue with IE or something that prevented people from using the right mime type? I swear there was something like that going on back in the day.

edit: yep https://flask.palletsprojects.com/en/2.1.x/htmlfaq/


Do MIME types in HTTP headers affect how browsers render content? As far as I know most static web servers simply have a mapping between file extensions and MIME types that they send for response headers and that it's up to the DOCTYPE and quirks of the browser to determine how the page itself is rendered. Since this page's DOCTYPE is...

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

...I'd say it absolutely is XHTML (assuming that it reasonably validates as such, i.e. closes all tags and so forth). Have things changed recently in this regard?


> Do MIME types in HTTP headers affect how browsers render content?

They absolutely do matter. To make an extreme point, if that page was served as text/plain, then the browser would show the literal XHTML source code on screen. Auto-sniffing the type based on the content is a big no-no where we learned lessons about vulnerabilities like ~20 years ago.

The text/html and application/xhtml+xml modes have many subtly different behaviors. XHTML supports things like <![CDATA[ ... ]]> and requires namespaces like <html xmlns="http://www.w3.org/1999/xhtml">, <svg xmlns="http://www.w3.org/2000/svg">. XHTML requires well-formed elements, so no <b><i></b></i>. XHTML treats <div/> as identical to <div></div>, whereas HTML5 interprets it as just <div> with no closing.

Here is my guide on XHTML, and the page itself and entire website is served as application/xhtml+xml: https://www.nayuki.io/page/practical-guide-to-xhtml


Small error in that sample script:

    let elem = document.createElement("img");
    console.log(el.tagName); // el is not defined


> Do MIME types in HTTP headers affect how browsers render content?

You can test it with the following snippet:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head><title>test</title></head>
    <body>
    <h1 style="color:green"><span style="color:red" />If this text is green, this file was parsed as XHTML</h1>
    </body>
    </html>
With Content-Type set to "text/html" the text will be red, with "application/xhtml+xml" it will be green.


The rendering differences in modern browsers are actually way more lenient. By the spec: If it’s served from DISK with that header, it’ll be rendered as XHTML, with the accordant failures. If it’s served from web, and has a Content-Type, this overrides DOCTYPE. (Ex, if you wanted to show it as text…) This will cause the page to be rendered in “quirks mode” in older browsers, or as a standard HTML page in modern browsers. application/xhtml+xml is as different from text/html as text/plain, and they all absolutely change the rendering pipeline — or should.

The difference in rendering lies in invalid XML documents — if you skip a closing tag in XHTML, the page should error and REFUSE TO RENDER. At all. Just display an error message to the end user. If your webpage doesn’t do this when it doesn’t have matching tags, it is not being rendered as XHTML by the spec.


It's the web server that happens to be configured to return the mime type text/html, not the document, which is clearly labeled and formatted as proper XHTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">


Nevertheless, it’s going to be rendered as an HTML document by the browser (with an invalid doctype) — the web server told it to!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: