Re: [Lynx-dev] lynx misrenders many *IN*valid xhtml5 pages on my site

[Lennart Jablonka]

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.