On Montag, 1. Juni 2020 10:23:37 CEST Dave Cridland wrote: > On Mon, 1 Jun 2020 at 09:19, Dave Cridland <d...@cridland.net> wrote: > > On Sun, 31 May 2020 at 23:50, Tedd Sterr <teddst...@outlook.com> 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. > > [… this omitted text is discussed separately below …] > > 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?
(Note: I fixed up some plain-text rendering of the quoted email to make it more readable. I hope I didn’t mess it up more.) Thank you very much, Dave, for writing this down. I like the proposed text and the rationale for it. As a strong opposer of in-body markup, I feel the need to say a few words on why I think that this compromise is "good enough", although it still mixes metainformation and content in XML character data. First off, as Dave mentioned already (and as "everyone" will already know), arguably this is deployed very widely. And not because of '393, specifically, but because people have been using these types of metamarkers for so long already that nobody could possibly trace it down to a single source. In a way, they are similar to quotation marks; they’ve become part of an additional grammar used by many people throughout the internet. There are "cultural dialects" (e.g. the various markdown flavors), but there is basic compatibility. Pinning down the XMPP dialect of this is a good` thing™. However, we need a way forward which will not have to rely on transmitting these markers on the wire. And we also need to be able to deal with entities which send text which is strongly not intended to be formatted based on those markers. With the proposed mandatory opt-in and opt-out solution, we get both of that. I *hope* that clients which unambiguously support '393 will start to add the opt-in so that the default behaviour (in absence of any marker) can move back from "styled" to "unstyled". In addition, should we ever have to iterate on this document (either in a new XEP or in this thing while it’s in draft), we now have a wire format element of which the namespace can be bumped. I think this is a good solution for a gradual transition we need to make. It builds the foundation for moving to a proper and more powerful rich markup solution. Omitted text from blockquote above: > 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. Yes, accessibility is a concern. Unless we find an expert in the various tools and platforms involved, I suggest that we add a rather generic hint that implementors should vet this particular feature with their resident accessibility person and report issues. I’m afraid that recommendations around this will be in flux, since the a11y tools themselves also are constantly adapting to software which is in the wild. So it’s very well possible that we can’t really put down hard requirements or suggestions here as they may become obsolete. Either way, the final wording on this can easily be deferred to the CFE towards Final state. kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
