Virtual classes do override block classes if the block which holds a virtual class is placed before the main block (where the original styling is coming from) in the DOM/Navigator.
Tested with several properties, nothing worked.
Not sure if it’s even a bug, might be the way virtual classes are working (now?).
v1.2.1.4
This makes sense to me because all three are simply block level classes. That means they all get added to the same stylesheet, and priority is determined by whatever comes later in the stylesheet.
That means level of priority goes:
All your blocks in order.
I can’t help but ask - why not use a global class in this scenario? It would instantly solve your issue.
If it’s because you don’t want those classes added to your global stylesheet, then yeah you’d need to try avoiding setting conflicting styles. Alternatively you could enter the CSS manually with more specificity instead.
*I’m not sure if this would’ve occurred on previous versions or not. Block classes would’ve been saved to cc-main.css, and I don’t know if they got added by creation date or by DOM position.
Either way, the general logic is the same as before, but it’s possible that the outcome might be different just based on when block styling gets added to the stylesheet.
What @sunny said is spot on.
The order of appearance of the blocks is what we use to construct the cascade of styles and selectors.
In this case, you would apply all common stylings to column 1 and then modify the others from there.
This is how Additional Classes (now Virtual Classes) would have acted. The logic behind this hasn’t changed.
Virtual Classes don’t add any rules or properties to the stylesheet, they are simply references in the class attribute for the specific block.
Thank you @sunny this makes total sense and it’s the exact way it should work!
I was just a bit confused because behaviours changed, that’s all, I guess.
It was not, this is where my confusion came from in first place, but I rather wasn’t able to put one and one together in this case.
Thank you @Louis as well, conforming what @sunny is saying and the additional and useful info.
For some reason, I can’t explain why though, I thought that there is some complex logic behind which handles the order of the classes, depending on where they are used to make sure the cascading behaviour won’t conflict anywhere.
It’s good to know that nothing changed in that regard, it’s only how classes are handled now within the various stylesheets.
I can’t see any potential issue on my side how this will affect my workflow - the opposite is the case. It makes more sense now, and I can see all the benefits which comes with the class system overhaul. It feels more native and natural now (much closer to hand-writing code experience).
But it was important to me to get a confirmation on how things work in this case.
I changed the title and the category to avoid any confusion for others.
The tag could be changed to discussion.
Thanks again!
