15 Mar
2026
15 Mar
'26
12:03 p.m.
Hi,
On Sun, 2026-03-15 at 12:43 +0000, Stephen Paul Weber wrote:
I was referring to the well-maintained HTML syntax of HTML5, not the
XML syntex. As HTML syntax is not fully compatible with XML, it can't
be transferred as XML and thus would need to be transferred as text.
The warnings about XML serialization hardly seem
relevant
How is "Using the XML syntax is not recommended [...] the XML syntax is
essentially unmaintained" not relevant?
If browsers didn't support it at all anymore that
would actually be a
possible benefit.
I don't care about browsers, I care about rendering engines. Because
you will need one if you want to support XHTML. And even a reasonably
correct implementation of XHTML-IM would require essentially a full
HTML rendering engine.
Other XML native contexts also use the XML syntax, eg
Atom, we are
not alone here.
Atom can do both, XHTML and HTML. They also did not define a "safe"
subset of XHTML either.
use XEP-0481
to transfer HTML5.
I think encoding something with a XML syntax as text for transmission
in an XML native context would be a great tragedy and also require including an HTML parser, very
inconvenient.
As I wrote above, you very likely will need an HTML renderer to render
the (X)HTML anyways and most HTML renderers come with HTML parsers
already and in fact the easiest way to pass the HTML would probably be
to pass it to the renderer verbatim instead of parsing it first and
passing it in some parsed form.
Just to be clear, I'm not arguing in favor of Markdown or XEP-0393 for
the IM usecase, but rather in favor of XEP-0394, which is actually
easier to parse and process for many text rendering engines (e.g.
somewhat matches Android's Spanned, Pango's AttrList or Apple's
AttributedString).
In contrast, some XEP-0071 implementations in the wild (or those that
want to be) take the XHTML body node, serialize it into a string and
then have that string processed by some HTML parser which (of course
does not implement XHTML-IM and) turns it into the above or similar
formats for their text rendering engine. I fail to see how that is
better.
And for Atom and similar usecases that want more full-featured
documents, our best bet is probaly just to use HTML5. I would suggest
using the HTML syntax here, just because that's the one more widely
supported and because transferring as text rather than XML nodes is
likely easier when passing the text to an HTML engine anyways, but in
the end XML probably works just as fine.
Marvin