Blurred editor selection should be distinguishable

[mlewand]

📝 Provide detailed reproduction steps (if any)

1. Open any CKEditor 5 sample.
2. Select all the content.
3. Move the focus away from the editor, e.g. press shift + tab to move the selection to preceding "classic editor" link.
4. Examine editor selection color.

✔️ Expected result

A common practice is to turn it gray or hide completely if the input widget is not focused.

❌ Actual result

Currently the editor focus is always blue.

📃 Other details

• Browser: Any
• OS: Win10 (probably any)

---

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

[Reinmar]

That's native behavior. We do nothing custom here. I'm not sure we should be touching this.

OTOH, it's something that we could perhaps do differently than the OS.

[Reinmar]

cc @oleq

[mlewand]

I'm actually surprised to see that this is an issue coming from browser, and in fact this is what we get from contenteditable. For comparison here's the behavior for textarea in Chrome, which still is not ideal:

Works better for this particular case but then again user is not aware what has been selected.

The way I see it the most optimal way is to keep showing the selection but change its color, to indicate that it doesn't have the focus.

[oleq]

Yes, we can do something about it. I created a PoC in https://github.com/ckeditor/ckeditor5-theme-lark/compare/i/6517?expand=1 that works in Chrome and Firefox.

Except for the selection background in nested editables which is broken due to the ::selection selector I used:

I couldn't find any way to filter nested editables out. Technically we could override this ::selection in widget styles but then there's probably no way to revert it to UA value.

Wanna take a look @panr?

[panr]

Sure, will check it tomorrow morning 👌

[panr]

@oleq what about using .ck-blurred class?

.ck-blurred ::selection {
    background: var(--ck-color-editable-blur-selection);
}

IMHO, it's even better. You keep "active" selection when you're navigating through the toolbar, but you get "inactive" selection when you blur the editor for real. And of course it's binded to the existing logic (switching between .ck-focused and .ck-blurred).

[oleq]

@panr It won't work because if you focus the toolbar via Alt+F10, the root editable still has .ck-focused. And this is when the selection should be greyed-out.

[panr]

As I mentioned above:

IMHO, it's even better. You keep "active" selection when you're navigating through the toolbar, but you get "inactive" selection when you blur the editor for real. And of course it's binded to the existing logic (switching between .ck-focused and .ck-blurred).

:-)

And for some reason, you decided to keep the .ck-focused class when focus changes to the toolbar 😉

[oleq]

Can you create a PoC so we can see it live?

[panr]

Sure, the simplest and the quickest POC (without any mocked environment) — https://github.com/ckeditor/ckeditor5-theme-lark/compare/i/6517-ck-blurred?expand=1 (don't be bothered by the diff in formheader.css ;-P )

[oleq]

So it only affects the selection when the focus went out of the editor (not when the toolbar became focused)... I think it makes sense and we could go with it. WDYT @mlewand?

[mlewand]

@oleq @panr Having it active while in the toolbar sounds totally fine to me (I think it makes for less distractions that way, so we should favor this UX-wise) 👍

[panr]

@mlewand @oleq I'll create a proper PR later today 👌