Hi, community)
I have a div, with a red background, when I add an additional class and set the background to green, but nothing changes.
I think according to css rules the last property should be taken. In webflow the logic was exactly the same.
I can change other properties, but if the property was used by the main class, the additional class doesn’t change it in any way.
Help me to understand the logic of work.
Hey @DenisKozeev.
Cwicly’s stylesheets are loading in this specific order:
As you can see, block classes (#6) always will have the highest priority. That’s the reason why it will override the styles of the global class (#5) you applied to your block.
Thanks for the clarification. Then I have to plan the construction differently.
Let’s say I had a white card before. I duplicated and made several of them. I added an extra class to some of them and changed the colour to what I wanted. And if I changed the size and typography, these parameters changed everywhere, but the colour was different.
Here it turns out I need to initially make a card without colour and only then duplicate and fill in the values.
Or what is the logic of work? It is difficult to rearrange from the usual scheme))))
I know about components, here we are talking about simpler things when you need to change one parameter for contrast.
And another question then that doesn’t beat the order.
I have filled Global Styles → Elements Section and Container.
The section has a white background. But when I add a global class with a black background to this section, the background again does not change but remains white. Although according to the hierarchy above it should change.
There is no right or wrong way to do it, I can share with your our standard approach as an example.
We use a modular semantic method using global classes for most blocks.
Example:
A button that can be primary (e.g. “Submit”) or secondary importance (e.g. “Cancel”).
We create our global button class (e.g. .btn) that can be applied (either using global styles or a global class).
We then create a global class for each of the semantic variations: (.primary and .secondary), these can have whatever colours or styles are appropriate to override the base button.
Depending on the use case, this can also be done by relative styles. For example, before dark/light mode was built-in to Cwicly we were using our own version of this using relative styles.
As of 1.3 as you mention, using Components to wrap up this logic is ideal and simplifies the user experience for non-technical editors.
The only times we use block classes directly are when there are standalone elements that will not be overridden (e.g. in the header/footer).
Thank you for the example of work. I realise that the logic of work can be different, but it is important to hear the scheme of work from more experienced people.
Quickly threw together an example according to the above description. And it seems to work with the logic that I need.
If I reproduced it correctly, of course)
Looks great. As mentioned, this can also be combined with global styles and relative styles as needed.
We have used this strategy on many sites and it has continued to work consistently across the various improvements and enhancements added in Cwicly versions during the last year, so we can testify to its effectiveness in that sense.
The key advantages to using global classes for this are:
Block classes are fine to use if:
