On Mon, 1 Jun 2020 at 09:19, Dave Cridland <[email protected]> wrote:
> > > On Sun, 31 May 2020 at 23:50, Tedd Sterr <[email protected]> wrote: > >> *4c) Advance XEP-0393 (Message Styling)* - >> https://xmpp.org/extensions/xep-0393.html >> Dave quite likes this, but is aware that many people don't. >> Jonas has a multitude of concerns: community recommendations for an >> explicit opt-in switch; no way to replace this with an updated or new >> variant, due to a lack of explicit signalling; putting 'markup' in the body >> is not the way to go in XMPP (more a weak, purity argument); it should >> mention security concerns about using existing markdown parsers, even if >> they're not necessarily 100% compatible; lack of an explicit grammar for >> writing a compliant parser. >> Dave sees the problem of there being many conflicting demands around >> styled text in messages, and doesn't think are yet any clean solutions; and >> this isn't one, either. >> Despite his concerns, Jonas acknowledges that this stimulated a great >> deal of improvement in UX by adding rich text to clients; but it was useful >> as an intermediate step, and we should now find a way to do it properly. >> Jonas would also prefer if this were on Informational-Active, rather than >> Standards Track. >> Daniel notes that this is only standardising something which clients >> already do in one form or another, and have done for years; it's not really >> in-body markdown because the formatting isn't removed, it's a suggestion on >> how to display emphasis that users are giving the text regardless - >> therefore it doesn't require opt-in/out. Dave knows it doesn't need >> signalling or negotiation, but thinks it would be nicer if it did - Daniel >> wouldn't be against adding a hint in the body to indicate use of message >> styling. >> Jonas replies to Daniel that, in that case, it doesn't really belong on >> the Standards Track; quoting XEP-0001, §3.1, "A Standards Track XEP defines >> … A wire protocol intended to be used as a standard part of XMPP >> technologies.", Jonas doesn't feel comfortable approving this for Standards >> Track, and even Informational would be stretching it, but is acceptable as >> a middle-ground; a non-XSF resource, such as ModernXMPP or similar, would >> be more fitting for UI things (which this is, according to Daniel's >> argument.) >> >> Jonas: -1 (concerns mentioned above) >> Zash: -1 (agree with Jonas) >> Dave: +0 >> Daniel: +1 >> Georg: [pending] >> >> The author, Sam, views the use of a "styling hint" as unnecessary bloat; >> Sam also took care to make sure the grammar was well-defined so a compliant >> parser can be written; also feels strongly that it belongs on the Standards >> Track. >> Zash thinks that overloading the body without negotiation is problematic >> - Dave queries whether negotiation or hinting would be preferable - Zash >> thinks either would be better than nothing. >> Jonas could be persuaded to accept overloading the body in this specific >> way if and only if an opt-in is given; and if an opt-in is present then >> it's more clearly wire protocol and belongs on the Standards Track; the >> lack of formal grammar isn't blocking, as long as implementers agree that >> it's doable without one (which is more an issue for Final.) >> Sam says it will never be opt-in, as that defeats the point - the very >> reason it got wide adoption is because it wasn't opt-in, it simply >> documents how to apply styling to what users already do; it could be >> opt-out per message, but that's all he would be comfortable with - opt-in >> is the only thing Jonas would be comfortable with. >> Dave says the inclusion of a styling hint for opt-in would move his vote >> to +1, and opt-out would be great too. Zash is also fine with this. Jonas >> concludes this is a clear way forward for the author. >> Sam intends to add the opt-out hint, but is absolutely against adding >> opt-in as it would completely break the point of this - it makes this much >> harder to implement and much less consistent. >> Jonas tries to get things back on-track, and directs further discussion >> on this elsewhere. >> > > I'll try to summarise this as best I can, and then look for a consensus to > advance the document. > > The status quo is that a considerable number of clients by deployment > already look for things like *this* and apply styling. A considerable > number of users will type things like *this* irrespective of client > support, and have done for literally decades. > > So from that perspective, *at least* an informational document seems > useful. (I will avoid the meta-argument over whether this is a wire > protocol or a UX hint; I maintain this is a distinction without much merit). > > Sam's position is, as I understand it, that this status quo should simply > be recognised. > > Others (Jonas for example) feel that it presents sufficient problems that > it ought not to be presented as a recommended standard. > > The suggestion offered is to add one of two hints - in the interest of > finding a consensus here, I'll suggest some concrete text as a starter: > > Implementations of this specification MUST add one of two hints: > > <styled xmlns='urn:xmpp:styling:0'/> - This message body contains >> explicitly styled text, either because the client always does this or >> because the user has explicitly chosen this. Any styling markings SHOULD be >> honoured. >> <unstyled xmlns='urn:xmpp:styling:0'/> - This message body does not >> contain explicitly styled text, so any styling markings SHOULD be ignored. >> In the absence of either marking, receiving clients MAY choose to render >> the text as styled or not at their discretion. Implementers are advised >> that there exist a number of deployed clients which will render such text >> as styled, and a number of users who will habitually type these markings >> even if no UI support exists. >> > Notes: > > - I've made this a MUST-send because although I feel personally that > given such widespread use, it's somewhat bolting the door after the train > has sailed, I appreciate that many in the community would strongly prefer a > future based on explicit signalling rather than fire-and-forget. > - I've equally made the hint a SHOULD-accept because a client might > heuristically determine that - in particular - styled text isn't. As > before, I believe that I'm voicing the community consensus here but I'm > personally perfectly happy to change these. > > Nice, I managed to accidentally send this while trying to figure out how to add extra blank lines into the quoted block. Turns out it's *not* Control+Return. Anyway... One more item that I thought got raised in the discussion was accessibility. I have *no* idea what text-to-speech systems do when faced with text in this form. I think this specification would probably benefit from at least a note to that effect. If we have a hint and (approximately) the text above in the specification, is this enough to make people... if not actually happy, at least willing to grudgingly accept the document? Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
