On 02.06.20 22:34, Sam Whited wrote:
> This does not add new rules, [...] I was hoping to avoid
> adding extra rules anyways, and making category C another thing that's
> disallowed counts.

You are contradicting yourself, but I guess we were thinking the same
nonetheless ;)
>> Solution could be:
>> - If a space, the start of the string or a newline precedes the
>>   opening directive, it can be disabled by prefixing it with U+200B
>> - If another opening directive precedes the opening directive, it can
>>   be disabled by prefixing it with U+2060
>>
>> Both are not sane solutions and I wasn't actually very serious when
>> mentioning it. So maybe it's not a good idea to mention it in the XEP
>> even though it technically works.
> 
> This would be adding a new rule like disallowing category C would, by
> making the ZWS or whatever we ended up using a special case, which I was
> hoping to avoid, but it may be worth considering. I'll keep thinking
> about it. Thanks for the ideas!

I guess you misunderstood: I am talking about prefixing, that is putting
the non-whitespace character (both U+200B and U+2060 are) where a
whitespace would've been needed under current rules. Thus this does not
require any changes to existing implementations to support it. The
additional complexity is to correctly handle the breaking vs
non-breaking nature of the preceding character. It also wasn't exactly
correct as I didn't handle non-breaking spaces, so here is an updated
version:

- If a breaking space, the start of the string or a newline precedes the
opening directive, it can be disabled by prefixing it with U+200B
- If a non-breaking space or another opening directive precedes the
opening directive, it can be disabled by prefixing it with U+2060

I'd say it might be worth documenting that in the XEP, but I'd refrain
from in any way suggesting developers to do that outside of controlled
environments as this is very likely to have negative impact on clients
that use Unicode older than 3.2 (when U+2060 was defined as WJ) or don't
have proper Unicode support.

Marvin
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to