Checkbox Hack on Mobile Webkit

[jimdavis]

Having a problem getting the checkbox hack to work on my android with standard webkit browser. Works with Firefox beta mobile. See http://jimdavis.org/test/cssmenu3.html for example. Best viewed on your smartphone. On my android/webkit tapping the button has no effect. See Chris’s demo here: http://dabblet.com/gist/1506530.
Jim

[paintba11er89]

I have the same problem. This hack seems to work on every browser that I’ve come across, except the default Android browser. I obviously don’t like designing pages based on a hack, but when your only other option for storing state data with CSS (and avoiding javascript) is :target, I’m going to want to go with this hack (which works in more browsers than :target).

I am not sure what causes it. Do let me know if you find an answer, and I’ll do the same.

EDIT: I’ve been testing further. It seems that the android browser does check the input tag, but the :checked pseudo class in the CSS doesn’t get activated or isn’t dynamically applied.

[paintba11er89]

Ah, I’ve found the actual problem, but no solution.. It seems as if the sibling combinator (~) doesn’t work in the default Android browser.. Any site you’ve made that uses a stylesheet with those combinators, will not render correctly. I’ll look for a fix for this, but I’m thinking there isn’t much we can do.

EDIT: Take that back. The default android browser does support the sibling combinator (~), just not when used in conjunction with pseudo classes (this goes for :checked or :target).

[paintba11er89]

Getting back to your problem, here is the solution that works (this format is compatible with the default Android browser): http://jsfiddle.net/NicholasRBowers/knVcn/.

Alright, so as far as I can see, this is what’s up:

Sibling (~) and adjacent sibling(+) combinators work the same on the default Android browser – they each only pick up the NEXT SIBLING when used in conjunction with a pseudo class – which really sucks. So in order to get this to work on the default Android browser, I had to move the label above the input element, so that way the div element was right after the input (since the input is controlling the div). If you want to extend this to working on an actual site and make it a little more impressive, my suggestion would be to put an invisible input before the page container div element, and then you can drill down into it using more selectors. It really sucks that it has to be this way, but it seems like that’s what’s going on.

If anyone has a better workaround, please let me know! For projects where you’re utilizing this idea with several input (checkbox) elements, it’s not going to work on the default Android browser, because there is no way to make all of the sibling checkboxes be adjacent to the same element (that is if they all control the same area).

Code for clarity:
HTML:

Styled nicely

Styled nicely

Styled nicely



Sweet content to style differently depending on which boxes are checked [this hack works the same with radio buttons, if you only want one of the boxes checked at a time].

CSS Snippet:

input[id="one"]:checked ~ div#pagecontainer label {

super-secret: styles;

}

input[id="one"]:checked ~ div#pagecontainer div#controlthissection {

super-secret: styles;

}



input[id="two"]:checked ~ div#pagecontainer label {

super-secret: styles;

}

input[id="two"]:checked ~ div#pagecontainer div#controlthissection {

super-secret: styles;

}



input[id="three"]:checked +(or ~) div#pagecontainer label {

super-secret: styles;

}

input[id="three"]:checked ~ div#pagecontainer div#controlthissection {

super-secret: styles;

}

While all three sets of styling would work (with regards to specificity and order) in most normal browsers, in the default Android browser, only the third style set would work because it is expressly adjacent to the next element it is selecting. I am using something similar in a project of mine, and would definitely be interested in a better work-around if anyone has any ideas!

[DesjardinsM]

Hate to drag this up again after such a long time, but if you hadn’t gotten a better workaround yet, Tim Pietrusky actually mentioned this the other day in his guest post on [Responsive Menus](https://css-tricks.com/responsive-menu-concepts/ “”). For me, at least, adding the fake body animation was able to get it working, though I’m not sure I like the idea of having a hack to fix a hack.

Basic CSS:

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

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

More information about it on [Stackoverflow](http://stackoverflow.com/questions/8320530/webkit-bug-with-hover-and-multiple-adjacent-sibling-selectors/8320736#8320736 “Stackoverflow”).

[paintba11er89]

Thanks @DesjardinsM! Definitely not best-coding practice, but interesting enough for those who want CSS-only solutions for storing state. Good to know there is a “legitimate” workaround.

[age401]

Hey!, Someone mentioned on Tim’s post about this fix that if you combined this with hardware accelerated transforms you’ll enter a dark place of battery burn. Sounds sensible. So, has anyone gone into the trouble of testing this? Is there a way to avoid this?

Thank you!

[Author]

Posts