The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home Forums CSS Working Around a Chrome CSS Selector Bug

  • This topic is empty.
Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #33682

    Hi everyone,

    Basically what I’m trying to do is improve upon some of the CSS tabs that Chris has made. The biggest problem with them is that whenever you click on a tab you jump to the element of a corresponding ID (it uses hashtags) about which Chris said:

    “Also, hash tag links ‘jump down the page’ when clicked, so also note that that when you click a tab your browser window will pop down to have that tab be the top-most element (if there is enough room to scroll down on the page). Again, no fighting that without JavaScript to my knowledge.”

    Well, I’ve found a way with CSS. It does require one extra span per tab but I think that is an acceptable sacrifice considering it’s so unusable with the jump.

    What I’ve done is this:

    Tab 1
    Content goes here

    Tab 2
    Content goes here

    Tab 3
    Content goes here

    Tab 4
    Content goes here

    Then I’ve styled the spans with position: fixed; top: 0; left: 0; height: 0; width: 0; meaning they’re always in the top left of the browser window, which means that when you click on, say, Tab 1 the page will not ‘jump’.

    Then the following CSS is used to bring the targeted tab to the front:

    :target + * + div {
    z-index: 1;

    This works fine in Gecko (Firefox). Webkit (Chrome, Safari) however, is another story.

    Due to a webkit bug, webkit fails to correctly render anything with a :target and two or more + selectors.


    So my question is, is there a way I can work around this without using Javascript?

    Live example:


    You could/should actually be doing this:

    :target ~ div{
    z-index: 1;

    It’s works like ‘+’ selector except it isn’t limited the the adjacent element. It can be an element down the line somewhere. However, that will target all the following sibling divs.
    Unfortunately Webkit might fail at that too!

    I know that this fails in webkit. ( It works in IE7+! ):

    div ~ div:hover{
    background: red;

    I don’t really like webkit. Gecko is so much better with selectors and rendering box-shadows and rounded corners.


    Unfortunately you’re right (lol)

    The title of the bug is: “General sibling selectors and multiple chained adjacent selectors don’t work dynamically”

    The ~ has the same problem.



    I think it’s completely ridiculous. These bugs were reported YEARS ago. You would think that the fact that IE7 supports these same css expressions (not :target) would be motivation enough for them to get it fixed ASAP.


    Yeah, c’mon Google!

    Judging by the way it behaves though (It doesn’t just not work. Half the time it’s fine, just really slow) it’s probably quite a complex issue. However, three and a half years is still quite a long time to fix a bug.


    Okay, I’ve found a way around it, although I now have even more extra markup:

    Oh well, at least it works in webkit now.

    Anyway, I’m trying to animate them now. I’d already got animation working in Firefox before I started looking into the Chrome bug and so when I found the solution to that I just tried changing prefixes. Guess what? It doesn’t work in Chrome.

    So unless the webkit syntax is different to the gecko syntax, this is probably another bug (this one might be in gecko though, I don’t know). Any suggestions?

Viewing 6 posts - 1 through 6 (of 6 total)
  • The forum ‘CSS’ is closed to new topics and replies.