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

I believe, that there are two perspectives when talking about RTEs.

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. For example, Chrome has that "funny" behaviour that deleting the content of `<strong>` and then typing leads to inserting `<b>`... And `<a>` is replaced with `<u>` (cause link was underlined, so Chrome tries to maintain that styling ;|) (see: https://bugs.chromium.org/p/chromium/issues/detail?id=226941). This is magic which breaks people content and cannot be controlled in a reliable way by RTE developers. 

The situation may be different in case of RTEs with a custom data model. I don't know how it works in e.g. ProseMirror or Draft, but in [CKEditor 5](https://ckeditor5.github.io) we built an abstraction over the data and selection and we handle content modifications manually in the model and re-render the DOM if needed. 

Due to the fact that `beforeInput` isn't yet available, we needed to implement some hacks in order to intercept user input. With `beforeInput` we won't need that, so we'll be fully independent on browsers' input handling. The only thing which `beforeInput` doesn't change is where we see selection in the DOM, so that's still a thing which could be improved, but it's not very important because the custom data model represents text attributes (bold, italic, links, etc.) differently.

See https://twitter.com/pomekPL/status/740149101334016000 for how the text attributes are represented. They are just a properties of characters. Hence these two positions: `x^<b>x...` and `x<b>^x` are in some way identical for us. They are both positions between `x^x` and the difference is in the selection attributes (whether the selection has bold or not – yes, the selection also has attributes). However, this only applies to collapsed selections, so in the selected link case there's just one selection for us.

Anyway, you can test how we decided to implement the case with typing over the link on https://ckeditor5.github.io – the link is always fully removed and the typed text isn't linked. Typing over a non-collapsed selection always triggers first a generic `delete content` action and only then inserts the new text. So it's the same behaviour which backspace + typing have. It was natural for us that after you select entire linked/bolded/etc fragment of text and deleted it you don't want to have that style anymore.

-- 
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-263856172