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

2023-06-15 Thread Lennart Jablonka
Quoth Thorsten Glaser: Handling XHTML approximately by treating it as HTML-syntax HTML may be useful in stead of refusing to handle XHTML, but that is not implementing XHTML. Yes, but the onus is on the *server* to provide the data in a format the client can handle because native XHTML-as-XML

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

2023-06-15 Thread Lennart Jablonka
Quoth Thorsten Glaser: There’s HTML-compatible XHTML, which you can serve as text/html, and there’s nōn-HTML-compatible XHTML, which you must serve as application/xhtml+xml, yes and if you expect to serve websites you may serve the latter only if explicitly requested by the browser because

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

2023-06-15 Thread Lennart Jablonka
Quoth Thorsten Glaser: Nope: HTTP_ACCEPT='text/html, text/plain, text/sgml, text/css, */*;q=0.01' Indeed. I was using an older version of lynx. It seems v2-9-0dev_0l regressed in dropping application/xhtml+xml from Accept. That’s a consequence of: --- a/src/HTInit.c +++

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

2023-06-12 Thread 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

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

2023-06-12 Thread Lennart Jablonka
Quoth Thorsten Glaser: Your file is well-formed XML, but neither valid for webbrowsers (due to the omission of the space before “/>” self-closing tags) nor actually valid for any XHTML DTD because you self-close tags that MUST NOT be self-closed. And here I thought that all of XHTML 1.0, XHTML

[Lynx-dev] [PATCH] accept

2023-04-15 Thread Lennart Jablonka
Some XHTML pages declared as using UTF-8 are erroneously taken to be non-UTF-8. The syntax for encoding declarations allows the use of either ' or " for the encoding name. Further, the spec says that the encoding name should be parsed case-insensitively. See