Open mmichaelis opened 1 year ago
I second this and find this feature, that has been worked in CK4, absolutely necessary
Anything new here?
Maybe you can add a internal function that converts a definition like this: { name: 'Special Color', element: ['h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'p', 'span'], classes: [ 'specialcolor' ] }
internal to the expected format: { name: 'Special Color h1', element: 'h1', classes: [ 'specialcolor' ] } { name: 'Special Color h2', element: 'h2', classes: [ 'specialcolor' ] } { name: 'Special Color h3', element: 'h3', classes: [ 'specialcolor' ] } { name: 'Special Color h4', element: 'h4', classes: [ 'specialcolor' ] } { name: 'Special Color h5', element: 'h5', classes: [ 'specialcolor' ] } { name: 'Special Color h6', element: 'h6', classes: [ 'specialcolor' ] } { name: 'Special Color p', element: 'p', classes: [ 'specialcolor' ] } { name: 'Special Color' span, element: 'span', classes: [ 'specialcolor' ] }
That should not be RocketScience and make config styles a lot easier.
There is also no way for a workaround by making the assignment for all elements separately, as all assignments are always displayed regardless of the selected element.
@almfisch's proposal only removes some manual work, but doesn't solve the issue: there will still be many style buttons doing the same thing, just one button for each type of element it is allowed for, still bloating the UI and making for terrible UX.
An element of "*" might also be interesting, so that the custom class gets applied to any (block level) element (closest).
Also still waiting for this feature. Is there a good reason not to do it?
📝 Provide a description of the improvement
The suggestion is to have a configuration such as (taken and extended from config example):
This would decrease duplication for such scenarios and would be one way to reducing the impact of:
12770
which would, for the workaround of adding all elements one by one, bloat up the UI a lot.
Note, that such multi-element approach may make sense only for block-elements, as (unfortunately, from my point of view, as it raises other already reported issues) for inline elements also the inline elements will be created (instead of also applying only to the matched element). Thus, a configuration like this would be ambiguous:
and, if allowed, would require a clear contract like: The first element wins.
📃 Other details
If you'd like to see this improvement implemented, add a 👍 reaction to this post.