Cwcly latest version: 1.2.9.2
Hi! I’m not sure if this is a bug. I tried inserting !important via Quick Code, but it didn’t record it.
I have a relative styling for the block—the category’s BG colour changes when I hover over the parent div. I also want to add the category’s button BG colour to change when I hover over the category itself. So, I wanted to add !important to inherit it but adding it via Quick Code failed.
Looking forward to hearing from you.
Hi @jornes,
There are no !important rules in Cwicly blocks currently, so !important will have no incidence when added to Quick Code.
Remember, Quick Code is a direct integration of the Design tab properties, what isn’t available in there won’t be applied.
Moving to General.
Alright. Noted. I will add it to a stylesheet or custom code at the setting section then.
But your comment about !important is important 
Definitely something that is going to make its way in the visual/quick code interface and style engine at some stage!
Thank you!
I think adding !important in the custom CSS field is good enough. Otherwise, you will need to add it to every design option. Or maybe you will think of the best solution for it when you do it later.
Hi,
Jumping in because I have some class specificity issue…
As Cwicly block settings are assigned to block class, some of my custom CSS takes precedence over them. Here, my custom .cc-btn padding is more specific than the UI block setting, which seems wrong to me.
With some other builders, block settings are set on ID instead of class, which makes them more specific, but I’m not sure that ID styling is really the best solution.
Nevertheless, as we can’t use !important in block settings, I can’t simply override my generic button style.
Is there a workaround for this?
What do you think of this specificity ambiguity with class styling?
Is it something happening not too often, so we can find workarounds for specific cases?
I would tend to say that it is a design flaw regarding CSS philosophy, but I only had to deal with it once or twice while building a site.
Not quite. I think it’s more that button[type] is more specific than your class… That specificity seems wrongly placed here.
As long as one takes care of the stylesheet priority/order, I can’t see any issue with Cwicly.
And since we are in full control of specificities as well, even within the GUI for a no-code approach via Relative Styling, it’s up to oneself deciding how to manage styles properly.
I can’t see myself using !important once, when it comes down to pure CSS rules.
You could be right here, but that’s not something to blame Cwicly for, I guess 
Oops my bad false alarm, you’re very right, removed [type] and it was OK
Actually removed button as well, since my menu icon was targeted (this selector came from older sites where I had some external button tags I couldn’t alter).
I tested some different situations and everything seems to be in the right order.
And I have to say that Cwicly is a real pleasure to work with regarding CSS. It is clean, base is very sober and neutral, and everything seems respectful of standards (accessibility included), no invasive or senseless stuff, no complicated or twisted mechanisms
All my customizations have been easily integrated without pain or !important, and by the way I simplified my own framework a lot compared to being used in Bricks or Oxygen 
So thanks and congratulations for this, this precise point made me jump to full LTD (well, the whole Cwicly is awesome, but this part, I mean solid CSS foundations that can be relied on, is crucial to me).
Well I was talking about Cwicly CSS philosophy, but it was based on my selector error, so forget it 
As for the CSS ambiguity between two selectors of same specificity, well I can work with that, just needs discipline
