Using <f:spaceless> in layout for rendering any fluid_styled_content element causes valid RTE content to be be destroyed.
As pointed out here: #80695 <f:spaceless> removes too much whitespace in certain contexts.
Important here is, that RTE content potentially is such context.
Therefore I suggest to remove the <f:spaceless> from the layout
#11 Updated by Benjamin Kott 9 days ago
Removing the spaceless viewhelper is a massive change in behaviour during released versions that WILL lead to visual differences. Please see very very simple example: https://codepen.io/benjaminkott/pen/dQYwwy
This will make the change breaking, and so the change must atleast be marked as beeing that. If you rely on these to reduce for example spacing between buttons or other examples. You will need to adapt your templates and override the layout if you are currently not doing this.
In addition we reintroduce a lot of unnessesary bloat we tried to remove in the first place. That means if you are fine with the current solution you will now need to take additional actions to optimize the html output.
Means, whatever we will change, it will be breaking in some kind or another. This is why i prefer not to make any backports to older versions in this area.
But since v9.5 is almost fresh out of the door we can/should make an exception for this one. But i would still like to see an option that keeps the compression and the removal of bloat, but is handling block and inline elements differently/better.
#12 Updated by Helmut Hummel 9 days ago
Benjamin Kott wrote:
Please see very very simple example: https://codepen.io/benjaminkott/pen/dQYwwy
Well, yes. inline-block elements must not have spaces to avoid gaps when gaps are not wanted. In RTE context (or any context where basically editors control the HTML), inline-block elements must have spaces
I tend to say that situations where spaces need to be removed between inline-block elements are not controlled by editors, right?
I at least can't imagine a case where editors add a space and this space should be trimmed.
So when you don't want a CSS fix for this issue, you have to adapt your templates to not have gaps where you don't want one. But CSS fixes might be a tradeoff:
But i would still like to see an option that keeps the compression and the removal of bloat, but is handling block and inline elements differently/better.
If I'm not completely mistaken, it is impossible to decide on HTML level where to trim and where not (HTML parsing is hard enough), but since CSS defines which tag should be displayed as inline block,
we can't do anything on HTML level.