Relative styling parents

I think it would be useful to add the ability to add a parent selector inside relative styling. For example, if I have a .dark-mode class, or something similar, on the body tag, then the relative styles below would do something.

Right now, I think we can select the body tag separately and do this with relative styles, but it would be cool to be able to add it on a child element.

This is what we can do now:
.current-selector > .child-element

What would be cool is to be able to add a parent:
.parent .current-selector > .child-element

Hope this makes sense


Excellent idea!
This would solve a couple of issues at once, at least for me.
Happy to elaborate if anyone cares :face_with_peeking_eye:

Oh! Having the rules go either way is a superb idea that hadn’t crossed my mind in this way.
Love it and will definitely look into adding this.


1 Like

Was focused on the live stream, so will give more details now.
I have 3 different things on my list, but in addition, the case @msguerra74 described is also only achievable with Custom CSS and I also faced limitations in this kind of scenario.

  • Would solve this issue: Modal - Relative Styling

  • Would solve this issue: Relative Styling - Folders

  • Let’s say you toggle a class with the help of the interactions feature and assign this class to Element A.
    This will trigger a style change to Element B. the Relative Styling would look like .element-a.toggled-class .element-b
    I now have to manage the style of Element B from 2 different areas. Default styling from the Element B area, but with the class toggled, I need to manage styling of Element B from Element A’s area.

I hope that makes sense.

Yes, I ran into this when implementing dark mode on my site, where I needed to target the “dark-mode” class higher up the DOM in order to restyle certain elements below. I used custom CSS for now, which is no problem, but it’s nice to use the visual tools so most of the styles are together in the elements where they reside.

1 Like


Very underestimated point.

1 Like

Any chance we will see this in the near future?

Managing Relative Styles from the 1st level (or a parent) block is something I tried in the past but isn’t a real solution for me.
I’d still have no direct access to parent containers of certain blocks.

After the block defaults removal and the upcoming removal of the auto-generated default classes, this is the only thing which stops me from starting a professional project.

For me, it’s an essential thing. It would just take too much time to build things with Relative Styling and then translate everything to a better implementation, if this will be a thing at some point.

So maybe going with the Code Block in the meantime? Not the best approach, but would make things easier to manage Relative Styles per block or section basis?

Just trying to find out which route I should go without this option.
Any suggestions?
What’s your current approach, guys?


Hi @Marius,

It’s definitely on the cards, I’m just waiting for a little free moment to put this together so that “either” sides of the block class can be customised with rules.

It is something that is lacking currently, although I am also considering global relative styles, with custom rules as the selector so that the visual experience can be applied to not just classes.


Thanks a lot for your reply @Louis.

Great to hear an official confirmation.
With that in mind I can look for a temporary workaround with confidence which makes the translation more convenient, once it’s available.

The 2nd part sound quite interesting and exciting.
Curious how this can be implemented and how it will work in the end.

Patiently waiting for this particular update.

Thank you so much for making this available @Louis! :partying_face:


Just a quick feedback/question:

Wouldn’t it make more sense if the combinator of a before selector is placed after the selector itself?
Contrary to the after selector, which is oriented towards the previous selector or the block class itself, the before selector is oriented towards the following selector.
Currently, the combinator of a before selector needs to be set to same set to achieve valid CSS, it fulfills no purpose.
In addition, in most cases the current behaviour is forcing one to add an additional empty combinator to achieve the desired CSS, two rules are required to setup one class properly.

I might miss something here or maybe something will get added in the future, so it makes more sense why it works this way.
A quick explanation would help me to understand things better.

After selectors are not removable entirely, shouldn’t this be the case now?
Adding nothing and leaving it as undefined won’t make the Relative Style work.
Also, when adding an empty combinator to remove the undefined class, it doesn’t work either.

I’m not getting it to actually work on my end. It adds the parent selector to the child selector (.parent.child > .class). It is showing the “before” combinator before the parent selector, like @Marius said, so it seems like it’s backwards unless I’m missing something too. Haha, either way, I’m very happy to see this, once I can figure it out!

Did you make any progress @msguerra74?

Nope, either I’m not understanding how it’s supposed to work, or it’s not working correctly. All of the parent combinators get placed before the parent, so it’s smushing up the parent selector with the child selector (example: .parent.child). If I set the parent to descendant, I would think it would add a space between the parent and child (example: .parent .child). I think it’s adding the combinator before the parent because when I do a child selector, it’s outputting it like this (> .parent.child) instead of this (.parent > .child).

Hope this makes sense, but it’s how it appears to be working for me.

Hey there @Marius and @msguerra74,

The before rules are a bit counter-intuitive I’ll admit, but we didn’t want to stray away from the after rules order.
They should work independently from each other, and I’m surprised you’re both experiencing the same issue of not being able to apply the styles. I’ll try and set up a demo install and share it here.

All in all, this confirms that a simple text input with a dynamic {class} selector seems the way to go. We initially introduced the optioned ruling to help users out, but I see that it is more confusing (and time consuming) than anything else.

What do you think?

1 Like

Ok, I played around with it some more and I think I got it… haha… Maybe I was missing the step of adding the descendant combinator as a separate rule on the “after” section.

This seems to be the correct way:

Originally, I was trying it all on one line thinking it would work differently.

This seems to be the wrong way:

Am I doing it right now? lol, sorry @Louis!

@Louis, thanks for the reply.

I understand there is a need to remain consistency to give people a better understanding and don’t add confusion, but at what cost?

Just the most basic example I can imagine. I want to change the style of my current class when another class is toggled on a parent container. .blockclass

Do I really add 3 lines inside the Before area?
And then another one inside the After area?
My understanding is the same as @msguerra74 shows in his example above.
It’s not that bad as our first posts might suggested, but at least minor tweaks are needed in my opinion.
At least, that’s my first impression. I’m confident I will get used to it though.

This is my example:

Maybe it would help to remove the combinator field on the first before line, but that would interfere with the re-order option, I’m sure.
Is there a case where it would make sense to have this option?
To remain consistency, it would also be fine to mute it instead of removing it.
In addition, removing the default (and not removable) 1st after line could also improve the experience.
Everything could be blank when a new Relative Style is created. If you think, the default after line is necessary to give the user a better starting point, why not give an option to remove it at least?

You are right, when using Relative Styling a lot (especially when building more complex stuff), it becomes quite time consuming, because of the way it’s designed.
The way how to build the classes “visually” is something I actually enjoy, it’s just not that efficient I wish it would be. But I’m not sure if there is space for sufficient improvements in that regard.
This was pointed out here and there in the past by other users, but you always stated that there are no plans to change the way it works. One point you mentioned, was to prevent user errors.
I accepted it and never added my own opinion.
I want Cwicly to be accessible for everyone and I have no issues to make compromises.
It still is fine for me, and I appreciate this feature from day 1.

I think this is the way, a lot of people who uses this feature frequently, are dreaming about.
Wouldn’t a dynamic selector give access to non-accessible selectors as well? E.g. Modals, Sliders, etc.? If I understand you correctly, this will solve another issue.

As mentioned above, I totally understand the reasons behind your initial vision, but in its current state I think it’s more confusing than it helps.
Again, nothing wrong with it in general, just some minor improvements would be appreciated, in case the solution you suggested won’t make the way.

I’m all for sticking with your vision @Louis because I trust it’s a good one. Originally, I was thinking this could be done with the normal relative styling interface with, like you mentioned, a simple text input where we add a selector that would just appear before whatever is set in the relative styling panel.

Usually it’s just a class or something that we don’t easily have access to inside the builder, like a “dark mode” class on the body, or something similar. A simple input would give us the ability to add in a simple class like “.dark” or more specific like “body.dark”. It would also give us the option to add more complex selectors like “#hmm .this > .is-very + .specific”. Then is would just prepend that to the relative styles selectors.

Either way, as long as I know how it’s supposed to work, it’s all good. I just wasn’t sure and the documentation doesn’t cover these new features, so it took some playing around with. I don’t mind figuring things out, but sometimes I don’t have the time to tinker as much, so it’s nice to be able to get in and get stuff done as “cwicly” as possible… <== see what I did there :sweat_smile:

1 Like

I can agree with every word of it, especially the first line :muscle:

In case this gets overhauled anytime soon, it’s all fine for me.
If it remains, could you please add html and body to the type selector list @Louis?
Didn’t make sense to have it in the past (well now, it does) and I hope I didn’t overlook it.


1 Like