[Style dropdown] Improvements
Improvements to our Styles plugin:
Retention of styles
- [x] #14216
- [x] #11591
- [x] #11606
- [ ] #12777
Support for elements
- [x] #13341
- [x] #11577
- [ ] #12625
- [ ] #13778
UX
- [ ] https://github.com/ckeditor/ckeditor5/issues/14372
- [ ] #11579
- [ ] #12770
- [ ] #12771
- [ ] https://github.com/ckeditor/ckeditor5/issues/14946
Drupal uses the official Image plugin, but also has its own DrupalMedia plugin. This also uses a (block) widget.
What would allow Style to work for widgets? Because that is hard-blocking https://www.drupal.org/project/drupal/issues/3117172. I thought #11577 was the issue to watch, but it was closed 4 days ago: https://github.com/ckeditor/ckeditor5/issues/11577#issuecomment-1740794667. I'm confused 😅
Thanks! Allow me to share more comments on this (@Reinmar or @niegowski feel free to share yours). The original issue was too generic, and it lacked the very specific detail that should have been there: support for the current block widgets of the editor (tables, lists, etc.). Most of those were implemented, hence the closing.
Style dropdown [SD] operates on HTML alongside the GHS plugin. We cannot make it generic in a way, that it works with all widgets by default. Widgets are a layer SD isn't concerned about.
What we need to do is to make SD aware how it should integrate with certain features (and their HTML). That's why we need more specific feedback, which features lack such behavior.
And then, there are tricky parts. Images have their styling implementation. Should we duplicate it? Combine it with SD? Those are questions we don't have answers to yet.
Drupal uses the official
Imageplugin, but also has its ownDrupalMediaplugin. This also uses a (block) widget.
@niegowski any ideas how this could be done?
Most of those were implemented, hence the closing.
Most (table, list), but not all. Image in particular is very often requested.
Images have their styling implementation. Should we duplicate it? Combine it with SD? Those are questions we don't have answers to yet.
Ahhh! This is why Image is not supported!
ImageStyle does far more than just adding a class attribute. AFAICT the only desire is the ability to add a class attribute, without changing from block to inline or vice versa. So, I think this approach would make sense:
ImageStylecontinues to work as it does todayStyleplugin gains the ability to add aclassattribute value to a selected image.- For example, say we define a "Vintage photo" (class name:
vintage) style for<img>, which applies some CSS to do filtering. - If I select a right-aligned image (
alignBlockRight) and click the "Vintage photo" style, it would add to the existing<img class="image-style-align-block-right">and hence change it to<img class="image-style-align-block-right vintage"> - Upon removing a style: same thing.
IOW:
- "image style" is for image positioning, size, etc. These are all deeply tied to the image and hence appear on the image balloon only.
Stylefor an<img>is for addingclasses, just like for all other elements, and is virtually always presentational.
We cannot make it generic in a way […] I understand that. I'm not asking for it to work everywhere, "magically". I'm only asking for an API to allow other plugins to support it. Since you've done it for
Tableetc, it must be possible. But there's no public API — or if there is, it's missing from https://ckeditor.com/docs/ckeditor5/latest/features/style.html#common-api (really hoping it's "just" a documentation problem! 😄 🤓).
Imagein particular is very often requested.
Could you share some links to remarks about this? It would help a lot. I checked most conversations about the Style dropdown on our GH, and the tables and lists are the top comments, images almost do not appear. Even on the Drupal side img was mentioned once.
So, I think this approach would make sense:
Lots of those comments make sense :+1: I just keep in the back of my head the remarks on the need for SD to be visible directly on the elements as the better UX choice than the large list of styles. I'm also worried about the confusion of users that applying image styles would be in two places and discovering which is where. I think most people won't grasp the difference between the presentational/positional. cc @dagdzi
Since you've done it for
Tableetc, it must be possible.
Quick look at the code, it is. The new plugin was created to listen to the SD events to inform if the style can be applied.
I'm trying to make a custom block widget I created compatible with the Styles plugin. It's view downcast creates an outer <section> element that wraps a title and description div. It's very similar to the output that the tutorial for creating a block widget produces.
I'm trying to figure out if it's possible for me to allow creating a Style for the outer section element. In CKE4 I could do this by declaring the widget properly.
From reading the comments above, it seems like it may be the Style plugin that needs to be made compatible with my custom element, is that right? Does that mean I can't really do it without hacking the Style plugin?
Please bear with me - the linked example for how the Table plugin was made to work with this didn't help me much. For example, it doesn't have anything there about data downcast where I might need to concerned about combining standard CSS classes on the outer element with classes from the Style plugin. Or maybe I don't need to deal with that manually?
This improvement ticket has been open for over two years. Could you please provide an update on its status? Is there an estimated timeline for when this enhancement might be shipped?