Re: [Standards] Council Minutes 2020-05-27

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

Re: [Standards] Council Minutes 2020-05-27

On Mon, Jun 1, 2020, at 12:51, Tedd Sterr wrote: > Your view is that some clients may default to not styling, and other > clients may default to doing styling, and so the same message viewed > on two different clients will render differently. This is also going > to happen where some clients

Re: [Standards] Council Minutes 2020-05-27

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

Re: [Standards] Council Minutes 2020-05-27

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

Re: [Standards] Council Minutes 2020-05-27

Not that it really matters, but to be pedantic and correct my own mistake: I mentioned connected scripts, this is not correct. That is a Zero width joiner, of course. ZWS is used in languages that don't put spaces between words to indicate word boundaries, which is of course a different thing. I

Re: [Standards] Council Minutes 2020-05-27

As I understand your argument, it seems the disagreement is actually over what happens when no hint is provided, rather than whether an opt-in hint should be provided. Your view is that some clients may default to not styling, and other clients may default to doing styling, and so the same

Re: [Standards] Council Minutes 2020-05-27

Hi, Sorry, long mail ahead. I'd like to express that I am very much unhappy where this is leading. While I am personally not a big friend of inline message styling, I kind of feel that the party of non-likers (or parts thereof) is trying to make the XEP to something that is mostly useless

Re: [Standards] Council Minutes 2020-05-27

Based on the feedback provided, and partially based on the text Dave suggested, I've submitted some updates to add an "unstyled" hint among other more minor changes. https://github.com/xsf/xeps/pull/955 I want to give my reasoning for not adding the opposite, a "styled" hint, on list: Part of

Re: [Standards] Council Minutes 2020-05-27

On Montag, 1. Juni 2020 15:28:40 CEST Maxime Buquet wrote: > On 2020/06/01, Jonas Schäfer wrote: > > [..] > > > > 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

Re: [Standards] Council Minutes 2020-05-27

On 2020/06/01, Jonas Schäfer wrote: > [..] > > 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

Re: [Standards] Council Minutes 2020-05-27

On Montag, 1. Juni 2020 10:23:37 CEST Dave Cridland wrote: > On Mon, 1 Jun 2020 at 09:19, Dave Cridland wrote: > > On Sun, 31 May 2020 at 23:50, Tedd Sterr wrote: > >> *4c) Advance XEP-0393 (Message Styling)* - > >> https://xmpp.org/extensions/xep-0393.html > >> Dave quite likes this, but is

Re: [Standards] Council Minutes 2020-05-27

01.06.2020, 14:31, "Andrew Nenakhov" :пн, 1 июн. 2020 г. в 16:02, Kozlov Konstantin : That's nice, that this XEP wasn't advanced yet. This encourages me to fore work on XEP-0394: Message Markup, which I beleive is much better and has more potential, than this one. I'll do my best

Re: [Standards] Council Minutes 2020-05-27

01.06.2020 13:31:39 Andrew Nenakhov : > yeah, and we've strengthened our resolve to work on our (yet another) > reference-based markup extension, because it is very consistent, works > great with group chats, makes it easy to process markup, mentions, > filter attached media, stickers, etc. 

Re: [Standards] Council Minutes 2020-05-27

пн, 1 июн. 2020 г. в 16:02, Kozlov Konstantin : > That's nice, that this XEP wasn't advanced yet. This encourages me to fore > work on XEP-0394: Message Markup, which I beleive is much better and has more > potential, than this one. I'll do my best to post updates to it soon and > start

Re: [Standards] Council Minutes 2020-05-27

Hello! 01.06.2020, 01:53, "Tedd Sterr" : 4c) Advance XEP-0393 (Message Styling) - https://xmpp.org/extensions/xep-0393.htmlDave 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

Re: [Standards] Council Minutes 2020-05-27

On Mon, 1 Jun 2020 at 09:19, Dave Cridland wrote: > > > On Sun, 31 May 2020 at 23:50, Tedd Sterr 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

Re: [Standards] Council Minutes 2020-05-27

On Sun, 31 May 2020 at 23:50, Tedd Sterr 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;