Fake selection

[Reinmar]

Fake selection is a feature which lets us work around browser limitations. Various browsers support only limited types of selections. For example, most browsers do not support multi-range selections (which are needed to represent table cell selections) and Blink and Webkit don't support selections anchored in elements which makes it impossible to have e.g. this:

<p>Foo.</p>
[<figure contentEditable=false>...</figure>]
<p>Bar.</p>

In CKEditor 4 we worked around this by styling the selected object so it looks like selected and hiding the real selection in a hidden container. Table cells selection works a bit differently and only marks the cells, leaving the native selection somewhere in the table.

Proposal

1. We're free to place whatever selection we want in the data model.
2. While conversion, a specific feature must tell how to render a selection on itself (e.g. add a class) and mark it as "fake".
3. The DOM renderer will then render such fake selection in a way it wants, handling all possible DOM quirks.

Most likely, we'll also need to types of fake selections – "on objects" and something to handle tables. Alternatively, the table feature will mark all cells (by adding classes) and cancel rendering 2+ ranges of the selection. But I don't know how this could work while you make selection using DnD (because it shouldn't be re-rendered then).

[Reinmar]

PS. We've been also discussion where should land the code which:

1. Listens on click on objects (which can be only selected with fake selections) and select them in the model (because this isn't a native behaviour).
2. Which handles arrow keys when a fake selection is made (it must be moved in the model).
3. ... and this is it – in CKEditor 4 we also had to handle backspace and block all other keys, but in CKEditor 5 those features will work naturally even on such selections.

I'm for placing 1-2 in the engine.

[fredck]

Will this feature also cover the following related "sub-features":

• Fake focus: For example, if I'm side an image caption, I may want to have the caption marked just like a selection, while the caret is inside the caption and I'm typing.
• Hover: When moving over widgets, I want them to be highlighted like a selection, but with a different color.

Basically, I'm talking about bringing the exact same features we have in CKEditor 4's Image2... they make the widget system very easy to use.

[fredck]

I would make it clear that this issue has nothing to do with fake inline, text selections, similar to those that one would use to show other users selection in collaboration.

Btw, this comment made me think that this feature can be useful in collaboration contexts where one wants to show the fake selection of other users with different colors.

[pjasiun]

I'm for placing 1-2 in the engine.

Hover: When moving over widgets, I want them to be highlighted like a selection, but with a different color.

I agree that 2 should be handled by the engine as a part of the fake selection. The user should be able to simply mark the selection as fake and do not care about its behavior.

So what engine allows you is to set the view selection in places where you can not set the DOM selection and add special flag fake to it. Thanks to it, the DOM selection is put in the safe place, but act like it is in the place you selected in the view (arrows works as expected).

On the other hand, the fake selection should not handle visual representation of the selection, should not mark any element in any way, nor add any listeners as long the selection is not there. This is why I think that it should not handle 1 nor hover.

But. This is exactly what should be provided by widgets. In CKE 5 widget should be a view/DOM element which provides exactly this: fake selection with proper visual representation, hover and clicks behavior (and it might be a part of the engine too, IMHO).

Btw, this comment made me think that this feature can be useful in collaboration contexts where one wants to show the fake selection of other users with different colors.

Selection of other users and the fake selection are separate cases. In the first one, the most important problem in how to handle changes in the view which has not representation in the model, what is not a case in the fake selection. On the other hand, fake selection needs to move the real selection and provide proper behavior for arrows, what is not a case for others users selection.

[fredck]

Selection of other users and the fake selection are separate cases. In the first one, the most important problem in how to handle changes in the view which has not representation in the model, what is not a case in the fake selection. On the other hand, fake selection needs to move the real selection and provide proper behavior for arrows, what is not a case for others users selection.

Yes, ofc... but for sure there are several rendering features that should be shared here.

[Reinmar]

On the other hand, the fake selection should not handle visual representation of the selection, should not mark any element in any way, nor add any listeners as long the selection is not there. This is why I think that it should not handle 1 nor hover.

Hover will be handled by CSS of course. Click listeners should pluggable and, as we've just agreed, should be implemented by the engine. They should not, however, be obligatory fake selection's feature.

But. This is exactly what should be provided by widgets. In CKE 5 widget should be a view/DOM element which provides exactly this: fake selection with proper visual representation, hover and clicks behavior (and it might be a part of the engine too, IMHO).

Widgets are 3rd thing in this picture. There's fake selection support, specific behaviour handlers (like "click to select" or "move sel on arrow key"), and widget view element. Widget view element will handle adding special classes to widgets and perhaps ensuring that default styles for them are injected in the page.

Widget elements can also automatically mix in those specific behaviours, like "click to select", but we need to figure out how we can actually do that. Cause currently we don't support view element observers and it seems that if we want to enable injecting behaviours to view elements, we need to have observers.

[mlewand]

I'm wondering if other than listening to (arrow) keys / pointing events there's also a need to create a fake selection on generic selection change event - some IMEs expose "arrow keys" - and it wan't that long ago when we were dealing with all keycodes being 0 in mobile Chrome. Although the ticket is closed as won't fix I saw that on most recent Chrome that in fact keycodes are there - however that's just one combination of browser - IME.

Also by implementing custom selection make sure to cover a11y for this feature. You need to keep user informed of what's going on. Without handling it user will get irrelevant information based on native selection.

[Reinmar]

Right, you mentioned 3 interesting things.

1. We always need to listen to arrow keys, because you must be able to select a widget if previously you had selection in the text next to it. So it's a behaviour that you need to inject globally, if there's at least one widget in the document.
2. Key codes 0 are something that can only be work arounded if there's some other property of the event set correctly. If none, then we can't do anything. Do you remember @mlewand what have you found out?
3. A11y is a feature for the future. It shouldn't be hard to complete though.

[mlewand]

1. I didn't mean to remove the key listener, just wondering if we need on top of that.
2. Unfortunately, back then there was no reliable way to tell which key was pressed on Android Chrome. I just on an Android device that was by my hand and... all the alpha-num keys are still marked with 229 code. But arrows were identified correctly. Anyway it needs more research down the road, thing might change since then.
3. I agree it should be fairly simple to accomplish. I think it would be a nice idea to create some sort of internal a11y bus within the application, so any component will "speak" through it.

[pjasiun]

See: https://github.com/ckeditor/ckeditor5-engine/issues/309 :P