[Style dropdown] Allow style definitions with various attributes

[semiaddict]

📝 Provide a description of the improvement

The Style plugin currently requires each definition to have a non-empty list of classes (an empty list results in the style not being applied), and doesn't allow setting other attributes.

It would be great to be able to specify definitions for elements with other attributes than just classes, and make classes optional.

This would make it possible to implement styles that simply add inline elements (such as <cite>, <q>, or <kbd>), and allow setting attributes other than classes such as "dir".

This is how it used to work in CKEditor 4, but seems to no longer be possible in CKEditor 5.

I would propose changing the style definition to something as below:

{
  name: "Cited Work",
  element: "cite",
  classes: [], // kept for backward compatibility but deprecated,
  attributes: {
    ...
  }
 }

---

If you'd like to see this improvement implemented, add a 👍 reaction to this post.

[mmichaelis]

While I like adding more flexibility, such a feature would increase the footprint of issues such as #11748, where it is about classes being (accidentally) removed, if used twice for two style configurations. Just to complete the idea of a possible issue: What about overlapping attributes when removing styles? For the dir attribute example, having two styles active which set dir attribute, we have to ensure, that the other dir attribute still remains set.

Just to continue, a possible issue just with the (very simple) dir attribute: What if two styles set different dir attributes (note, that there is currently no exclusive mode)? "Style A" sets a class "style--a" and dir to ltr. "Style B" sets a class "style--b" and dir to rtl. What is the activation state for an element <span class="style--b style--a" dir="rtl">?

And: It raises clashes with existing features such as Text part language for the given example dir attribute. Or clashes with font size, font family, etc. feature, that sets corresponding styles.

IMO, sticking to classes for this feature is perfectly fine... although the name (Style plugin) is somewhat misleading then.

[semiaddict]

Thank you @mmichaelis.
That makes total sense, but how did v4 manage those conflicts?

[mmichaelis]

That makes total sense, but how did v4 manage those conflicts?

@semiaddict, rough guess: It would also have issues with it.

Having a look at the corresponding CKEditor 4 feature, it may make sense adding the attributes section... but as recommended by me in #11748, a clear note should be added to the documentation that conflicting configurations must/should be prevented and that explicit plugins (like text part language) are favored over managing corresponding attributes via Styles feature.

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[Luu97]

Are there any news on this?
We are looking for a solution to add inline-styles with the style-Feature while migrating from v4 to v5.

For block-styles we found a solution using the headings-plugin, which supports ViewElementDefinition to set styles.
For inline-styles we found no solution to avoid generating css for the classes. For our use-case css-classes are not viable.