Comment puis-je mettre en forme une balise HTML INPUT afin qu'elle conserve CSS lorsqu'elle est centrée sur Android 2.2+?

Question

J'ai été ravi de découvrir que Android 2.2 supporte la position: sélecteur CSS fixe. Je l'ai construit simple preuve de concept, ici:

http://kentbrewster.com/android-scroller/scroller.html

... qui fonctionne comme un charme. Lorsque je tente d'ajouter une balise INPUT à mon en-tête, cependant, j'ai rencontré des problèmes. Au point, chaque périphérique que j'ai essayé jusqu'ici clone le tag INPUT, lui donne un index Z infini et le repeint au-dessus de l'ancienne balise. Le clone est à peu près dans la bonne position, mais la plupart des CSS de ses parents (y compris, bien sûr, position: fixed) sont ignorés. La balise INPUT clonée est de taille et de forme incorrectes et lorsque je fais défiler le corps de la page, elle défile vers le haut et l'arrière de l'écran.

Une fois hors écran, l'hilarité s'ensuit. Parfois, l'appareil force la partie défilante du corps vers le bas pour que le blanc cloné soit de nouveau visible; parfois, le clavier disparaît même si la zone visible semble rester nette; parfois, le clavier ne peut pas être ignoré même si l'entrée INPUT est clairement floue. Voici un exemple que vous pouvez exécuter sur votre appareil Android 2.2 pour voir ce qui se passe:

http://kentbrewster.com/android-input-style-bug/

entrée Styling: focus n'a pas fait l'affaire pour moi encore, ni avoir de nombreuses tentatives de force brute pour écouter de mise au point() et flou() avec JavaScript et faire la bonne chose avec la mise au point et le clavier.

Merci beaucoup pour votre aide,

--Kent

Answer 1

Ce ne sera probablement pas résolu jusqu'à ce que les commutateurs Android à l'aide de Chrome pour sa WebView. Le navigateur Android actuel crée un TextView Android en haut de la page lorsqu'un champ de saisie HTML est mis au point. Apparemment, ils ne le stylisent pas ou ne le positionnent pas correctement. Vous pouvez le voir aller plus mal sur les pages qui utilisent contentEditable. Le Chrome-for-Android actuel implémente l'interface WebKit IME. Les champs de saisie sont donc dessinés par WebKit (et perdent quelques-unes des subtilités de l'Android TextView sur ICS) et ne devraient pas présenter de problèmes de ce type.

Answer 2

Vous pourriez être en mesure de le résoudre en utilisant un bogue dans Android: http://code.google.com/p/android/issues/detail?id=14295. C'est-à-dire, n'affichez pas immédiatement le champ de saisie. Au lieu de cela, affichez un div overlay qui écoute sur le clic et se cache et montre l'entrée cachée, et donne le focus d'entrée. Cela empêche d'une manière ou d'une autre d'utiliser l'entrée wierd placée au-dessus de tout, et utilise plutôt le champ de saisie des navigateurs que vous pouvez personnaliser comme vous le souhaitez.

Comme vous le constaterez dans le RAPORT bug cependant, cela ne fonctionne pas avec l'entrée [type = « nombre »] ...

Answer 3

La solution est d'ajouter:

 

    input { 
     -webkit-user-modify: read-write-plaintext-only; 
     -webkit-tap-highlight-color: rgba(255,255,255,0); 
    } 

dans votre css.