Re: [w3c/editing] contentEditable: clarification of selection and typing behavior (#156)

> For those which don't implement a custom data model, it'd be great if it was consistent across browser and if the behaviour wasn't magical.

As far as I have seen, both editors with and without a data model largely try to control what change happens in the DOM. But you are right, sometimes this means reverting changes that have occurred already due to the lack of the beforeinput event. Another reason for why some let native handling go through and then revert afterward seems to be that otherwise the native browser spell checking doesn't understand what word should be underlined. And I one editor also let undo/redo events go through first when the undo undos auto-correct or spellchecking (and then it cleans the DOM afterward), because this way the browser ";learns" that a particular auto-correct or spell checking is undesired.

So browser native handling of some input still occurs sometimes with some editors, but at least I have not seen where this is happening in an "uncontrolled" manner, where the editor just lets stuff happen and then doesn't try to clean it up/standardize it afterward. Or which editors are you thinking of that let the browser handle uncontrolled DOM-changes (without time traveling backward)? 

What is definitely out of style is using execCommand except when there is no other way (clipboard-based events). So if part of the bug here is that execCommand does something inconsistent, I think all the JS editor projects would prefer if you could instead work on something that they use a lot more than fixing execCommand. Or what do you think @Reinmar?

-- 
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/156#issuecomment-263884190