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.


Anzeige

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.


Anzeige

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


(c) by Günter Born www.borncity.de
The source of smart computer books


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Anzeige


Dieser Beitrag wurde unter iPad abgelegt und mit iPad, patzt bei Webseiten verschlagwortet. Setze ein Lesezeichen auf den Permalink.

8 Antworten zu iPad: Safari-Browser patzt bei Formulareingaben

  1. Günter Born sagt:

    [Kleine Updates: JavaScript scheint doch unterstützt zu werden – und Scrollen in Textfeldern geht wohl mit „zwei Fingern“ (danke Giesbert Damaschke) – krude Welt. Aber mein Grundproblem, überhaupt nicht in’s Textfeld zu kommen, ist immer noch nicht gelöst.

  2. honzi sagt:

    Sch*** – beim Webmail das selbe Problem – nur im Betrefffeld gehts …. ???? was tun???

    • Günter Born sagt:

      @honzi: Das hängt vom Webmail-Anbieter und dessen Formulargestaltung ab. Hier habe ich mehrere Anbieter getestet, und es funktionierte. Wenn der Anbieter eine HTML-Darstellung bietet, kann man zu dieser umschalten.

      Unter dem Strich habe ich für mich eine einfache Lösung gefunden: Ich verzichtet auf das gichtige iPad und setze meine diversen Netbooks mit Windows (oder Android) ein – da funktioniert es.

  3. GE sagt:

    Günter Born: „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.“

    All diese Tablets sind eben vom Betriebssystem her grosse Handys (auch wenn man mit den meisten nicht direkt telefonieren kann), und eher zum „internet gucken“ aks zum arbeiten.

    Ich warte ganz einfach, bis die Dinger „kleine PCs“ sind, also mit Windows Betriebssystem, auf dem ich ganz einfach meine Programme installieren kann.

    Günter Born: „ch verzichtet auf das gichtige iPad und setze meine diversen Netbooks mit Windows (oder Android) ein – da funktioniert es.“

    Ein Netbook ist immer die bessere Wahl, eben ein „kleiner PC“.

    Android ist auch nicht viel besser, viele Anwendungen, die auf Java-script basieren, laufen nicht. Bei mir sind das z. B. Lightboxen in Fotogalerien und WYSIWYG Editoren im Backend. Ich habe auch mit grossem Aufwand ein Kommentar Plugin XSS-sicher gemacht und mit einem FCKeditor ausgestattet, auch das läuft nicht, weder auf dem iPad noch auf Android getriebenen Tablets.

    Hier mal zum testen:

    Was nun tun? Ich habe mich erstmal entschlossen, das auszusitzen. Irgendwann werden die Tablets „kleine PCs“ sein, mit einem ordentlichen Betriebssystem und voller JS-Unterstützung …

    • Günter Born sagt:

      @GE: Kann deinen Ausführungen nur voll und ganz zustimmen. Als Autor und Blogger muss ich gelegentlich aber mal „in die Bütt“ und mir so ein Teil näher ansehen. Die 700 Euronen für den iPad-Kauf tun mit heut noch leid. Nachdem ich gesehen habe, was das tolle Teil (bei Apple klappt ja alles) alles nicht kann bzw. nicht können darf, liegt das häufig unbenutzt hier rum. Nur mal gelegentlich zum Couchsurfing wird es benutzt (ziemlich teures Hobby).

      Bei Android ist es im Grunde das Gleiche – hier habe ich lediglich den Vorteil, dass ich da Teststellungen bekomme und ein Android-x86-Netbook sowie eine VM zum Experimentieren nutzen kann.

      Ich hab’s an anderer Stelle im Blog bereits thematisiert: Die Herkunft von Handy-Betriebssystemen ist das größte Problem bei iOS und Android – nur haben die Fachleute und Analüsten das noch nicht kapiert. Für mich ist es nun recht interessant, wie das Ganze Tablet PC-mäßig zukünftig mit Windows 8 ausschaut. Mit etwas Glück könnten viele konzeptionelle Krankheiten aus iOS und Android dort ausgemerzt sein. Aber ich erwarte da an anderen Stellen (UEFI safe boot etc.) die Haken.

      PS: Dachte schon, dass ich so langsam alt und nur noch mäkelig werde – weil auf meine Thesen so wenig Feedback kommt. Aussitzen könnte eine Strategie sein – obwohl ich irgendwie das Gefühl nicht los werde, dass die sich die Entwickler ständig neue Torheiten leisten und der Kunde sowie nachhaltiges Produktdesign zwischenzeitlich längst aus dem Fokus rausgewandert ist. Muss mir überlegen, ob ich nicht so langsam in Richtung „Weinberg“ in einer schönen Ecke Europas abdrifte und den ganzen IT-Zirkus hinter mir lasse …
      … aber vermutlich würde mir dann etwas fehlen, über das ich mich ärgern und bloggen kann ;-).

  4. GE sagt:

    Günter Born: “Vielleicht findet sich da ja eine App, die diese Probleme nicht hat und auch sonst einige Verbesserungen gegenüber Safari mitbringt.“

    Das kann ja eigentlich auch nicht die Lösung des Problems sein. Ein System sollte „im Auslieferungszustand“ in der Lage sein, alles zu erledigen, was man im Internet so erledigen will, und dazu gehören heutzutage auch Kommentare in Blogs, Posts in Foren und die Administration von CMS.

    Irgendwie alles noch nicht so richtig fertig, auch mehr als ein halbes Jahr nach Deinem Beitrag …

  5. Max sagt:

    Endlich mal jemand der auch große Probleme mit dem Ipad als Arbeitsgerät hat. Ich hatte es zwar nicht gekauft, sondern per Handyvertrag, aber arbeiten wollte ich trotzdem damit.
    Und siehe da: Auch ich muss Arbeiten an Kundenprojekten jetzt unterrwegs mit dem Netbook erledigen.
    Versucht mal mit dem Ipad bei WordPress irgendwas an den Widgets zu ändern. :-(
    Mein Ipad ist Surfstation, Mediaplayer und Spielekonsole. Und bleibt immer zuhause. Danke, Apple.
    Gruß, Max

  6. Kai sagt:

    Hallo zusammen,
    habe dasselbe Problem. Möchte mit meinem iPad aktiv an meiner Hompage (im Aufbau) arbeiten. Komme in den Hompagebaukasten von 1&1 rein, dann folgt jedoch die Fehlermeldung, dass man einen aktuelleren Browser mit aktiviertem JavaScript benötige. 1&1 sagt, das liege eindeutig bei Apple.
    Apple empfahl den Opera aus dem Store. Der erzeugt dieselben Fehlermeldungen. Ebenso der dann von mir heruntergeladene Mercury.
    Bin jetzt völlig hilflos. Javasript ist übrigens in Safari aktiviert.
    Kai

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.