Re: [w3c/editing] Different browser behaviors when moving the caret by one word. (#278)

I agree that standardizing across all browsers/OSs/languages will not work. But where do we ideally want the decision on what is the right caret movement behavior to sit? Is it in the browser or in the JavaScript app? If it is in the browser, as seems to be argued here, then it would be good if:

A) we could get browsers to try to make sure that they follow the conventions of the OS and script they are dealing with and to try to put resources aside for fixing bugs when they are encountered so that the JS editors don't end up with a lot of unfixable selection bugs against them, and

B) in those cases where JavaScript is taking on a greater part of the job of an editing app, for example using Input Events and/or EditContext, we need to make sure that it is always compatible with the native selection and that there are few or no situations in which JavaScript needs to intervene and move a selection manually because it ended up in a place where the caret cannot be displayed or similar.

I can see that we can do something for B by making sure those specifications are set up for such a situation. I don't know if A is something we can do anything about here other than to talk about it.

@Naheulf : Are you requesting an event with a target range that is executed before selection changes? Or are you saying you need an API to be able to query "If the selection was in place A and the user executed a command to go one word forward, where would the selection end up?" Or maybe something entirely different? 

-- 
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/editing/issues/278#issuecomment-777824882