transform translate percentages and Android

[barney]

I contend that Android WebKit miscalculates the box model when it invokes transform, which ruins my little trick. I’d like to find a way of making my little trick work on all transform-respecting browsers without resorting to inference via JS.

I’ve developped a mechanism for sliding a container to reveal full-width, horizontally arranged sub-sections. Sliding tabs, basically. Because there’s a lot of performance intensive stuff and elaborate Javascript going on, I want to keep JS to the minimum and do as much of the purely stylistic in CSS. I think I’ve done pretty well, considering — JS just changes an attribute on the wrapper:

http://jsfiddle.net/barney/VPJuq/
(mobile devices can append /show/ to these fiddle URLs to see the results by themselves)

A word on how this works: treating the tabs as `inline-block`s allows me to specify `white-space: nowrap` (the rest of the code in the last couple of rules essentially collapses the whitespace between the tabs) and allow them to stack horizontally without clearing / returning, all the while each maintaining the full width of their parent. From there, setting a negative left offset to the wrapper does the magic. Cool, huh?

Now, a bit of context: the interface I’m developing is to be run in native mobile applications — the application’s core functionality relies on cutting edge mobile-specific technology (don’t ask — NDA) — via a UIWebView, and the only platform that currently supports the technology in question is Android.

Here my problem is twofold: `transform: translate` works a /lot/ smoother (`translate3d` even more so) than `left` or `margin-left` transitions, to a point that is really really desirable, borderline crucial — especially on Android, seeing as non-translated transitions are still stutteringly glacial on the latest phones with the latest OS. With that in mind, the crux of the issue is that Android seems to infer the box model differently when relating to `translate`. To demonstrate, here’s a `transform`-based version of the same thing, which does the same thing as the previous fiddle, and works on all browsers that support translate3d…

http://jsfiddle.net/barney/EJ7ve

If you examine this on iPhone (again, by appending `/show`), you’ll notice improved frame rate on iPhones. The same goes for Firefox running on Android, and arguably on Chrome and the default browser on Android too, except that here, the `translateX` offset of -100% somehow refers to the space occupied by all three tabs, so the wrapper slides just enough such that none of the tabs are visible. This is odd, since transform percentages are specified as relating to the full box model of the element being transformed — and computed style unambiguously describes the wrapper width as being the same as its parent (not, as the result implies, stretched 3-fold to accomodate the tabs).

Can we describe this as a bug?

As far as I can tell, there’s no pure-CSS (I’m not averse to media query feature detection, CSS vendor forking or property hacking) method of infering and resolving this problem. In fact the only way of making this same CSS mechanic work that I can think of now is sniffing the UA string for Android and applying different rules conditionally. Yuk! If I’m to make an Android-WebKit-only solution, and break functionality everywhere else, I can take the de facto behaviour in to account and make the percentages refer to fractions:

http://jsfiddle.net/barney/nFt5t/

Not ideal, as this makes the UI browser-specific and requires that we know up front the number of tabs in a group before writing our CSS. But this doesn’t even completely solve the problem there, as, on orientation change (and this is really weird), the offset switches to the specification-correct behaviour displayed by other browsers!

I’ve also tried applying the translation to the actual tabs, which again works everywhere else, but despite correctly picking up and applying the rules, Android’s browser won’t render the effect. Stranger and strangerer:

http://jsfiddle.net/barney/EJ7ve/9

Any ideas?

[Author]

Posts