Re: Reinstating XHTML-IM (XEP-0071)
"Marvin W. via Standards" <[email protected]> Mon, 16 Mar 2026 00:03:56 +0800
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <[email protected]> |
Hi, On Sun, 2026-03-15 at 12:43 +0000, Stephen Paul Weber wrote: > 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 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. > 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 _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]