14

Safari and Chrome, as well as Opera and Firefox, can handle the :hover pseudo-class and adjacent-sibling selectors:

a:hover + div {}

This works.

However, when another adjacent-sibling is added:

div:hover + a + div {}

Webkit falls apart.

However, if you first hover over <a> and then hover over the <div> the style is applied as it ought to.

I'm further confounded, because if you add:

div:hover ~ div {}

with or without a style declared, it starts working as it ought to.

Demo

I see this problem in:

  • Google Chrome 15.0.874.121
  • Safari 5.1.1

for OS X.

Any ideas?

BoltClock
  • 630,065
  • 150
  • 1,295
  • 1,284
bookcasey
  • 35,635
  • 13
  • 70
  • 91
  • Yeah, this is a WebKit bug. I come across it occasionally. Elements apart from the `:hover`ed one and its parents aren't updated. Nothing you can do about it, I'm afraid. – Ry- Nov 30 '11 at 02:50
  • Somebody observed completely opposite behavior here: http://stackoverflow.com/questions/5061509/why-doesnt-this-css-selector-work-ahover-span Definitely a WebKit bug either way, and one that apparently hasn't been completely fixed yet. – BoltClock Nov 30 '11 at 02:50
  • I found a more elegant solution to this on a [more recent question](http://stackoverflow.com/questions/17219286/why-does-the-general-sibling-combinator-allow-toggling-pseudo-elements-content/17220145#17220145), so I posted a similar answer here. – ScottS Jun 20 '13 at 22:36
  • Seems to apply also in to a :checked selector. – Jaakko Karhu Apr 26 '16 at 20:00

3 Answers3

28

you can overcome Webkit's pseudo classes + general/adjacent sibling selectors bugs by faking animation on the body element:

body { -webkit-animation: bugfix infinite 1s; }

@-webkit-keyframes bugfix { 
  from { padding: 0; } 
  to { padding: 0; } 
}

you can check it out here: http://jsfiddle.net/jalbertbowdenii/ds2yY/1/

BoltClock
  • 630,065
  • 150
  • 1,295
  • 1,284
albert
  • 7,915
  • 3
  • 42
  • 62
  • you aren't even applying the fix i provided there, plus the commented out selector, you are using. this solution fixed his problem, no reason to downvote. – albert Jun 22 '12 at 09:33
  • this bug still present in almost similar situation, and this solution not working – Attenzione Jun 26 '12 at 10:34
  • 3
    the bug is not present in the question asked so i really do know how much more you want from me. or what you expect. if you have a question, post it to everyone. nit picking an accepted solution to fit your needs is not the purpose of SO – albert Jun 26 '12 at 21:59
  • Thanks! I used this in my artiyle [Advanced Checkbox Hack](http://timpietrusky.com/advanced-checkbox-hack) to fix the WebKit bug on Android in combination with the [default checkbox hack](http://css-tricks.com/the-checkbox-hack/). – TimPietrusky Nov 12 '12 at 19:28
  • @albert The bug is still present in Webkit. Your bugfixes does the trick, though (thanks!). However, is there a performance issue with constantly animating on the body? – Nix Jan 31 '13 at 05:49
13

Easy Fix without Animations

Handled a similar issue here, where this idea of changed pseudo-classes solved it (note: nth-child(n) will always match):

div:hover + a:nth-child(n) + div
Community
  • 1
  • 1
ScottS
  • 68,932
  • 12
  • 117
  • 139
12

Alternatively, the fix can be applied only to the elements that are having the update issue rather than to the body element:

http://jsfiddle.net/ds2yY/12/

.force-repaint { -webkit-animation: bugfix infinite 1s; }

@-webkit-keyframes bugfix {
    from { fill: 0; }
    to { fill: 0; }
}
tiffon
  • 4,711
  • 22
  • 33