On Mon, Nov 06, 2017 at 11:58:15AM -0600, Sam Whited wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Styling > > Abstract: > > > This specification defines a plain-text formatting syntax for use in > > exchanging instant messages with simple text styling. > > URL: https://xmpp.org/extensions/inbox/styling.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________
Hi, Thanks for taking the time to write this. I do like that it strictly defines a few ways to format text and blocks, without leaving too much leeway to implementors. I still think putting markup in the <body/> is a terrible idea that is not detectable or extensible, and proprietary clients get away with it only because they are in control of the client and server infrastructure. 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. If it's supposed to be informational (or historical), then it should not require additional development time or client updates; if it is something clients should implement in the future, then I don’t see how the existing, inconsistent behavior of current clients regarding inline markup is supposed to help this XEP. I’m in favor of the BMH-not-BMH suggested by Jonas, but I think it’s an awful solution to a problem we should not have (interpreting the body as something it is not). And it won't do a thing for clients that don't support this rendering. On the technical content of the XEP: - 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 - In 5.7, I don't understand example 5, why is there an "ignored", is it ignored by the rendering? why? - In 5.8, I think having blockquotes start with "> " (spaced) and not ">" would be better, as we can already see conversations quoting "><" smileys. - 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. - On section 9, there should be a grammar, or a reference implementation developers can use or check against, 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) Mathieu _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
