iOS-Textbereich, der bei der Verwendung von -webkit-overflow-scrolling ausgeblendet wird: touch

7

Noch einmal bin ich hier, weil ich meine Forschung zu diesem Thema erschöpft habe. Ich habe eine sehr einfache Einrichtung mit sehr einfachen Markup und doch ein sehr seltsames Verhalten.

Das Verhalten ähnelt auf unheimliche Weise ( Firefox und Angular: Der Textarea-Platzhalter erscheint erst beim ersten Fokus ), aber ich erlebe ihn in einer anderen Umgebung.

Betrachten Sie das Snippet mit einem schreibgeschützten Textbereich. Das bringt eine schlechte Liste von Kommentaren, wo 2-3 auf den Bildschirm passen, bevor man nach einigen bereits geladenen Kommentaren scrollen muss.

%Vor%

Dies funktioniert hervorragend, wenn Sie die Anwendung im Browser ausführen (Chrome, Safari usw.), aber sobald ich die Anwendung mit PhoneGap erstellt habe und sie auf dem iPad-Gerät ausgeführt habe, bekomme ich folgendes Verhalten:

Die sichtbaren Kommentare sind bereits in den Textareas gut sichtbar. Wenn ich nach unten scrolle, lese mehr Kommentare, ihre Textfelder sind leer, aber wenn ich auf das Textfeld klicke, erscheint der Text.

Nach dem Scrollen sind die Kommentarfelder leer, bis sie in iOS "angetippt" werden.

Das ist es, es gibt kein kompliziertes CSS in Bezug auf dieses Markup und keine seltsamen Probleme beim Laden des Servers. Wenn dieser Bereich geladen wird, bringt es alle Kommentare mit.

Ich möchte darauf hinweisen, dass es sich um eine große mobile App mit viel ausgefeilterem Markup / Funktionalität handelt, die im Browser gut funktioniert und sich perfekt auf Android- und iOS-Apps auswirkt.

Der erste Link, den ich hier gepostet habe, führt mich zu der Annahme, dass es einen seltsamen Bug in der Handhabung von Textbereichen auf mobile Clients gibt.

Irgendwelche Ideen? Ich würde es hassen, Textareas für Texteingaben auszugeben, aber ich bin fast an diesem Punkt.

    
Marcel 25.02.2015, 21:35
quelle

1 Antwort

18

Dieses Problem wird durch das TextArea-Element in einem Container ausgelöst:

%Vor%

in seinem übergeordneten Container.

Durch das Entfernen der Klasse wird das Problem behoben, dass der ursprünglich verborgene Text nicht geladen wird, aber die gewünschte Trägheit verloren geht, wenn UX gescrollt wird.

Hinzufügen

%Vor%

zum Stil meiner betroffenen Textarea-Elemente löst mein Problem.

In meinem speziellen Fall glaube ich nicht, dass es zu verbietenden Leistungsstrafen kommen wird, da meine versteckten Elemente, zu denen ich noch blättern soll, nicht reichhaltige Inhalte (Videos / Animationen / etc) laden würden, die den VRAM auf dem mobilen Gerät besteuern würden. Ich nutze im Prinzip den zusätzlichen Rendering-Kontext (hardwaregestützt), der dadurch ausgelöst wird, wodurch mein Text normal gerendert wird und somit ein iOS-BUG umgangen wird.

Tolle Informationen zu translateZ (und seinem nahen Cousin translate3d (0,0,0)) Ссылка

    
Marcel 02.03.2015, 21:22
quelle