Re: [editing] What do we need to integrate with the clipboard api? (#64)

> I have a feeling that changes to the selection for no good reason will be problematic for those who protested against these normalizations of the selection. But I cannot recall which of the editor people saw the normalization of selections as problematic. Was it one of you: @spocke, @teleclimber or @fredck?

I'm pretty sure every single one of us saw it as problematic, but I recall that I was writing about this (even [yesterday](https://medium.com/content-uneditable/contenteditable-the-good-the-bad-and-the-ugly-261a38555e9c) actually). 

The most important problem with selection normalisation is that [it makes it impossible to place selection inside empty inline elements](https://bugs.webkit.org/show_bug.cgi?id=15256) which is crucial for implementing features like *bold* and *italic*. User presses a *bold* button, an editor creates `<b></b>` element, inserts it and tries to place the caret inside. 

* Gecko and IE will keep the selection inside that empty inline element. When user starts typing, the text will appear inside this element.
* Blink and WebKit moves the selection to the closest text node (so basically – somewhere outside). There's a small difference between Blink and WebKit currently, as Blink will claim that the selection is inside that element (until it's manually changed), while in WebKit `getRangeAt()` clearly shows that the selection was normalised. The [change in Blink](https://code.google.com/p/chromium/issues/detail?id=2874), as I recall, was made as a first step to fix this bug, but the second step, [fixing commands so they don't normalise selection](https://code.google.com/p/chromium/issues/detail?id=346613) wasn't made.

Note that setting selection inside an empty inline element isn't the only problematic case. There are more:

* `<b>foo</b>^<b>bar</b>` (can be achieved by removing bold from a collapsed selection)
* `<p>^<b>foo</b>` (can be achieved by removing bold from a collapsed selection)

Interesting fact: if you use `document.execCommand( 'bold' )`, then magically everything works fine, but not because the engine allows to set a selection in such a place, but because the inline element is created upon text insertion. While this can be regarded as a solution (that an editor records that the *bold* command was executed and creates an element later on) I think it's not a good direction. For instance, the style of the caret (weight and colour of the line and cursive) could one day reflect the inline styling (it partially works in MSWord and very nicely in Google Docs). As a user I would then expect that if I press the *bold* button the caret immediately changes. That could be triggered by setting selection inside that `<b>` or `<i>` element. Therefore, I prefer Gecko's and IE's behaviour.

Moreover, when using `contentEditable=true` working around this issue in Blink and WebKit requires terrible hacks (CKEditor uses zero-with-space which it later must remove without breaking a composition). So in my opinion this problem needs to be resolved anyway and aligning specification to that flawed Blink's and WebKit's behaviour seems strange.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/64#issuecomment-131053162