Vollbild-Web-Apps

() translation by (you can also view the original English article)

Eines der ersten Probleme beim Erstellen einer mobilen Web-App von Grund auf ist der von der Adressleiste des Browsers belegte Speicherplatz. In diesem Tutorial wird gezeigt, wie Sie die ansonsten in der Adressleiste verlorene Bildschirmfläche zurückfordern können, während Sie Änderungen der Ausrichtung, Probleme mit der Inhaltshöhe und interne Dokumentverknüpfungen berücksichtigen.

Nachträgliche Änderungen an Techniken und Software

Bestimmte Aspekte der in diesem Tutorial verwendeten Anwendungen oder Techniken haben sich seit der ursprünglichen Veröffentlichung geändert. Dies könnte es etwas schwierig machen, mitzumachen. Wir empfehlen, sich diese neueren Tutorials zum gleichen Thema anzusehen:

Mobiletuts + Web Apps Kategorie

Problem definieren

Einer der schwierigsten Aspekte beim Entwerfen für mobile Geräte ist der begrenzte verfügbare Bildschirmplatz. Mobile Webanwendungen müssen rationalisiert und intuitiv sein, um mit nativen Anwendungen konkurrieren zu können. Das Vorhandensein der Benutzeroberfläche des Browsers beeinträchtigt häufig nur die Benutzererfahrung und die Ästhetik der Website insgesamt.

Betrachten Sie beispielsweise den folgenden Screenshot einer mobilen Website:

Der obige Screenshot wurde auf einem iPhone 4 aufgenommen, wobei sowohl die Adressleiste als auch die Symbolleiste von Mobile Safari angezeigt wurden.

Schauen Sie sich jetzt denselben Screenshot ohne die Benutzeroberfläche des Browsers an:

Die iPhone-Version der Website hat 60 Pixel durch Entfernen der Adressleiste oben und 44 Pixel durch Entfernen der Schaltflächenleiste unten gewonnen, um insgesamt 104 logische Pixel vertikalen Bildschirmbereichs zu erhalten (der auf Android-Geräten gewonnene Speicherplatz variiert) , aber das Ergebnis ist ähnlich). Wenn Sie versuchen, ein beeindruckendes Erlebnis zu schaffen, können Sie anhand der obigen Screenshots leicht erkennen, welchen großen Unterschied eine so kleine Änderung bewirken kann.

Leider haben die großen mobilen Webbrowser Entwicklern noch keine einfache und universelle Methode zum einfachen Ein- und Ausschalten der Browser-Benutzeroberfläche zur Verfügung gestellt. Es gibt jedoch zwei gängige Ansätze, um die Arbeit zu erledigen, und beide werden in diesem Lernprogramm behandelt.

Der Meta-Tag-Ansatz

Wenn Ihre Web-App nur auf iOS ausgerichtet ist, besteht die ideale Lösung darin, das folgende Meta-Tag im <head>-Teil Ihres HTML-Dokuments festzulegen:

1	<meta name="apple-mobile-web-app-capable" content="yes" />

Dadurch werden sowohl die Adressleiste des Browsers als auch die Symbolleiste vollständig aus Mobile Safari entfernt, wie im zweiten Screenshot oben gezeigt.

Zusätzlich zu der Tatsache, dass dieser Code nur auf iOS-Geräten zuverlässig funktioniert, gibt es ein weiteres großes Problem bei diesem Ansatz: Er funktioniert nur, nachdem der Benutzer die Website zum Startbildschirm hinzugefügt hat und wenn der Benutzer die Website unabhängig davon startet Mobile Safari.

Ich habe unbestätigte Berichte gelesen, dass der Meta-Tag-Ansatz auch auf einigen Android-Geräten funktioniert, aber auf meinem Nexus S funktioniert er sicherlich nicht und scheint von Android überhaupt nicht offiziell unterstützt zu werden.

Dies ist offensichtlich nicht ideal. Das Hinzufügen von Websites zum iOS-Startbildschirm ist eine obskure iOS-Funktion, von der viele Benutzer nicht einmal wissen, dass sie möglich ist und die sie beim gelegentlichen Surfen im Internet wahrscheinlich nicht verwenden.

Vielleicht werden eines Tages Browser-Anbieter ein einziges plattformübergreifendes Meta-Tag vereinen und bereitstellen, um die Benutzeroberfläche des Browsers detailliert zu steuern, ohne den normalen Anwendungsfluss des Webbrowsers zu beeinträchtigen (wie würde das Leben aussehen, wenn dies tatsächlich eintreten würde). Bis dahin müssen wir die Dinge auf die altmodische Weise in die Hand nehmen: mithilfe von JavaScript.

Kontrapunkt: Wenn Entwickler das Vorhandensein der Adressleiste und/oder der Registerkartenleiste steuern können, erhalten Entwickler kreative Freiheit auf Kosten der Endbenutzerfreiheit und des gesamten Browsererlebnisses. Ohne ein konsistentes UX-Muster zum Zurücknavigieren oder Eingeben einer neuen URL werden Benutzer beim Surfen verwirrt und können die Site in einigen Fällen nicht verlassen, ohne den Browser vollständig zurückzusetzen.

Gegenkontrapunkt: Erstellen eines neuen UX-Musters, mit dem Entwickler das Vorhandensein oder Fehlen von Browsersteuerelementen bestimmen und gleichzeitig die Kontrolle des Endbenutzers über die Navigation behalten können (möglicherweise durch eine Kombination aus einem Ausblendeffekt und dem 'Double-Tap'). Geste oder vielleicht durch Erzwingen des Starts von Vollbild-Apps in einem neuen Fenster) könnte ein Gleichgewicht zwischen beiden Interessen herstellen.

Der JavaScript-Ansatz

Viele der jetzt verfügbaren plattformübergreifenden Web-App-Frameworks verlassen sich auf einen JavaScript-Hack, um einem Vollbild-Erlebnis so nahe wie möglich zu kommen. Die folgenden Frameworks enthalten alle einige Variationen der JavaScript-Lösung, die ich in diesem Tutorial demonstrieren werde:

Für diejenigen unter Ihnen, die nur den Code ohne die Erzählung wollen:

Ich hoste den obigen Code auf GitHub: Gist, also zögern Sie nicht, Änderungen vorzunehmen, zu ändern oder vorzuschlagen. Denken Sie daran, dass dies bestenfalls ein browserabhängiger Hack ist. Es kann sich in Zukunft ändern. Es kann sein, dass es nicht jeden Randfall abdeckt. Es ist unter Blackberry und Windows Phone 7 nicht getestet.

UPDATE 03.09.2011:
Dank des Feedbacks von John Boxall unten habe ich dem Listener "Laden" eine weitere Bedingung hinzugefügt. Die Funktion hideAddressBar() wird jetzt nur aufgerufen, wenn der Benutzer vor dem Auslösen des Ereignisses "Laden" noch nicht mit dem Scrollen begonnen hat.

Für diejenigen unter Ihnen, die genau lernen möchten, wie und warum dieser nette kleine Trick funktioniert, lesen Sie weiter!

Das Kaninchenloch hinunter wagen

Im Wesentlichen läuft der Trick darauf hinaus, was in einer einzigen Zeile JavaScript zusammengefasst werden kann:

1	window.scrollTo(0, 1);

Der scrollTo-Aufruf ist eine Methode des window-Browserobjekts mit der folgenden Signatur:

1	scrollTo(x, y);

Das erste Argument steuert den Abstand zum Scrollen des Fensters auf der x-Achse und das zweite Argument steuert den Abstand zum Scrollen des Fensters auf der y-Achse.

Das allgemeine Konzept ist, dass wir die Browsersteuerelemente zwar technisch nicht aus dem Webbrowser entfernen können, den Inhalt des Ansichtsfensters jedoch nach unten scrollen können, um die Adressleiste aus dem Fenster zu entfernen.

Warum also nur die Y-Achse um 1 Pixel verschieben? Sollte es nicht 60 Pixel für das iPhone sein? Das war auch mein erster Gedanke. Die Adressleiste ist jedoch technisch nicht Teil des Dokumentansichtsfensters. Anstatt den Inhalt tatsächlich um 60 Pixel nach unten zu scrollen, nutzen wir tatsächlich eine WebKit-Besonderheit (Fehler?), Die die Adressleiste automatisch aufhebt, wenn die scrollTo-Methode aufgerufen wird. Bei meinen Tests konnte ich den gewünschten Effekt unter iOS erzielen, indem ich den Y-Wert auf eine beliebige Ganzzahl einstellte, einschließlich -10, 0, 1 oder 60. Unter Android erreichten jedoch nur positive Ganzzahlen den gewünschten Effekt, sodass "1" der beste Y-Offset für den Browser-Hack ist.

Im nächsten Schritt müssen Sie festlegen, wann die scrollTo-Methode aufgerufen werden soll. Idealerweise sollte dies unmittelbar nach dem Laden der Seite geschehen. Alle folgenden Implementierungen haben in meinen Tests funktioniert und sind in der Reihenfolge ihrer Eleganz aufgelistet:

Hinzufügen eines Ereignis-Listeners:

1	window.addEventListener("load", function() { window.scrollTo(0, 1); });

Hinzufügen eines Inline-Ereignis-Listeners:

1	<body onload="window.scrollTo(0, 1);">

Innerhalb eines eingebetteten script-Tags (für diejenigen, die sich rebellisch fühlen):

    <script>
        window.scrollTo(0, 1);
    </script>
</body>
</html>

Wenn Sie alle drei Beispiele unter Android ausprobieren, sollten die Dinge gut funktionieren (obwohl das dritte Beispiel besonders hässlich ist). Wenn Sie dies jedoch unter iOS versuchen, geschieht nichts.

Aus Gründen, die mir nicht ganz klar sind, kann Mobile Safari unter iOS den Scroll-Hack nicht nur mit einem der oben genannten Ereignis-Listener anwenden.

Damit dies unter iOS funktioniert, müssen Sie eine geringfügige Verzögerung zwischen dem Auslösen des Ereignis-Listeners und der Ausführung der scrollTo-Methode festlegen.

Dies kann einfach mit der setTimeout-Methode durchgeführt werden, wie gezeigt:

1	window.addEventListener("load", function()
2	{
3	setTimeout( function(){ window.scrollTo(0, 1); }, 100 );
4	}

Die Methodensignatur für die Funktion setTimeout lautet:

1	setTimeout(code, milliseconds, [ lang ])

In meinem Beispiel habe ich eine anonyme Funktion bereitgestellt, die den scrollTo-Aufruf enthält, der nach einer Verzögerung von 100 Millisekunden ausgeführt werden soll. Seltsamerweise funktionierte das oben Genannte immer noch für mich, unabhängig von der Ganzzahl, die für die Millisekundenverzögerung vorgesehen war. Es funktionierte mit -100, 0 und 1 genauso gut wie mit 100. Folglich empfehle ich, 0 für das Millisekunden-Argument zu verwenden.

Zu diesem Zeitpunkt sollte unsere Adressleiste, in der das JavaScript-Snippet versteckt ist, ungefähr wie eines der folgenden Beispiele aussehen:

Ereignis-Listener:

<head>
    <title>Fullscreen Test</title>
    <script>
      window.addEventListener("load", setTimeout( function(){ window.scrollTo(0, 1) }, 0));
    </script>

Inline-Ereignis-Listener:

1	<body onload=" setTimeout( function(){ window.scrollTo(0, 1) }, 0); ">

Toll! Jetzt können wir also tatsächlich etwas Nützliches bauen, oder? Leider nicht. Es gibt immer noch einige browserspezifische Probleme, die diesen Hack verschmutzen können.

Unzureichende Inhaltshöhe

Was ist, wenn Ihr Inhalt nicht groß genug ist, um den gesamten Bildschirm auszufüllen? In diesem Fall haben Sie keine vertikale Bildlaufleiste und der oben gezeigte Trick funktioniert nicht. Zusätzlich zum einfachen Hinzufügen von mehr Inhalt zu Ihrer Seite gibt es mindestens drei weitere weniger restriktive Methoden, mit denen Sie dieses Problem beheben können.

Option 1: Stellen Sie die `Initial-Scale` ein

Der erste Ansatz besteht darin, die initial-scale Ihrer Webseite zu ändern, bis Ihr Inhalt das gesamte Ansichtsfenster ausfüllt. Sie können dies mit dem folgenden Meta-Tag tun:

1	<meta name="viewport" content="width=device-width, initial-scale=1.0">

Sie müssen mit dem anfänglichen Skalierungswert herumspielen, bis Sie den Skalierungs-/Zoombetrag gefunden haben, der Ihren spezifischen Anforderungen entspricht.

Option 2: Stellen Sie eine Mindesthöhe ein

Der zweite Ansatz besteht darin, ein einfaches CSS-Attribut zu verwenden. Sie können entweder auf das body-Tag oder auf ein anderes Element auf Blockebene auf Ihrer Seite einen min-height Wert für die Mindesthöhe anwenden, um den leeren Leerraum zu berücksichtigen. Hier müssen Sie jedoch aus zwei Gründen vorsichtig sein: Der genaue Pixelwert, der vom Attribut min-height benötigt wird, hängt von der initial-scale (d.h. dem Zoom) der Seite ab, und der Wert ändert sich, wenn der Benutzer von Hochformat zu wechselt Querformat oder umgekehrt. Die grundlegende Syntax zum Festlegen des Attributs min-height für das Body-Tag ist unten dargestellt:

1	body { min-height: 900px; }

Nochmals: Der tatsächlich verwendete Pixelwert hängt von der anfänglichen Skalierung/dem Zoom Ihrer Site ab. Möglicherweise müssen Sie ziemlich hoch oder ziemlich niedrig gehen.

Option 3: Stellen Sie die Höhe dynamisch mit JavaScript ein

Der dritte Ansatz besteht darin, die Eigenschaft document.height dynamisch mit der Eigenschaft window.outerHeight zu vergleichen und bei Bedarf die Größe von document.height dynamisch zu erhöhen.

Das folgende JavaScript-Code-Snippet ist eine Nicht-Framework-Lösung für dieses Problem:

   <script>
      window.addEventListener("load", function(){  
          if(document.height <= window.outerHeight)
          {
              document.body.style.height = (window.outerHeight + 50) + 'px';
              setTimeout( function(){ window.scrollTo(0, 1); }, 50 );
          }
          else
          {
              setTimeout( function(){ window.scrollTo(0, 1); }, 0 ); 
          }
      }
      );
    </script>

In den Zeilen 5 oben habe ich eine scheinbar willkürliche Menge an Polsterung hinzugefügt (+50). Dies war notwendig, damit der Effekt sowohl auf iOS als auch auf Android funktioniert. Ich musste auch den Aufruf von setTimeout neu positionieren, da iOS den automatischen Bildlauf nicht sofort nach dem Festlegen von document.body.style.height erzeugen würde. Besonders merkwürdig fand ich, dass ich nicht nur den setTimeout-Aufruf neu positionieren musste, sondern für iOS auch eine scheinbar willkürliche Verzögerung von +50 hinzufügen musste, wenn ich gerade die Dokumenthöhe geändert hatte. Dies war anfangs nicht der Fall (wenn Sie den load-Listener verwenden, ohne einen neuen Wert für die Dokumenthöhe festzulegen).

Interne/Anker-Links

Variationen des oben genannten Browser-Hacks sind im Web bereits weit verbreitet. Es gibt jedoch mindestens einen Anwendungsfall, in dem das Erzwingen eines Bildlaufs des Browsers auf 0,1 genau der falsche Ansatz ist: Besucher, die über einen Anker auf Ihre Website kommen (a.k.a. interner) Link. Um diesen Randfall zu berücksichtigen, müssen Sie scrollTo(0, 1) nur aufrufen, wenn das Hash-Tag nicht in der URL vorhanden ist. Um diesen Ansatz zu implementieren, müssen wir lediglich prüfen, ob in window.location.hash ein Wert vorhanden ist, und dann unseren Listener für load-Ereignisse in diese Bedingung einschließen. Wenn wir dies tun, haben wir ungefähr Folgendes:

      if( !window.location.hash )
      {
          window.addEventListener("load", function(){  
              if(document.height <= window.outerHeight + 10)
              {
                  document.body.style.height = (window.outerHeight + 50) +'px';
                  setTimeout( function(){ window.scrollTo(0, 1); }, 50 );
              }
              else
              {
                  setTimeout( function(){ window.scrollTo(0, 1); }, 0 ); 
              }
          }
          );
      }

Änderungen der Geräteausrichtung

Ein weiteres Problem, das möglicherweise auftritt, betrifft Änderungen der Geräteorientierung. Wenn ein Benutzer unter iOS das Telefon vom Hoch- in den Querformatmodus dreht, wird der Bildlaufversatz nicht automatisch geändert (Android scheint nicht unter diesem Problem zu leiden). Dies bedeutet, dass Ihr Benutzer irgendwo weiter unten auf der Seite bleibt als beabsichtigt.

Die Lösung hierfür besteht darin, einen Ereignis-Listener für window.onorientation change festzulegen, der benachrichtigt wird, wenn sich die Ausrichtung ändert, und den Aufruf von window.scrollTo(0, 1) nach der Änderung erneut auszuführen.

Dies scheint ein guter Zeitpunkt zu sein, um mit der Überarbeitung des Codes zu beginnen, indem der Code, der für das tatsächliche Ausblenden der Adressleiste verantwortlich ist, in eine unabhängige Funktion aufgeteilt wird. Danach bleibt uns Folgendes übrig:

      function hideAddressBar()
      {
          if(!window.location.hash)
          { 
              if(document.height <= window.outerHeight + 10)
              {
                  document.body.style.height = (window.outerHeight + 50) +'px';
                  setTimeout( function(){ window.scrollTo(0, 1); }, 50 );
              }
              else
              {
                  setTimeout( function(){ window.scrollTo(0, 1); }, 0 ); 
              }
          }
      } 

      window.addEventListener("load", hideAddressBar );
      window.addEventListener("orientationchange", hideAddressBar );

Die oben genannte Lösung scheint sowohl für Android als auch für iOS hervorragend zu funktionieren, aber es gibt noch ein weiteres Problem, das für Ihr Projekt relevant sein kann oder nicht: Was ist, wenn der Benutzer vor dem Ändern der Geräteausrichtung deutlich nach unten gescrollt hat? In diesem Fall würde das Zurücksetzen der Anzeige auf 0, 1 dazu führen, dass der Benutzer seinen Platz im Dokument verliert. Dies zu berücksichtigen ist sehr implementierungsspezifisch. Das Wesentliche ist jedoch, einfach einen Schwellenwert für die y-Achse festzulegen und den Bildlaufversatz nur dann auf 0, 1 zurückzusetzen, wenn der Benutzer diesen Schwellenwert noch nicht überschritten hat.

Sperren der Adressleiste außerhalb des Bildschirms

Einige Frameworks, wie z. B. SenchaTouch, sperren die Adressleiste tatsächlich außerhalb des Bildschirms, indem sie verhindern, dass der Benutzer über einen bestimmten Schwellenwert für die y-Achse hinaus scrollt. Dies ist sicherlich möglich, aber ich werde hier nicht diskutieren, wie dies zu tun ist, da ich finde, dass diese Lösung ein erhebliches Usability-Problem darstellt, insbesondere unter Android. Wenn Sie jedoch entschlossen sind, diesen Effekt zu erzielen, müssen Sie wahrscheinlich mit dem Attribut window.pageYOffset experimentieren.

Was ist mit der Schaltflächenleiste unter iOS?

Meines Wissens gibt es derzeit keine Lösung, um die Symbolleiste/Schaltflächenleiste unter iOS mit JavaScript allein von unten in Mobile Safari zu entfernen. Der einzige Weg, den ich kenne, um diesen Effekt zu erzielen, ist der Meta-Tag-Ansatz, der zu Beginn dieses Tutorials erläutert wurde. Korrigiere mich, wenn ich falsch liege!

Bedingt machen

Eine Überlegung mit dem oben noch nicht diskutierten Ansatz ist, wie Benutzer behandelt werden sollen, die von einem nicht mobilen oder nicht unterstützten Webbrowser aus besuchen. Es gibt verschiedene Methoden, um festzustellen, welcher Browser derzeit auf Ihre Website zugreift. Wenn Sie mit einer serverseitigen Skriptsprache arbeiten, möchten Sie möglicherweise feststellen, ob sich der Benutzer zum Zeitpunkt der Seitengenerierung auf einem mobilen Gerät befindet, und diesen Hack nur bei Bedarf bereitstellen. Ein robusterer Ansatz wäre möglicherweise, die Tests dynamisch mit JavaScript durchzuführen. Das Anwenden dieser Überlegung würde den Rahmen dieses Tutorials sprengen, aber bitte hinterlassen Sie Ihre Vorschläge in den Kommentaren.

Vorbehalt Emptor!

Browser-Hacks wie der, den ich beschrieben habe, um die Adressleiste auszublenden, widersetzen sich den Best Practices. Die Implementierung, die ich in diesem Tutorial erklärt habe, wurde auf einem Android Nexus S, iPhone 3GS und einem iPhone 4 getestet, aber es ist durchaus möglich, dass ich irgendwo einen Edge Case verpasst habe. Ich bin mir auch nicht sicher, ob die angezeigte Implementierung auch in Zukunft so funktioniert, wie sie ist. Deshalb war ich ziemlich überrascht, dass so viele der primären Web-Frameworks (z. B. iUI, jQuery Mobile, SenchaTouch) prominent waren Websites (z. B. Google Mail, Yahoo, Apple), die auf einer benutzerdefinierten Variante dieses Hacks basieren. Der Grund ist meiner Meinung nach einfach: Eine bessere Lösung ohne Javascript gibt es derzeit nicht.

Einpacken

Ich hatte drei Hauptabsichten beim Schreiben eines so ausführlichen Tutorials zu einem scheinbar trivialen Thema.

Zunächst wollte ich ein reines JavaScript-Snippet bereitstellen, um diesen Effekt zu erzielen, der robuster ist als die meisten anderen, denen ich begegnet bin. Ich hoffe, dass ich dies erreicht habe, indem ich Orientierungsänderungen, Ankerlinks und Probleme mit der Inhaltshöhe berücksichtigt habe.

Zweitens wollte ich etwas von der Magie zerstreuen, die dahinter steckt, wie Frameworks wie SenchaTouch oder iUI diesen Effekt ermöglicht haben. Als ich mich vor einiger Zeit entschied, SenchaTouch für ein freiberufliches Projekt zu verwenden, war die "Magie" des Frameworks, mit dem Apps den Bildschirm ausfüllen, einer der wichtigsten UX-Effekte, die mich angesprochen haben. Es ist wichtig zu wissen, dass der gleiche Effekt problemlos in reinem JS implementiert werden kann, unabhängig davon, ob Sie in Ihrem Projekt ein JavaScript-Framework verwenden oder nicht.

Schließlich war der Hauptgrund, warum ich dieses Problem so ausführlich ansprechen wollte, die Sensibilisierung dafür, wie launisch dieser Ansatz wirklich ist. Trotz der Tatsache, dass Variationen dieses Tricks weit verbreitet sind, glaube ich, dass es bestenfalls ein uneleganter Kludge und im schlimmsten Fall ein unzuverlässiger browserabhängiger Hack ist, der möglicherweise in Zukunft weiter funktioniert oder nicht. Ich möchte die Mitarbeiter des Browser-Geschäfts und der gesamten Web-/Mobile-Entwickler-Community auffordern, auf einen standardbasierten, JavaScript-unabhängigen Ansatz für den Umgang mit dieser UX-Überlegung zu drängen. Ich denke, die von Apple implementierte Meta-Tag-Methode ist ein großer Schritt in die richtige Richtung, aber wie oben erwähnt, wird sie den Anforderungen der Entwicklergemeinschaft nicht ausreichend gerecht.

Die eigentliche Frage ist: Was denken Sie? Lassen Sie uns im Kommentarbereich unten darüber sprechen.

Verbessern Sie diesen Code

Ich habe keinen Zweifel daran, dass einige unserer Leser den Code, den ich in diesem Tutorial bereitgestellt habe, möglicherweise verbessern können. Wenn Sie in diesem Beitrag etwas sehen, das optimiert oder verbessert werden könnte, hinterlassen Sie bitte unten Ihr Feedback! Sie können mich auch über Twitter (@markhammonds) erreichen, obwohl ich manchmal eine Weile brauche, um auf Tweets oder DMs zu antworten. Der beste Weg, mich zu erreichen, ist entweder in den Kommentaren unten oder über das Kontaktformular auf Mobileuts +. Wenn ich einen Ihrer Verbesserungsvorschläge akzeptiere, werde ich diesen Beitrag aktualisieren und Ihren Namen oder Handle zitieren!

Verweise

Wollen Sie nicht mein Wort für eines der oben genannten nehmen?

Schauen Sie sich die folgenden Ressourcen an, auf die ich bei der Recherche dieses Beitrags gestoßen bin:

Konfigurieren von Webanwendungen, Safari Developer Library
"Mobifizierung" Ihrer HTML5-Site, Eric Bidelman
Blenden Sie die Adressleiste in mobilen Webanwendungen aus, David Walsh
iPhone WebApps 101: Safari aus dem Weg räumen, Niels Leenheer