Backwards compatibility for flexbox gap?

Beta
#1

Love the addition of the Gap option for the Flexbox controls on divs, cells, columns, etc.

Unfortunately, without configuration, updating from Pro 6.4.x to 6.5.0 RC 1 overrides any gap I added through CSS, as it’s now explicitly setting it to 0px, with the element ID along with the Pro class (.x-col etc)

Often I have just added the gap declaration within the most basic $el { ... }, which is getting overriden by the built in .mcs31-0.x-col for example.

Any chance that when the value is 0, it could output no gap declaration at all?

I guess it serves me right for wanting to shortcut adding it without the class specific to the element type!

But my other gripe with that is that sometimes it’s useful to have CSS snippets that can be transferred from element to element without looking out for the element type (x-col vs x-cell, etc). Is there another better way to achieve this going forward? A different way to ensure that the CSS will override the element settings, but not be dependent on the element type class?

1 Like
#2

Actually, the bug is slightly different, and looks like it might not be fixable to be backwards compatible for this kind of thing.

This bug only occurs with the Column and Cell elements.

For the Div element (and H Flex / V Flex), the gap is being added to the plain .mcs58-0 styling, which is overriden by custom CSS with a $el { ... } declaration.

image
image768×312 26.7 KB

For the cell, it is within the mcs60-0.x-cell styling, which is not overridden by $el { ... }.

image
image770×734 68.9 KB

The same is true of the Column setup

image
image772×558 50.4 KB

I would guess removing the x-cell and x-column from the style declarations would cause a lot more issues.

#3

Yes I can try to check if the value has changed from 0 before outputting the gap CSS. Thanks for running through the RC. Have a great day.

On our end we probably shouldn’t be using multi class selectors, since they are so specific they end up overwritting custom CSS. This is probably in place to prevent plugins from breaking things, so I’m not sure I feel confident we should change that.