[Standards] Council Minutes 2020-05-27

Sam Whited sam at samwhited.com
Tue Jun 2 15:36:32 UTC 2020

On Tue, Jun 2, 2020, at 10:26, Jonas Schäfer wrote:
> I think this is missing one disadvantage without an explicit opt-
> in flag:
> - We cannot upgrade or fundamentally change the syntax in a non-
>   breaking fashion, without:
>  - forcing everyone using a newer version to send opt-out flags for
>    all eternity, or
>  - adding explicit support for detecting other non-Styling markup and
>    disabling the Styling parser in those cases (which introduces a
>    weird coupling; you might call that ideological, too), or
>  - have inconsistent displaying of styling, which is the one of the
>    primary things this XEP is intended to solve.

I added a disco feature in the latest draft (merged earlier, should be
live later today if it's not already), this should also solve some of
these issues. A client can detect support which includes a versioned
namespace so that they can see what version of styling is supported if
we make changes later.

> I think this is fundamentally problematic.
> - Either the user inserts those characters themselves, which makes for
>   extremely terrible UX.
> - Or the sending client has to do it (-> requires client support) and
>   I wonder what the UI would look like for that.

The user probably doesn't want to insert those characters themselves,
and the space thing doesn't help much there. However, in the case where
the client does have a UI, this is fairly easy to do using normal UI
patterns. The user types *this* and it gets styled as strong, or they
highlight the text "this" and press the strong button and it wraps it in
*'s. Now they press the strong button again and it inserts the space if
one doesn't exist, thereby breaking the styling and the message goes
back to looking like "*this*" but without the formatting. Alternatively,
the user types "*this*" and it becomes strong, but they don't like that
so they press backspace. Instead of removing the last * the client could
first insert the spaces (then the user can continue to backspace if they
actually meant to remove the *). Of course, exactly what your UI
supports and how it does it is up to you, these are all just examples
based on other messengers that would work just fine with the space being
inserted to convey the no-break-but-not-part-of-the-same-span semantics.

> Then it has a non-obvious disadvantage (apparently) even to technical
> users, in that it inserts invisible unicode codepoints. This will
> cause hard-to- troubleshoot issues when (parts of) the message are
> copied into a thing which cares about it, such as a C compiler.

I don't think this is a problem we should worry about. If this is a
problem for you, you already have this problem all over the web and
everywhere else and the answer is not "pretend Unicode doesn't exist and
don't use it".


More information about the Standards mailing list