On 1 November 2012 01:08, Philippe Wittenbergh <e...@l-c-n.com> wrote:
>
> If I understand correctly (no Android based device to test over here),
> Android default browser treats the inner width of .tabs as the total of
> your 3 ‘columns’ for the purpose of the translate3d transform ?
Yes, that's right. Upon DOM inspection, the div innocently claims to be the
correct width. It's only for the purposes of transforms that any faulty
behaviour comes about.
> And then only in portrait mode.
Not exactly — I've investigated this behaviour a bit more (along with
another mobile WebKit bix-model rendering issue with `display:
table-cell`), and whether the phone is in portrait or landscape orientation
is of no significance in itself, but rotating it forces a redraw that
results in correct behaviour (the same went for my table-cell issue). Of
course triggering a translation will break again (and rotation will fix
again!). This appears to be WebKit's variation of hasLayout.
> Does G Chrome for Android work correctly ?
>
No. As with iOS, Chrome for Android appears simply to be a different
interface around the same OS-based WebKit engine.
> That sounds yucky indeed. I don’t have any solution…. Does specifying
> .tabs { width: 100%; }
> help anything ?
No, I tried that — it seems that default value is taken on board, until the
transform.
I also wonder if this has something todo with the way you write viewport
> meta (the correct way, using a column (,) as a separator). I seem to
> remember that had Android being buggy with that - they ‘accidentally’
> allowed the use of a semi-column (;) instead, and have ‘better’ support for
> it (Mobile Safari drops everything after the 1st semi-column).
No dice!
PS - with Safari 6.01 on Mountain Lion, the text rendering after performing
> the translate3d transform looks quite poop - smoothing gone bad ? I’ve
> never seen that before. G Chrome isn’t great either, but not as bad as
> Safari.
>
Something really strange has been going on with WebKit's text rendering for
quite some time. I'm using Chrome on Windows at the moment and currently
there are no issues here, but I've seen the effect you're describing. I
believe it's a result of the transition, not the translation. I set up a
test case a while back here: http://jsfiddle.net/barney/8MFu4/ (actually,
that demo is full of strange things — text rendering is the tip of the
iceberg). I found that iOS Safari & OSX Chrome could be fixed by setting
`-webkit-backface-visibility` (to any value). Sadly the hack wasn't
production-viable because in OSX Safari 6 it could sometimes trigger the
bug.
>
> Philippe
> --
> Philippe Wittenbergh
> http://l-c-n.com
>
>
>
>
> ______________________________________________________________________
> css-discuss [css-d@lists.css-discuss.org]
> http://www.css-discuss.org/mailman/listinfo/css-d
> List wiki/FAQ -- http://css-discuss.incutio.com/
> List policies -- http://css-discuss.org/policies.html
> Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
>
______________________________________________________________________
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
