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 overnight). > - 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 "><" > smileys. 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. —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
