Re: [w3c/manifest] Rewrite dir member. (#743)

> Note: I think this is actually making a slight behavioural change which we may not be OK with (but assuming it brings it more in line with actual implementations): if the member is embedded within another string (such as "Do you want to install %s?"), the new text lets the BIDI algorithm take the wheel, whereas the old text implies (without formally stating) that it would be embedded LTR or RTL depending on the first strong character. I'll have to think on this more.

I thought a lot about this case. I think this is making a slight normative change, to no longer require, for `dir: auto`, user agents to wrap the string in an LTR or RTL embedding.

- a) it only makes things more permissive (any existing user agents are free to keep wrapping strings in an embedding, which is good practice for any user-supplied strings anyway), and
- b) this only affects extremely rare edge cases (wrapping a multi-directional string in another multi-directional string).

I think it's better to proceed; it's better to treat this like a normal string than impose special rules on how it must be renderer — rules that not only does the user agent need to follow, but it also needs to ensure the OS follows. (Consider generating a [.desktop file](https://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html) on Linux, and needing to wrap all strings in "[LRE]...[PDF]" or "[RLE]...[PDF]" to force the OS to follow the above rule.)

I'm going to keep this marked as "editorial change" since it doesn't break any existing behaviour but makes it (slightly) more permissive and easier to implement. (Also note that Chrome currently doesn't implement `dir` at all; I'm not sure about the state of the other browsers.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/743#issuecomment-442705181