> *So, it would be valid for some rendering engines to implicitly closes the par...

vbezhenar · on Dec 10, 2020

I think XHTML allows to put anything inside anything. Not sure if it's legible, but DOM will be nested properly.

chrismorgan · on Dec 11, 2020

On the contrary, XHTML was stricter. If you put an element where it’s not supposed to be, the whole document would (probably?) not render.

But the point is moot: XHTML is completely dead, lacks newer HTML elements like <details>, and no browser includes an XHTML parser anyway—they’ll use the HTML parser.

vbezhenar · on Dec 11, 2020

I don't think you're correct about that.

Here's simple test.xhtml:

    <!DOCTYPE html>
    <html xmlns="http://www.w3.org/1999/xhtml" lang="en">
      <head>
        <meta charset="UTF-8"/>
        <title>XHTML</title>
      </head>
      <body>
        <p>
          <details>
            <summary>Summary</summary>
            Details
          </details>
        </p>
      </body>
    </html>

It's rendered properly in Chrome. If some XML is wrong, it'll error. So at least Chrome supports XHTML with strict XML validator. And <detail> tag works as expected and it's even nested inside <p> tag in DOM.

That XHTML won't pass validator.w3.org (<details> can't be inside <p>), but Chrome does not care.

chrismorgan · on Dec 11, 2020

Huh, I thought the XML serialisation of HTML had been evicted from all the browsers, but you’re right, and Firefox behaves the same way. https://html.spec.whatwg.org/#html-vs-xhtml describes briefly what is expected to occur (though that section is non-normative). Also given that I know that browsers can successfully load XML documents with XSLT (I’ve seen one or two web pages that actually do this), and that I know that the XML parser is accessible via DOMParser (this can be useful for some kinds of markup sanitisation), I’m not sure why I thought XHTML was completely dead in this way. Something’s niggling at the back of my mind, but I can’t place it.

I believe browsers would be quite within their rights to do DTD validation and consequently reject such a document as this, but they don’t actually do so. (Even if the DTD is specified correctly for XHTML 1.0 Strict, nothing changes.)

Thanks for correcting me. I have updated my mental knowledge repository.

ttepasse · on Dec 13, 2020

> I’m not sure why I thought XHTML was completely dead in this way. Something’s niggling at the back of my mind, but I can’t place it.

Browsers were always non-validating XML processors. Maybe you're thinking about the Well-formedness constraints? These constraints check if an XML document follows the XML metasyntax and any XML processor is required to fail [1] on errors in these contraints. And browsers do that.

[1] https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-conforman...

In practice most well-formedness violations were nesting errors like missing start or end tags, common when generating XML via text concatenation or templates, which in the dark times a lot of people do, even when they shouldn't . [2] That's why the HTML5 parsing algorithm is so complex and almost unimplementable. It's the ambition for error correction: It tries to generate a DOM out of any well-formed and unwell-formed documents.

[2] https://hsivonen.fi/producing-xml/#nottext