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.
Example:
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
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.
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.
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.
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?
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.
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.
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!
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.
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.
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.
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.
.parent.open .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.
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
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.
