Not sure if this is a bug or awkward UI, but I was trying to change the hover colour for links within a paragraph.
Instead of applying the text colour to .paragraph a:hover, it applied it to .paragraph:hover a - even though I was editing the relative style.
That’s correct behavior.
You need to add the pseudo state inside the Relative Styling rule.
Pseudo states from the dropdown will only be applied to the default RS class itself.
If that’s correct, it feels awkward.
It means there’s two separate ways to add hover styling - which would definitely be confusing to newer users if I still was confused by it.
The psuedo selector should also be removed inside of relative styles if that’s the case:
Is there a reason that it wouldn’t work that I’m not thinking of?
P.S. And to be clear, I’m not suggesting removing the pseudo classes from the relative styling options.
I just think if you style hovering one way, it should work for all elements.
For me, it makes absolute sense, and of course shouldn’t be removed.
Let’s take your example.
You have a .parent .child RS rule.
In your case, you need to add a 2nd RS, when adding the psuedo state to the child element.
But what, if you want to add it to to the parent element?
You would force users to add a 2nd RS, when they can use a single one for the default and hover state?
Making it work like you have in mind would alter its core behavior, which would be even more confusing, plus it would remove some flexibility.
Hmm, I’m not sure I follow.
This is what makes sense me to:
Adding a relative style should take care of being able to style the “.parent .child” selector.
If you have the parent item selected, choosing hover from the drop-down should add “.parent:hover” styling.
If you have the relative style child selected, choosing hover from the drop-down should add “.parent .child:hover” styling.
If you wanted to style “.parent:hover .child”, then that’s when you’d need to include hover in the relative styling selector because you’re not actually styling the hover state.
Did I miss your example?
The pseudo state dropdown list is totally independent of Relative Styling.
For me, this is the correct and expected behaviour.
It only respects the actual class (the one you see inside the RS rule modal), you are currently editing, whether it’s a block class or a global class - and not the RS rule itself.
Don’t get me wrong, I totally understand your point and know what you are up to.
Maybe someone of the team can add some more info here to clear things a bit.
In case it’s feasible, why not add an option to alter the behaviour?
Yeah I think if the current behaviour is going to stay the same, at the very least the drop-down icon needs to be removed.
It suggests that it IS how you edit the hover state of the relative style. From the user perspective:
Of course there is still the drop-down in the top toolbar, but at least it doesn’t as directly suggest that that’s how you edit the hover state.
+1 for a more clear UI in that regard, in case everything remains as it is.
In fact, I really think that’s necessary.
But I have to disagree in removing elements from the interface where I’d expect them and got used over the time.
It still fulfills a purpose, and using the top bar isn’t convenient at all, especially when working on Relative Styling, where you stay exclusively inside the block inspector.
Pretty convinced that there will be a smart solution in the end.
Anyway, thanks for bringing this up @sunny.
Probably gonna help users taking advantage of this powerful feature in an even more efficient and clear way.
Hi @sunny,
I get the point you’re making and it makes sense, although you are applying your own logic (which could also seem awkward) to this specific matter.
This is all about Relative Styling → styles are only applied to an element relative to its parent.
With that premise in place, the pseudo selector always affects its base element in Cwicly (whether a block or a global class) → wouldn’t it be counter-intuitive to suddenly change that behaviour and apply the pseudo class to a “virtual” relationship when styling an element relatively from a base class?
Isn’t relative styling more about:
If I’m hovering over this parent, then change the background-color of its child div
Than:
If this parent, then change the background-color of its child div if I’m hovering over the said div
Now, having said that, a pseudo selector for the specific rule in place sounds like a great idea, and sort of necessary when looking at example 2…
Thanks for the explanation @Louis, that makes total sense.
Sometimes, it just requires some additional details to understand the process.
When exploring the pseudo selectors in the Relative Styling panel, I had to check things on front-end, to see what’s actually going on there, so I totally get @sunny’s point here.
In terms of the example, I think he just tried to increase specificity, not applying changes on parent hover.
Another use case of this versatile feature, which I also take advantage of since the before selectors were introduced.
Didn’t think about an additional pseudo selector for individual rules, but that might be something which is actually needed, I guess. Curious how this gets implemented.
That should make things more clear and avoid confusion in the future. I’d assume it also improves the workflow.
Looking forward to this potential addition.
Any improvement is welcome, as I use this feature a lot.
Thanks!
I see what you mean about looking at it from the parent element. Funny enough I checked to see how I accomplished example 1, and this is what I did:
Yeah, maybe some ways to clarify the proper workflow here. Even if in the interim it just meant adding a tooltip saying you need to style the child hover state by adding the pseudo class in the relative styling selector.
But even with this new knowledge, it still doesn’t feel natural to me that editing the hover state inside of the relative style child element affects the parent. Again, mostly because everything else is pertaining to the child element. Just something to think about 
To clarify, I actually was applying changes. In this case: when hovering anywhere on the card, the featured image’s (inside of the card) box shadow expands.
