[Standards] Need sanity check on an example in XEP-0393: Message Styling

Tedd Sterr teddsterr at outlook.com
Sat Nov 7 16:57:01 UTC 2020

I'd actually be tempted just to change it to explicitly format sequential runs of the same directive, and remove the intervening text requirement - i.e. {***********}, which is how I'd expect it to appear as a user.
It clears everything up nicely, and apparently no implementations have taken notice of that anyway.

After a long and productive conversation with Ted, I think I have a
better understanding of this situation and the answer is that it's just
underspecified and there are multiple valid interpretations of "***" and
"****" depending on how you build your parser (though I would still very
much love to get other opinions).

This is not likely to matter in the real world, but it's also not ideal.
I've written implementations that work both ways, so I wanted to see
what existing implementations do, and have come up with the following
list (things in square parens are bold, each set of asterisks was sent
as a separate message):

    Conversations: ** [***] ****
    Dino: [**] [***] [****]
    Gajim (not technically message styling): nothing bold
    Yaxim: Nothing bold
    Converse.js: Nothing bold
    Spark: Unsure (does not make styling directives bold at all, just the enclosed text)

Interestingly, Converse.js and Dino both do things incorrectly
(regardless of which rules you follow) if you actually send "** ***
****" on one line and appear to be able to wind up with unmatched (but
highlighted) directives.

Unfortunately this means that either way I clarify it I'd break some
existing application. I'd be curious if others think one way is better
than another. Luckily this isn't the kind of thing that's likely to be a
problem or confusing in the real world for real users.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20201107/052ad46f/attachment.html>

More information about the Standards mailing list