[Standards] Proposed XMPP Extension: Styling
jonas at wielicki.name
Wed Nov 8 10:18:51 UTC 2017
On Mittwoch, 8. November 2017 10:58:06 CET Goffi wrote:
> Le mercredi 8 novembre 2017, 10:39:49 CET Daniel Gultsch a écrit :
> > Reading this the first time I wasn't sure what you mean by opt-in.
> > But essentially you want each 'styled' message annotated by an <styled
> > xmlns="styling..."/> tag or something like that. And you want clients
> > to render those messages styled only if a message contains that tag.
> > I can get on board with this.
> > I mild annoyance is that the sending client needs to support this. So
> > if i'm using mcabber which doesn't support styling I can never trigger
> > styling on the receiving side even if I, as a knowing user, know about
> > the syntax and the consequences of styling.
> > But if this is required to get everyone happy I can accept this as a
> > compromise.
> Hi Daniel,
> regarding the new "Message Markup" proposal from Jonas I think there is
> little sense to keep pushing this styling one, the use case is covered and
> in a far better way (no markup in the body).
We’re having a nice, civil discussion in xsf@ right now about this, let me
summarize my current viewpoint on this (as author of the Message Markup
- Styling fills a gap in the sense that it documents currently used input
formats *and* provides a nice fallback for plain-text clients at the same
- It should be viewed as a docmuentation of the current status instead of a
new markup format everyone is supposed to use from now on.
- Daniel agreed to an opt-in mechanism so that clients which did not intend to
send Styling-ed messages don’t get their messages interpreted that way
- People pointed out rightfully so that Message Markup indeed contains
something like markup in the body -- this is contradictory to the mission
statement that it should not. I have a hard time to resolve this
contradiction, but it boils down to "we need a plaintext fallback" and
"plaintext fallback is hard to distinguish from markup language in many
- I think that there’s merit in having something like the rejected Body Markup
Hints as a more general mechanism and have Styling define the current use of
intuitive ascii-based markup. This provides us with an opt-in mechanism and a
- I think we have to acknowledge that there are sources which emit a markup of
a certain class (like what is documented in Styling, or even Markdown like the
sources Florian quoted when proposing Body Markup Hints) which falls back to
plaintext gracefully. We can make use of this property (which Message Markup
does not necessarily have, and which XHTML-IM certainly does not) by leaving
the markup in the <body/> as plain-text fallback and at the same time
conveying a hint how it can be formatted nicely.
Examples of markup which falls back to plaintext gracefully: Markdown,
Counter-examples: XHTML, reStructuredText (sometimes), Markdown containing
- I think we at the same time also have to acknowldege that there are sources
which emit text which is really just plaintext (automated systems), and their
messages must not be interpreted incorrectly as marked up.
- I think we also have to acknowledge that there are use-cases for much richer
text, for example within the Social Network and Blog Federation interest
groups (sorry if that name doesn’t quite fit). Those use-cases were covered by
XHTML-IM before, and fail to be covered by BMH and Styling. Message Markup can
cover those use-cases, if it gets extended into that direction, while helping
to prevent the security issues of XHTML-IM. Please see the other thread for
considerations about plaintext fallback.
I think that this discussion has helped me to better understand where I want
to go with Message Markup, and I also think that both specifications plus
possibly BMH should co-exist.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards