[Standards] Council Minutes 2020-05-27

Kevin Smith kevin.smith at isode.com
Tue Jun 2 13:16:01 UTC 2020


On 1 Jun 2020, at 19:52, Kevin Smith <kevin.smith at isode.com> wrote:
> 
> I think all the discussed ideas have merit, although possibly not for the obvious reasons:
> 
> I think there is merit in being able to mark some bits of a message as skipping styling. This is conceptually a hack (IMO), but it’s a hack that has mileage and we should follow this train of thought through.
> 
> I think there is merit in “This message does not contain styling, don’t bother parsing for it” for multiple reasons, performance being as obvious one, but possibly more usefully it’s very simple for an entity that will never send styling (e.g. a bot) to shove this on all messages and not have to (implement support to) parse the outgoing message, work out where the style-breaking-character-hack needs to be applied, and apply them.
> 
> I think there is merit in “This message *does* contain styling, and you can skip the markups, because I’ll have hacked them away from where they shouldn’t be applied”. This is opt-in where the opt-in is actually providing value, I think.

And that can be applied to screenreaders, or whatever accessibility services, so it can try to avoid reading out the markup. It doesn’t make the world perfect, but it means that for that part of the world that does implement 393 including the (currently hypothetical) opt-in, at least screen reader-aware clients can have a better time of it when incoming messages are marked with the opt-in annotation.

So I’m not pretending that clients won’t send without such an opt-in, or that a receiver should assume it’s not marked up because it doesn’t see the opt-in, but I don’t think it’s worthless to have it.

/K

> 
> /K
> 
>> On 1 Jun 2020, at 18:05, Sam Whited <sam at samwhited.com <mailto:sam at samwhited.com>> wrote:
>> 
>> Sorry, last rapid reply to my own email, I promise:
>> 
>> Apparently there is U+2060: word joiner which is the exact same thing as
>> a ZWSP except that it implies no line breaks. This has just about
>> exactly the semantics we want, and seems like it would be a good
>> candidate for how you disable styling on a specific piece of text.
>> 
>> I think I would prefer to have this over something that has to be
>> namespaced and registered. It's more flexible, would make it easier to
>> implement eg. a toolbar with bold and italic buttons (things get styled
>> by default if you type them, if you highlight the whole thing and remove
>> the styling it could cycle through just removing the styling but leaving
>> the *'s, or removing the *'s etc.
>> 
>> What do others think?
>> 
>> —Sam
>> 
>> On Mon, Jun 1, 2020, at 12:59, Sam Whited wrote:
>>> On Mon, Jun 1, 2020, at 11:58, Marvin W wrote:
>>>> PS: As a sending client you can already opt-out using a hack: By
>>>>    prepending the opening (and, if needed, closing) styling
>>>>    directive with zero-width space (U+200B)
>>> 
>>> I hadn't actually thought of this. I'll need to think about it more,
>>> but we might recommend this in the spec since this is the exact use
>>> case zero width spaces are for (things that are word boundaries but
>>> where spaces don't necessarily go, between characters that shouldn't
>>> be put together in connected scripts, etc. My only concern would be
>>> that they also have the meaning "you can add a soft break here" which
>>> is probably *not* what you want in this case.
>>> 
>>> I'll think about it more, but this is definitely at least close to the
>>> point of a zero-width space and might be worth documenting.
>>> 
>>> —Sam
>>> 
>>> 
>>> --
>>> Sam Whited
>> 
>> -- 
>> Sam Whited
>> _______________________________________________
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards <https://mail.jabber.org/mailman/listinfo/standards>
>> Unsubscribe: Standards-unsubscribe at xmpp.org <mailto:Standards-unsubscribe at xmpp.org>
>> _______________________________________________
> 
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200602/bea2bcfc/attachment-0001.html>


More information about the Standards mailing list