Adding .ck class to elements in content generates conflicts between features

[szymonkups]

The .ck class became the common part of some features and creates conflicts between them.
For example, placeholder needs to know where to add and remove ck class because it might be added to the element that already had that class.
Another example might be a conversion from marker to some highlight (like presenting user selection in collaboration use-cases). When that highlight is using ck class it needs additional logic to not remove those class on elements like widgets or links (link highlighting using class will propably use ck class aswell).

I guess we should discuss if adding this class to elements in the editor's contents is a good idea.

[Reinmar]

The .ck class was introduced to improve selectors specificity. However, one of the most important requirements for the editor's architecture is that various features should be extensible. So we have many features which are composed together. And then we have the conflict – which of these "feature atomic functionalities" should care about the .ck class?

One of the options is that only the base feature (e.g. the editable UI view or the toWidget() helper) should be adding this class. All the other extensions (user selection, placeholder) should not toggle this class. This is tricky (see https://github.com/ckeditor/ckeditor5-image/issues/198#issuecomment-378643612) because sometimes the base feature may not be able to easily add this class.

The other option is that we should not use this class inside the editor's content. It was meant to improve the specificity of selectors, but perhaps it doesn't have to do that everywhere. Also, in certain scenarios instead of writing a selector such as .ck.ck-user-selection we may write .ck .ck-user-selection because the editor's UI will provide this class somewhere up the DOM tree.

Let's see this on examples:

• Link highlight – I think that it's unnecessary that it adds the .ck.ck-link_selected classes together. It may only add the .ck-link_selected and the selector could be .ck .ck-link_selected.
• User selection – the same as with link highlight – it should add just one class and use selectors like .ck .ck-user-selection.
• Placeholders – this one is the trickiest because it can be used whenever you want – on an editable element which does not have any .ck ancestor, or inside the editor (e.g. the title element), when managing the .ck class is not cool. So, we can leave how it works now (it removes this class only if it added it). Or we can style it using two selectors: .ck .ck-placeholder, .ck.ck-placeholder to handle these two situations. In the latter case, ensuring that the .ck class is present somewhere will be the responsibility of someone who uses the placeholder util.

[Reinmar]

cc @dkonopka @oleq

[scofalik]

Maybe we could hotfix this issue by adding view post fixer. Every element which should always have a .ck class, but sometimes have the class stripped (like <figure class="image"> in the view) could have a post fixer that will add the .ck class if it is gone. Seems like a quick solution that might work until we have a real one? WDYT?

[Reinmar]

I don't think that's a good idea. Once we'll understand what direction to take, fixing this will be trivial.

[scofalik]

But we have to take a direction and it does not look like we do :). Also, this causes some ugly looking bugs now.

[scofalik]

We decided to use .ck .ck-link_selected type of selectors, so .ck class will be defined only on root editable. Placeholder styles will use .ck.ck-placeholder, .ck .ck-placeholder selector.

[scofalik]

PRs related to the issue:

ckeditor/ckeditor5-widget#38
ckeditor/ckeditor5-image#202
ckeditor/ckeditor5-link#191
ckeditor/ckeditor5-engine#1396
ckeditor/ckeditor5-theme-lark#167

@dkonopka could you please review if these are all changes that are needed to be done? I hope I haven't missed something.

[Reinmar]

🎉