Re: lynx misrenders many *IN*valid xhtml5 pages on my site

Quoth Thorsten Glaser:
>Lennart Jablonka dixit:
>
>> And here I thought that all of XHTML 1.0, XHTML 1.1, HTML5 XML syntax, and
>> WHATWG HTML XML syntax defer parsing to the XML processor.
>
>As usual, it depends.
>
>Iff the browser requests XHTML served as XML, that is, if the browser
>sends an HTTP Accept header that contains application/xhtml+xml

as is the case for lynx

>(and
>probably contains that before text/html if both are given), then the
>server may send the document as XML, skipping the space before “/>”.

That is what happens here.  (Also, I’m under the impression that 
content negotiation à la Accept is entirely optional—the server is 
free to ignore Accept; what matters to the client is just the 
returned Content-Type.  Per HTTP, at least: ignoring the strange 
HTML rules for Media type sniffing.)

>I’m not sure whether it may then also self-close all tags but would
>assume so (except I know tech is… tricky).

As in an XML document, <asdf/> and <asdf></asdf> are entirely 
equivalent, yes, the server may then “self-close” all empty 
elements.

>If however the browser does not send that header, the document must be
>served in compatibility mode,

It might be smart to do, but is not a requirement, is it?  
A server sending an XHTML document as application/xhtml+xml, not 
in any way stating that it is valid HTML syntax, need not restrict 
the XML syntax, does it?

>in particular the self-closing tags thing
>(if you self-close <textarea/>, even Firefox croaks and dies), but also
>a compatibility space before “/>” for best effect.
>
>(And yes, XHTML, despite later changes to the HTTP docs, may be served
>as text/html, but only under these caveats; the XHTML spec supports
>this.)

This is the one case for which the space and the separate end tag 
are required.

>tl;dr it’s a mess…

It for sure is.