[Standards] Proposed XMPP Extension: Styling
sam at samwhited.com
Wed Nov 15 15:46:36 UTC 2017
On Wed, Nov 15, 2017, at 04:06, Mathieu Pasquet wrote:
> One thing that bugs me is that this XEP is supposed to specify the
> existing behavior of several clients regarding various pieces of markup
> (Gajim, Psi, etc…), but on the other hand it does not exactly match with
> either (from what I remember of gajim inline markup, at least). Even
> then, Conversations implemented it while it previously only had support
> for the blockquote feature. The other clients will probably need to be
> updated to match the featureset and the rules defined in the XEP, so it
> will not be compatible with the already existing deployments.
Unfortunately there was no single formatting in use across clients that
I tried, so I went with the one that seemed most widely spread (or at
least, something similar to it). This wasn't really meant to be a
historical XEP that documents existing functionality, it was supposed to
be a new styling system and I just took cues from what people were
already doing when writing it up. The ideas was to make it a standards
track XEP (not historical or informational). I'm not against changing
that, but I do have a feeling standards track makes the most sense.
Right now there is fragmentation among clients, hopefully this standard
can reduce that fragmentation (eventually, it's not likely to happen
> - Section 4 is somewhat insufficient, it does not make a case for
> styling being both an input and a wire format at the same time
Users don't really care what the wire format is, and the use cases are
mostly about users. I agree this could use some expanding though, and
I'd love suggestions.
> - In 5.7, I don't understand example 5, why is there an "ignored", is it
> ignored by the rendering? why?
Oops, that looks like a mistake. We'd talked about making all text on
the same line as the opening ``` ignored but I appear to have added it
to an example but not to the text. Thanks!
> - In 5.8, I think having blockquotes start with "> " (spaced) and not ">"
> would be better, as we can already see conversations quoting "><"
This seems sensible; it does mean that nested block quotes would have to
be special cased, or the definition of block quote changed to include
the "level" of the quote. I'll think about how best to reword this.
> - In section 7, accessibility, there is no way to make this kind of
> thing accessible to existing clients, because they have to support the
> XEP to exclude formatting characters from being read.
I do not think this is an accessibility concern, maybe a UI issue
though. However, the plain text version of formatting sent using this
specification is probably readable enough. People are used to quotes
from email and type *emphasis* all the time. The others are easy enough
to understand (or at least don't hinder readability).
> - On section 9, there should be a grammar, or a reference implementation
> developers can use or check against
I will try to add something later on in the process; that does seem
reasonable to have.
> otherwise I don't see how that
> will solve any of the security issues we had in XHTML-IM. (this is
> close enough to a subset of markdown that some people will be tempted
> to use on of the existing parsers, most of which allow inline HTML)
This is not compatible with markdown, many of the symbols are different
so using a markdown library is probably not an option.
More information about the Standards