It is certainly possible to address this issue by incorporating an input parameter into the block and binding the input to the Style Classes within the first child div.
However, the problem arises from the fact that the parent element (let's call it the block div) has its own default class with inline styling for the display property.
While there may be a valid reason for this default class, it could potentially create difficulties later on. For instance:
When using flexbox layouts with maximum widths for the children, the desired outcome of having all children fill the width while capping it at 25% would not be achieved because the 'block div' is in the way.
Therefore, it would be beneficial to have more control over these situations in order to avoid the need for workarounds like the ones mentioned above.
I realize that this is a very specific use-case that I am highlighting. But there's plenty more usecases where I might not feel the need for:
- the default class added to blocks
- more code at different places
And would love:
- Control over generated code that directly impacts the DOM
- More extensibility to the blocks without custom workarounds with input parameters
- A cleaner widget tree with less excessive containers
- Centralised css, preferably reusing the existing classes at hand.