Further adventures in CSS

[triskellian]

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?

Comments

Danger, Will Robinson!

[wimble.livejournal.com]

The order in the stylesheet is frequently irrelevant. What you need is the specificity of the rules.

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!

[wimble.livejournal.com]

Oh. See what you mean: not only do they appear when the second level is hovered, they also appear when the first level is hovered, which you don't want.

Ok, I'll look further.

Re: Danger, Will Robinson!

[wimble.livejournal.com]

Right. I'm not sure why your version doesn't work. But I've fixed it.

Change the li:hover ul selector into li: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!

[triskellian]

Thank you! That was what I thought was happening, but I didn't know about that use of >. Hooray!

Re: Danger, Will Robinson!

[triskellian]

And now it works for multiple levels of nested lists, with no extra code required at all! How very cool :-)

Re: Danger, Will Robinson!

[chrisvenus]

I've not read the spec but I certainly noticed when doing some stuff before that li ul seems to not care too much if there are some other tags between the li and the ul. It just has to be a decendant rather than a direct child or something. Can't be bothered to read the spec now to find out if that is how it should be, a bug or undefined.

Re: Danger, Will Robinson!

[wimble.livejournal.com]

A selector of 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!

[triskellian]

I think this all makes sense to me now - you introducing me to the > made it all slide neatly into place.

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 onebyone>.

Re: Danger, Will Robinson!

[wimble.livejournal.com]

Found my misunderstanding.

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!

[triskellian]

The order often does matter with pseudo-classes, but my reading of it was also that the second was more specific. Trouble is, it's not working, in either Safari or Firefox (Mac). Can you have a look for me? The page is here and the CSS is here. Thanks!

[chrisvenus]

Oh, and in answer to the HTML comment that says "the navigation bar has to appear after the content div, to ensure the pop-out menus appear on top of the content div when they display":

Isn't that what the z-index thingy is for? There may be a reason not to use it but if it can be used then it will potentially make pages a lot more useable since you can order the menus and stuff so that they look good on browsers that ignore the positioning (ie you might want your nav at the top of the page for old crappy browsers but your layout gives it at the beginning.

[triskellian]

So much for you thinking I'm the CSS whiz ;-) I'm making this stuff up as I go along!

Z-index does do that, but I've never used it. Remember, I'm only doing this stuff for me, so while I know there are all sorts of other things I'd be doing if I was making a page for general consumption (such as the aforementioned JS to make IE behave), I'm currently ignoring them. Oh, the joys of making web pages solely for reasonably standards-compliant browsers!

[onebyone.livejournal.com]

It's probably worth pointing out that in this particular respect IE is standards-compliant, it's just that the standard (sucks|doesn't do what you want).

Maybe CSS 3 will be better.

[triskellian]

But "sucks" == "doesn't do what I want" ;-)

And my impression, from your comment yesterday, and from some wandering around the specs last night, is that none of them are exactly non-compliant, it's just that the standard is not explicit enough.

But, OK, I'll change my jubilation to 'Oh, the joys of making web pages for two different browsers that behave roughly the same way!' ;-)