![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Further adventures in CSS
I'm working on streamlining the CSS I was talking about in my previous post - some of it's clearly redundant, and there's no apparent reason for the third level to require a separate class from the first and second. But it's not working.
The problem is that the third level items are displaying when the first level is moused over, not when the second level is moused over. The reason for this seems to be that the first of these two bits of CSS is overruling the second:
li:hover ul { display: block;} li ul li ul { display: none;}
This is the order they appear in in the stylesheet, which should make the second take precendence, but I guess 'li' includes 'li:hover'.
The best I can come up with is that I need a 'no-hover' pseudo class for the second li in the second bit, but such a thing does not seem to exist ;-(
Anyone got any ideas?
Danger, Will Robinson!
If I'm reading the spec correctly, the two rules you mention have specifity 0-0-0-3 and 0-0-0-4 respectively, so the second should take precedence.
Um. Works for me: http://mrwolf.afraid.org/~tommy/triskell.html in Opera, or Firebird.
Re: Danger, Will Robinson!
Ok, I'll look further.
Re: Danger, Will Robinson!
Change the
li:hover ul
selector intoli:hover > ul
.I think what's happening is the dynamic effect of the hover: when it kicks in, *all* the ul's below that li were getting changed to block (although they shouldn't be). Adding the extra greater-than sign restricts it so that only the ul immediately within the li changes.
Re: Danger, Will Robinson!
Re: Danger, Will Robinson!
Re: Danger, Will Robinson!
Re: Danger, Will Robinson!
this that
means any that inside a this, without worrying about how far inside it is. Adding a greater than sign (this > that
) means that there must be no intervening elements.What I *think* is wrong here is that the second selector given should always override the first one (since it has four terms in it, rather than three). So the level 3 ul's should, in fact, never be displayed, even if the parent li is being hovered over!
However, that's clearly not what is happening, so there's something (I hope!) that I've misunderstood about the precedence of the cascade when hovers are involved. And once the precedence issue is understood, the behaviour does seem reasonably correct: all ul's within a hovered li get displayed.
Re: Danger, Will Robinson!
It seems to be something to do with pseudo-classes having their precedence set on a different scale from that of the rest of the stylesheet. After all, if, as part of this same page, I decided to fiddle with the visited link styles, even though that would only be one term (a:visited), I'd expect that to apply to all links, even those that have also been defined with greater specificity elsewhere. This also explains why order of appearance matters with pseudo-classes when it doesn't with anything else.
Of course, having said it makes sense to me now, some know-it-all is going to pop up and explain the crucial thing that I've missed which blows the whole thing apart <looks suspiciously at
Re: Danger, Will Robinson!
The examples include
:first-line
, which is a pseudo-element not a pseudo-class. And pseudo-classes have a higher priority. So the first rule has a specificity of 0-0-1-1, and the second is 0-0-0-4. So the first one takes priority (when the hover is active).Re: Danger, Will Robinson!