ckeditor
Is having `definitions.xxx.classes` mandatory by intention?
📝 Ask a question
Having a configuration like this (asking for the context of a default TYPO3 implementation):
editor:
config:
style:
definitions:
# block level styles
- { name: 'Orange title H2', element: 'h2', classes: ['orange'] }
- { name: 'Orange title H3', element: 'h3', classes: ['orange'] }
- { name: 'Quote / Citation', element: 'blockquote', classes: [''] }
- { name: 'Code block', element: 'code', classes: [''] }
# Inline styles
- { name: 'Yellow marker', element: 'span', classes: ['yellow-marker'] }
it seems that classes is a required attribute. Also https://ckeditor.com/docs/ckeditor5/latest/api/module_style_styleconfig-StyleDefinition.html does not really mention it as being optional. Leaving such an attribute out leads to the dropdown for styles not getting opened.
If the attribute is required, I wonder how one could implement an empty <code> element. Currently, always <code class=""> is emitted.
Also, when using classes: [] to indicate an empty array, the element is not choosable at all. Using classes: false|null|true only leads to having <code class="false|null|true">.
So I wonder, am I missing something here, or would it classify as a bug?
For now Style dropdown doesn't insert elements, it just adds classes to existing elements. Most likely, you would want it to insert as well, +1 the following ticket #14372.
The issue lacks the feedback we asked for two weeks. Hence, 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.
Just let us know if the ticket we sent is something that covers your need, and we will close this one as a duplicate :)
Ah I see! I just saw this as related, not a duplicate.
If I understand correctly, the other issue is about properly getting the "context" of the style dropdown and allowing to insert new elements when inside the context of another?
My issue here is about the ability to insert "pure" elements, without requiring an (empty) class selector.
IMO those two are distinct issues, but then again I'm not deep into the code 😇
Then I wonder why not use a proper button of the feature like code? Multiple access points to insert the same thing could be confusing, and I'm curious what's the use case and your thoughts here.
The reason is to group style-related custom choices in a single "point of truth", which would be the style dropdown.
Also, emitting <div class=""> as it is currently really looks odd and more like a bug than intention.
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.
Yes I still think there is a use case for it and an empty class (=no class attribute) would be beneficial. Happy to hear feedback on my last post/comment.
I'm trying to maintain CKEditor foe the TYPO3 Core so I would need a more "final" say for this to be able to communicate to our community, because every now and the I need to point people to this issue. Thanks!
There are a couple of things here that we’re considering for next year’s plan (cc @Reinmar).
The current Style feature needs a rethink. It’s based on the GHS compatibility layer, and this coupling makes it difficult to evolve. The entire premise of inserting new elements wasn’t part of the original design. At the same time, we want to improve HTML interoperability, e.g. div support (#6462), and possibly extend it in other directions.
I believe @niegowski once proposed flipping the architecture, where editor features would register themselves with the Style feature to define what attributes to apply, and in turn, the Style feature would know what to insert.
All in all, the topic is in our head, but no precise plan yet.
Thank you, that helps me a lot. Feel free to close this issue then if it's part of something else to address. I'll notice it then :-)