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". —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
