jdev - 2026-03-05

Embedding plain HTML is practically impossible, isn't it?

HTML is not valid XML

I think that's true

You can embed XHTML, but there's XEP-0071 already for that, just extend it with whatever you need

that's what they were talking about originally

not sure when or why normal html came up

Yes of course we mean using the XML syntax in an XMPP context surely ✏

iirc <br/> is not valid html5 right?

yes it is

XHTML5 is part of the HTML5 spec

Honestly I don't even know where that spec is, I assume whatwg somewhere

The XML serialization of HTML5 isn’t entirely compatible, for instance you <script src="foo.js"/> is valid in the former but not in the latter, but as long as you provide the proper Content-Type header in HTTP it’s fine.

Oh yeah the script tag thing is a fun historical case where you never use self closing. It's still well formed XML with an explicit closing tag though and not really relevant for XHTML-IM since you don't want a script tag there anyway

I wonder why XEP-0071 was deprecated in favour of a lot less powerful (and cool) XEP-0394

> I wonder why XEP-0071 was deprecated in favour of a lot less powerful (and cool) XEP-0394 Reportedly it's because some web devs used it wrong ↺

Nevertheless it's still widely implemented

Well, it's those webdevs problem, isn't it?

Imagine if XMPP RFC would stop requiring a proper XML parser just because slicers without full XML support are a thing

It was a contentious thing at the time, and it was deprecated because the people who felt that the argument for deprecating was weak gave up, I think.

But there is a good reason for 71 being problematic, and that’s the split/duplicated content thing.

It isn't problematic in email, why would it be problematic here

It *is* problematic in email :)

Anyways, if it works for email, it sure will work for XMPP

alexkurisu, feel free to implement it, there is no xmpp police that will hunt you down

and as singpolyma said, many clients support it

<fallback> (https://xmpp.org/extensions/inbox/compatibility-fallback.html) seems pretty complicated. It has to handle an arbitrary number of potentially overlapping ranges of characters and the actual content has to be implied from the leftovers? How do people implement parsing that? Has anyone implemented it for other than for='urn:xmpp:reply:0'? https://www.isode.com/whitepaper/military-forms-using-xmpp/ sounds like they implemented <fallback> for another urn, but they would never mix fallbacks (and they're closed source now so who knows).

Yes I use it for many things

XEP-0071 needs an update btw, for some newer XHTML5 tags like `<video>` and `<audio>`

> XEP-0071 needs an update btw, for some newer XHTML5 tags like `<video>` and `<audio>` I don't think there's a reason for the xep to mention any tags ↺

> Yes I use it for many things but also within one message? different fallback namespaces for overlapping ranges? ↺

sound not that common

Also within one message sure. Never overlapping I think (except where one is for whole body and one is only part as a special case)

A reaction is also a reply and a reply can also have attached media, for two examples of two fallbacks in one message

How does Cheogram parse that? Do you have a whole Interval arithmetic class?

yeah but the rules for applying these fallbacks are not spelled out

is there some obvious rule in what order they need to be applied?

i reverse sort the ranges and snip the relevant ones last to first ✏

If they are not overlapping this will always work

because if you snip from the end then the indecies of the earlier ones are still valid

yes .. i think i do the same

and just assume nobody will send overlapping ones

Okay that's a good compromise

a whole body one is a special case that's easy to support because then you just delete the body and ignore all other fallbacks

yes i dont yet check for overlapping, but a gotcha is, validate that the ranges are not bigger than the text

> I don't think there's a reason for the xep to mention any tags There's `Recommended Profile` and `Integration Set`. Also, XEP-0071 is explicitly restricted to XHTML 1.0, while newer tags would require XHTML5

even if the client sends them correctly, a MUC can remove parts of a message, then ranges are invalid

thanks singpolyma & lovetox, I think I can work with that

>> I don't think there's a reason for the xep to mention any tags > There's `Recommended Profile` and `Integration Set`. Also, XEP-0071 is explicitly restricted to XHTML 1.0, while newer tags would require XHTML5 Yes I suggest just ignoring all that ↺

I wish the spec would explicitly say "cannot overlap", but actually it has an example showing the opposite <fallback xmlns='urn:xmpp:compat:0' for='urn:example:markup:0'> <body start='0' end='1' /> <body start='14' end='15' /> </fallback> <fallback xmlns='urn:xmpp:compat:0' for='urn:xmpp:reply:0'> <body start='0' end='33' /> </fallback> this means "snip off the whole quote and then within the quote snip off the leading '> '"

yeah .. typically XEP, give examples never somebody implemented :D

> alexkurisu, feel free to implement it, there is no xmpp police that will hunt you down I guess the issue I have with this, is yes, I can use it in my product and be fine, but if I want to (loosely) collaborate with someone else to create interoperable products they'd very reasonably say to avoid deprecated parts of the standard and do formating some other way. Meanwhile, some parts of the ecosystem (like the part singpolyma's in) use it freely, and I assume don't want to deprecate it from their software. It's confusing, which is why I originally asked if depreciation was still appropriate. ↺

Examples are not normative but that one should either be changed or the xep shild suggest wtf it should do

either way, you dont need to be perfect here, start with things actually happening in the wild, you can always improve on the algo later

singpolyma, Examples aren't explicitly noted as normative or not in XEPs.

>> alexkurisu, feel free to implement it, there is no xmpp police that will hunt you down > > I guess the issue I have with this, is yes, I can use it in my product and be fine, but if I want to (loosely) collaborate with someone else to create interoperable products they'd very reasonably say to avoid deprecated parts of the standard and do formating some other way. Meanwhile, some parts of the ecosystem (like the part singpolyma's in) use it freely, and I assume don't want to deprecate it from their software. It's confusing, which is why I originally asked if depreciation was still appropriate. In my role on council I have brought up un deprecating but at least one council member feels strongly the opposite and we need unanimous votes ↺

singpolyma, You do not need unanimous votes.

singpolyma, Only for taking a protoXEP as a XEP, that's the only case with a veto.

Sorry I forget the word for "unanimous except for abstentions"

singpolyma, ignoring a huge part of XEP-0071 would basically result in me implementing a separate custom XMPP extension, since i would have to bump namespace

singpolyma, No, you just need a majority.

> singpolyma, ignoring a huge part of XEP-0071 would basically result in me implementing a separate custom XMPP extension, since i would have to bump namespace No ↺

Yeah, seems we haven't reached a consensus. Maybe in the future we will or some new idea will come along.

> singpolyma, No, you just need a majority. Really? I was specifically told all council votes are vetoes ↺

singpolyma, Well, I'd have to check if we actually have a formal pah for un-deprecating, but in principle, if we do, it'd just need a majority.

singpolyma, Not what XEP-0001 says (intentionally, too).

I'll go read xep1 again some time

> No > Until and unless (1) additional integration sets are defined and (2) mechanisms are specified for discovering or negotiating which integration sets are supported, the XHTML markup contained within the <html/> wrapper element: > > MUST NOT include elements and attributes that are not part of the XHTML-IM Integration Set defined in Section 6 of this document; any such elements and attributes MUST be ignored if received. XEP-0071 disagrees

The xep is deprecated otherwise we could change what it says :P

Section 6 has the bit about vetoing, as does section 9 (I'd forgotten that case - approval for advancement).

just do the obvious thing

The sensible thing to do would be to produce a new protoXEP, if you wanted to go that route, that used the same namespace, and described how to make it safe. When XHTML-IM was deprecated, I did write (and say) a lot of words about how this wasn't a ban of any HTML inside XMPP, but just deprecating the use of it for messaging.

was the above language about the integration set a preliminary attempt to make it safe?

well I found the xhtml5 spec but I can't say it's promising https://html.spec.whatwg.org/multipage/xhtml.html#xhtml

> WARNING! Using the XML syntax is not recommended, for reasons which include the fact that there is no specification which defines the rules for how an XML parser must map a string of bytes or characters into a Document object, as well as the fact that the XML syntax is essentially unmaintained — in that, it’s not expected that any further features will ever be added to the XML syntax (even when such features have been added to the HTML syntax).

doesn't seem like something that should be used for new dev work?

you could always use XEP-0481 and send HTML as text, it just looks ugly and wouldn't be compatible with existing XHTML-IM clients

> doesn't seem like something that should be used for new dev work? the "no new features" thing is hilarious because of course not? Unless XML changes syntax or something there's nothing to add anyway ↺

Also if you want u can ignore that section and notice that in the html syntax section we have > Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/)

ie yes <br/> is valid HTML syntax

what's the advantage of being the only people trying to use xhtml5 vs just cramming html5 in CDATA ?

Then you would need an html parser for no reason. Makes everything more complicated. We're also not the only ones. Atom for example also uses XML syntax for html

HTML5 is of a greater complexity too

Greater complexity than what?

previous versions of HTML perhaps?

Maybe. It's not significantly different IMO except that the parsing algorithm is more comprehensive but sure