iPad: Safari-Browser patzt bei Formulareingaben

So hatte ich mir das nicht vorgestellt! Eigentlich wollte ich das (für ein Projekt zugelegte) iPad als "mobiles" Büro nutzen, mit dem man auch Aufgaben per Internet erledigen kann. Leider bin ich auf ein dickes Problem beim Safari-Browser gestoßen, der diesen Ansatz zunichte macht – unter [1] hatte ich das Problem bereits am Rande erwähnt. Aber jetzt habe ich das Ganze nochmals detaillierter analysiert.

Wo liegt das Problem?

Das Problem ist recht fix auf den Punkt gebracht: Um beim iPad Texteingaben vornehmen zu können, muss iOS ein für Texteingaben vorgesehenes Bedienelement in der GUI oder im Browser erkennen. Nur dann wird die virtuelle Tastatur eingeblendet oder eine angeschlossene Bluetooth-Tastatur freigeschaltet. Während dies bei iPad-Apps durch die Entwickler innerhalb der GUI sichergestellt werden kann, ist man bei HTML-Inhalten darauf angewiesen, dass die Rendering-Engine des Safaria-Browsers (oder konkret der in iOS integrierten WebKit-Bibliotheken) dies sauber umsetzt.

Und hier liegt leider der "Hase im Pfeffer". Bereits zum Jahreswechsel fiel mir auf, dass ich in Microsofts Social Answers-Foren keine Beiträge posten konnte. Safari zeigt zwar die Forenseiten an und ermöglicht auch das Bearbeitungsformular zu öffnen. Aber es sind keine Texteingaben möglich. Da Microsoft mit seiner Forensoftware gelegentlich Probleme hat und auch Browser wie IE oder FF schon mal mit einem Formular, welches nur HTML-Code anzeigt, auftauchen, habe ich diesem Thema erst einmal keine größere Bedeutung beigemessen. Eine Analyse ist auf dem iPad zudem schwierig, da Safari keinen HTML-Quellcode anzeigt (und Zusatzapps für diesen Zweck sind eher eine Zumutung, als eine Hilfe).

Nachdem ich letzten Sonntag schnell einen Blog-Beitrag in WordPress editieren wollte (da hatte sich ein Tippfehler eingeschlichen), stand ich vor einem ähnlichen Problem. Das Bearbeitungsformular ließ sich zwar öffnen, und ich konnte auch das Feld zur Überarbeitung des Blog-Beitrags öffnen. Dann fehlten mir allerdings die Cursortasten, um im Textfeld zum Ende des Blog-Beitrags zu blättern. Erst als ich die Bluetooth-Tastatur koppelte, konnte ich über deren Cursortasten zu den gewünschten Textstellen des Textbereichs gehen.

Also habe ich den HTML-Quellcode auf einem Windows-System analysiert. Der HTML-Code im Social Answers-Forum sieht folgendermaßen aus.

<div class="content">
<textarea name="body" rows="20" cols="100">
…
</textarea>
</div>

während der HTML-Code in WordPress beim Editieren eines Beitrags folgende HTML-Tags enthält.

<div id='editorcontainer'>
<textarea rows='10' cols='40' name='content' tabindex='2'
id='content'>
…
</textarea>
</div>

Der Safari-Browser (bzw. die Routinen der WebKit-Bibliotheken) werden die Probleme auf, sobald im HTML-Code ein <textarea>-Tag, eingebettet in einen <div>-Tags, auftritt. Der Tag wird zwar korrekt gerendert – aber die Bibliothek scheint den Tag-Inhalt gegenüber iOS nicht immer als "Texteingabefeld" auszuweisen. Folglich sieht iOS auch keine Veranlassung, den Tastatureingabefokus auf das Feld zu setzen und die virtuelle Tastatur einzublenden. Bei WordPress fehlte dagegen die Funktion zum Blättern (Cursortasten).

Im ersten Moment glaubte ich noch, dass generell der <textarea>-Tag das Problem darstellt. Aber so einfach ist es nicht. Das Feedback-Formular meiner Webseite http://www.borncity.de enthält auch einen solchen Tag, aber das Eingabefeld wird im Safari-Browser des iPad korrekt erkannt.

Mein Versuch, das Ganze schnell mal an einem Web.de-Freemail-Konto zu verifizieren, scheiterte zuerst daran, dass ich für die Authentifizierung einfach nicht die von mir gewählten Sonderzeichen über die Bildschirmtastatur des iPad eingeben konnte. Erst eine aktivierte Bluetooth-Tastatur ermöglichte mir die Anmeldung am Web.de-Webmail-Konto. Hier konnte ich dann im Feld für den Body-Text der Nachricht Tastatureingaben vornehmen.

Ob es jetzt an Cascading Stylesheets, die bei der Microsoft-Forensoftware verwendet werden, oder an einer "ungünstigen" Schachtelung von <div>- und <textarea>-Tags liegt, habe ich nicht mehr eruiert. Es ist auch letztendlich egal, es kann nicht sein, dass Webdesigner jetzt auch noch irgend ein iOS mit iPad im Hinterkopf haben müssen, um eine simple Formulareingabe zu designen.

Mein Fazit ist jedenfalls, dass iPad-Benutzer ganz schnell bei HTML-Seiten, die mehrzeilige Texteingabefelder über den <textarea>-Tag bereitstellen, ausgebremst werden können.

Update: Bei WordPress habe ich doch noch eine Lösung zum Bearbeiten eines Beitrags gefunden. Die Lupe ermöglicht ja das Markieren und positionieren im Text. Tippt man auf das Bearbeitungsfeld und hält den Finger länger auf dem Text, erscheint irgendwann die Lupe. Dann kann man die Lupe mit dem Finger nach unten oder oben verschieben und so ein Scrollen im Textfeld auslösen. Hebt man dann den Finger ab, erscheint das Bearbeitungsmenü, welches durch Antippen einer anderen Textstelle geschlossen werden kann. Ziemlich umständlich, aber zumindest ein Notnagel (und für größere Korrekturen nehme ich ein Bluetooth-Keyboard. Aber für die Microsoft-Foren habe ich noch keine Lösung gefunden, um Beiträge zu bearbeiten.

Nimm doch einen alternativen Browser …

Dies war mein erster Gedanke, als der Effekt erstmalig bemerkt wurde. Nun, ich habe ein paar Browser zum Testen auf dem iPad. Leider hat man in diesem Fall die Rechnung ohne den Wirt – sprich Apple – gemacht. Alle im iStore angebotenen Browser setzen letztendlich auf Safari bzw. den Webkit-Bibliotheken auf und dürfen auch kein JavaScript oder weitere aktive Inhalte ausführen. Apples Regularien verbieten dies. Aufmerksam wurde ich auf diesen Sachverhalt (den ich aber bereits vermutete) bei der Recherche nach einem Firefox für das iPad. Die Mozilla-Entwickler erläutern unter [2, 3] die Hintergründe, warum es keinen Firefox auf dem iPad geben wird. Wie der Opera Mini-Browser das regelt, entzieht sich meiner Kenntnis. Das Teil schaffte es nicht mal 10 Sekunden im Test, dann habe ich die App wieder gelöscht.

Also: iPad-Benutzer sind da schon arme Schweine – nicht nur kein Flash, sondern auch keine Webinhalte, die auf JavaScript setzen. Dass die fehlende JavaScript-Unterstützung im Safari der Grund für die fehlende Formulareingabemöglichkeit darstellt, kann ich übrigens verneinen. Ich habe meine WordPress-Bearbeitungsfunktionen im Firefox mit deaktiviertem JavaScript problemlos ausführen können. An dieser Stelle habe ich meine Versuche abgebrochen …

Schöne neue Welt! Und damit wird das ganze Konzept des Tablet-PC (zumindest auf Basis des iPad) in meinen Augen ziemlich obsolet – wie das Teil in Firmen produktiv eingesetzt werden soll, vermag ich auch nicht zu erkennen. Ich erwische mich jetzt jedenfalls ständig, dass ich mein Netbook boote, um schnell mal was im Internet nachsehen und ggf. Forenbeiträge beantworten zu können. Dabei war das Ganze ja doch etwas anders gedacht – Freunde werden wir (dass iPad und meine Wenigkeit) unter diesen Gesichtspunkten in diesem Leben wohl nicht mehr werden. Ich plane momentan einen Test verschiedener Browser. Vielleicht findet sich da ja eine App, die diese Probleme nicht hat und auch sonst einige Verbesserungen gegenüber Safari mitbringt.

Weiterführende Links:
1: "Nette" Überraschungen 2011
2: Will Firefox ever be released for iOS devices?
3: Techcrunch-Artikel zum Firefox