Ability to design header at top different from header not at top

We had a lengthly discussion on that here Relative Styles for submenus? - #10 by FZwo)

It should be possible (like in any advanced theme, there is the difference labeled as at top vs. on scroll) that the header and ALL elements of the header could be styled differently at least “at top” vs. “not at top”. This seems currently not achievable, or it is achievable only with several days of trial and error with the different scroll selectors and different attempts with relative styling rules (I did not succeed with that). There are currently several problems with that:

  • relative styling rules on upper level are overriden by settings (if set) in the inner elements they are addressing
  • there is no such scroll selector as “.cc-scrolld-not-at-top” (to be MECE (mutual exclusive and collectively exhaustive) together with .cc-scrolld-top)
  • I found no way to address the typography of submenu items via. relative styling rules (I only managed to address the background of a submenu)

Can’t see how this is not possible.
There might be other ways (I didn’t check opportunities), but when there is a “.at-top” state, there is also always a “:not(.at-top)” state via pseudo class.

I couldn’t follow what you were about to achieve, so I didn’t reply on your linked topic.

As described at the linked post, the one usecase I tried to accomplish was:
The header is general* ly set as “scroll-down → slide-up”

  • Overall header is transparent at top, and takes its background color otherwise (done)
  • Submenu background colored different at top than otherwise (could be accomplished with rules addressing “.cc-menu-dropdown” and type “li”, but only if the regular background settings of the submenu are not set, otherwise they are overriding the relative styling)
  • Typo settings of the submenu items should also alter, but they could not be addressed within the same rules as above, if they could be addressed this way at all I don’t know)

If you have any ideas to accomplish that via pseudo classes, very welcome. But if so, it is still a very cumbersome set-up if this is successful that way

It appears to me that you have trouble to find the proper Realitie Styling rules, which includes potential issues with specificty.

You might want to have a look at this feature request.
I think that’s exactly what you are looking for.

Sorry for not being more helpful for now.
I might return to help you out at a later point in case you are still struggling.

Could be that one of the problems (for me) is to find out what the existing selectors/ classes are to be addressed via the rules of relative stylings to achieve what

And of course you are right, I am not used enough with styling rules, that’s true

You could also change the general approach.
Instead of changing things on scroll, make the scrolled position your default styles.

And when not being scrolled (this is the selector that you already have and that works for you if I understand you correctly), apply your desired styles there.

From there, the things which do not currently work (and if they still not work then), could be addressed and fixed in no time I’d assume.

That’s what I already tried to accomplish, but there is the priority / overriding issue:
relative style added to top container:

this is the respective rule to it:

And this is the setting (as standard):

The relative background style is only applied when the initial background color settings of the submenu target are empty. When not, there is no effect

Next is the challenge, that the at top Typo settings of the submenu items could not be set this way (as far as I experienced)

Your rule can’t be right, as there is no direct child of a list in the section block.
The only direct child that can exist is a div and that’s the inner section container.
So your styles are not overwritten (even though a high specificity is required), they do not even exist, as they are not applied.

This is how styles are applied to your submenu when using the builder interface.

.menublock .cc-menu-dropdown

So something like this should work out for you:

.sectionblock.cc-scrolld-top .menublock .cc-menu-dropdown

Hope that helps for now.

Just hopped into the builder to check things and made a few adjustments.
Didn’t check your specific case, so please let me know if it helps.

I do prefer to manage my styles from the block which is actually styled or changed by user interaction, so everything is in one place. The default styles and the additional styles.
You could consider this too by using the before rules inside the Relative Styling modal.
Not a must of course, just hinting a different approach.

If I got you right, I now did the following setting (which does not work):
At the menu block:

And no change to this setting at the top section (the header), which already works as intended:

Try something like this at the menu block level:


First of all, many thanks for that great help!

Implemented that exactly as your example, it works now half the way:

  • The hover Background color set with this relative style is now applied to the submenu dropdown at top of page
  • The regular settings of that submenu are now appearing when leaving the top of page as intended
  • The text and link colors (no matter if set at normal, hover,…) set with this relative style do not apply to the submenu items, no matter if set there in general or left empty

Conclusion: a first step is made, I am able to modify the background of the submenu, that is something I can start now with. What I am not able to address via the above rule is the submenu item (link) and background color, and moreover not to talk about these settings in normal and hover mode…See screenshot of what settings I am talking about:


Your rules might be not specific enough.

Yes, there is: :not(.cc-scrolld-top).

Yes there is, just be sure to target the a tag because li is not enough.

And if you don’t want custom/specific classes/styles to interfere, be very specific like:
nav > ul > li > ul > li > a.

There are also very strange things in your screenshots:


Why are you manually setting those virtual classes???
There is some strange '..' before the first one.

oh, thanks, I took these already existing classes out, now header is much better displayed within the editor. But behavior and findings remain the same. I will try to pick up your hint for more specific definitions, thanks!

Araminta also recorded a video for you in the other thread. Just in case you didn’t notice already.

1 Like