johanneswilm
commented
6 years ago @r12a this spec is just about capturing user intentions, triggering the beforeinput event, and then triggering another event (input) after the browser has made any changes to the DOM based on the intention. It is not concerned with anything else. If the JS author decides to handle event themselves, they have to use other methods to find out about what is present in the browser and how to manipulate it, just like they do now. This also includes the various text directions involved. Also, it does not standardize in what way UAs react to those user intentions, so in those cases where directions are important for how the DOM is changed by the UA, this is entirely up to the UA and not something specified in this spec.
As for formatSetBlockTextDirection and formatSetInlineTextDirection - these are triggered when the user expresses the intention to do so. Most common this would be through the context menu where these options often are found (see screenshot). Whether and how the UA or JS react to such a request from the user is entirely up to the UA/JS app and not specified here.
chaals
If someone selects a bidirectional phrase from a paragraph that has a RTL base direction, it will almost certainly be useful to know the the captured text came from a rtl context, and when inserting such text into a new context, it may be necessary to take some action to isolate and assign base direction to the inserted text if the base direction of the new context is different.
Do you envisage any way in which:
Actually there is the intriguing formatSetBlockTextDirection and formatSetInlineTextDirection, but it's not clear to me how those work, or whether they are intended to address this concern.