Forçar a interpretação correta da porcentagem de transformações CSS3 no Android

tl; dr? Obter o mecanismo demonstrado no link abaixo para se comportar com aceleração de GPU no Android Chrome e navegador padrão.

ATUALIZAÇÃO 2 (2014-01-13 13: 25: 30Z): De acordo combref.itComentário abaixo, o comportamento relatado é fixado a partir do Android 4.4 KitKat - mas a correção que descrevi abaixo agora o quebra! Lei de Sod.

ATUALIZAÇÃO 1 (2012-11-01 17: 54: 09Z): O comportamento de bugs é inferível a partir da matriz de transformação, conforme relatado pelo estilo computado do elemento transformado, que retorna um valor de pixel. Vou tentar escrever um teste Modernizr para isso preparar o caminho para quaisquer soluções possíveis.

Desenvolvi um mecanismo para deslizar um contêiner para revelar subseções com largura total e disposição horizontal. Sliding tabs, basicamente. Como há muito material intensivo em desempenho e Javascript elaborado, quero manter o JS no mínimo e fazer o máximo possível com o estilo puramente estilístico do CSS. Eu acho que fiz muito bem, considerando - JS apenas muda um atributo no wrapper:

(com a esquerda)

http://jsfiddle.net/barney/VPJuq/ (dispositivos móveis podem anexar / mostrar / a esses URLs de violino para ver os resultados por si mesmos)

Uma palavra sobre como isso funciona: tratando as guias comoinline-blocks me permite especificarwhite-space: nowrap (o resto do código no último par de regras basicamente recolhe o espaço em branco entre as guias) e permite que empilhem horizontalmente sem limpar / retornar, enquanto mantêm a largura total de seus pais. A partir daí, definir um deslocamento negativo à esquerda para o invólucro faz a mágica. Legal né?

Agora, um pouco de contexto: a interface que estou desenvolvendo é para ser executada em aplicativos móveis nativos - a funcionalidade principal do aplicativo se baseia em tecnologia específica para dispositivos móveis (não pergunte - NDA) - por meio de um UIWebView e a única plataforma que atualmente suporta a tecnologia em questão é o Android.

Aqui meu problema é duplo:transform: translate funciona um / muito / mais suavetranslate3d ainda mais) do queleft oumargin-left transições, para um ponto que é realmente muito desejável, limítrofes cruciais - especialmente no Android, visto que as transições não traduzidas são ainda glacialmente chocantes nos últimos telefones com o mais recente sistema operacional. Com isso em mente, o cerne da questão é que o Android parece inferir o modelo de caixa de maneira diferente quando relacionado atranslate. Para demonstrar, aqui está umatransformversão baseada na mesma coisa, que faz a mesma coisa que o violino anterior, e funciona em todos os navegadores que suportam o translate3d…

(w / translate)

http://jsfiddle.net/barney/EJ7ve

Se você examinar isso no iPhone (novamente, anexando/show), você notará uma taxa de quadros melhorada nos iPhones. O mesmo vale para o Firefox rodando no Android, e possivelmente no Chrome e no navegador padrão no Android também, exceto que aqui, otranslateX O deslocamento de -100% de alguma forma refere-se ao espaço ocupado por todas as três guias, de modo que o wrapper desliza apenas o suficiente para que nenhuma das guias fique visível. Isso é ímpar, já que as porcentagens de transformação são especificadas como relativas ao modelo de caixa completa do elemento que está sendo transformado - e o estilo computado descreve claramente a largura do wrapper como sendo a mesma do pai (não, como o resultado implica, estendido em 3 vezes acomodar as abas).

Podemos descrever isso como um bug?

Tanto quanto eu posso dizer, não há puro-CSS (não sou avesso à detecção de recursos de consulta de mídia, bifurcação de fornecedor de CSS ou propriedade de hacking) método de inferir e resolver este problema. Na verdade, a única maneira de fazer esse mesmo trabalho de CSS mecânico que eu posso pensar agora é farejar a string UA para Android e aplicar regras diferentes condicionalmente. Yuk! Se eu quiser fazer uma solução somente para o Android-WebKit e quebrar a funcionalidade em qualquer outro lugar, posso levar em conta o comportamento de fato e fazer as porcentagens se referirem a frações:

(w / translate - para Androidatualização: desnecessário e quebra no Android 4.4 KitKat)

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

Não ideal, pois isso torna o navegador da interface do usuário específico e exige que saibamos com antecedência o número de guias em um grupo antes de escrever nosso CSS. Mas isso nem resolve completamente o problema, pois, na mudança de orientação (e isso é realmente estranho), o deslocamento muda para o comportamento correto da especificação exibido por outros navegadores!

Também tentei aplicar a tradução nas guias reais, o que funciona novamente em todos os outros locais, mas, apesar de ter corretamente coletado e aplicado as regras, o navegador do Android não renderiza o efeito. Estranho e Estranho:

(w / translate, trabalhando na teoria do Android, não trabalhando no Android)

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

Quaisquer ideias ou ideias para uma solução entre navegadores são muito apreciadas.

questionAnswers(3)

yourAnswerToTheQuestion