Html5-boilerplate: Meta "Ansichtsfenster" funktioniert nicht richtig

Vielen Dank, dass Sie dieses Problem @Fatbat gemeldet haben!

Der anfängliche Skalenwert wurde zuvor diskutiert . Es wurde aus dem HTML5-Boilerplate entfernt, da es beim Drehen eines Mobilgeräts einen bösen Fehler verursachte: Geräte zoomen nicht richtig.
Dies kann verhindert werden, indem maximun-scale=1 hinzugefügt wird, wodurch Sie nicht mehr zoomen können. Dies ist ein Problem mit der Barrierefreiheit, auf das im Kommentar hingewiesen wird.

Meine Meinung zu diesem Thema ist, dass wir die beiden Parameter nicht erneut zum Boilerplate hinzufügen sollten, sondern die Leute ermutigen sollten, diese zu ändern und ihnen mehr darüber mit einem detaillierteren Kommentar in HTML zu erzählen (außerdem würde ich vorschlagen, nicht nur auf # 37 zu

Entschuldigung für die Eröffnung einer weiteren Ausgabe. Meine Git-Etikette entspricht nicht dem Schnupftabak. Sollten wir hier weiter darüber sprechen oder sollte ich es in einem der vorherigen Threads zu diesem Thema diskutieren?

Kein Grund zur Sorge. Ich wollte dich nur dorthin zeigen.
Es ist gut, dieses Problem erneut zu diskutieren und, wie gesagt, weitere Dokumentationen dazu hinzuzufügen, da es für Entwickler unklar zu sein scheint, wie dieses Tag verwendet wird.

Vielen Dank. Ja, zusätzliche Dokumentation wäre gut. Ich bin jedoch der Meinung, dass das aktuelle Verhalten, zumindest auf dem iPad2, nicht wünschenswert ist. Obwohl ich den Bildschirm im Querformat mit 1024 Pixel zur Verfügung stelle, zoomt meine Website so, als würde ich ihn im Hochformat mit 768 Pixel betrachten. Aber es zoomt nicht nur den Text und andere CSS-Elemente auf der Seite, es sprengt auch Grafiken und als solche sind sie verschwommen. Dadurch wird die Seite gezwungen, einen Haltepunkt für Medienabfragen zu erhöhen, wenn dies nicht erforderlich ist.

Wir haben also bereits die Optionen besprochen:

    <meta name="viewport" content="width=device-width">

Dadurch wird eine 768px-Site im Querformat in 1024px Speicherplatz gezwungen, indem alle Elemente auf der Seite künstlich gezoomt werden. Der Porträtmodus funktioniert wie erwartet.

Oder:

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

Dadurch wird die Site sowohl im Quer- als auch im Hochformat korrekt angezeigt und der richtige Haltepunkt für Medienabfragen für beide angezeigt. Wenn Sie von Querformat zu Hochformat drehen, wird die Site links in der Breite der Bildlaufleiste abgeschnitten und erfordert eine Prise, damit sie korrekt zentriert wird. Sie können leider nicht zoomen.

Oder:

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

Dadurch wird die Site sowohl im Quer- als auch im Hochformat korrekt angezeigt, und es werden auch beide Haltepunkte für Medienabfragen für beide angezeigt. Wenn Sie von Querformat zu Hochformat drehen, wird die Site links abgeschnitten und erfordert eine Prise, um sie zu zentrieren. Wenn Sie jedoch vom Hochformat zum Querformat zurückdrehen, wird die Site vergrößert und erfordert auch eine Prise, um sie zu verkleinern und neu zu zentrieren (ist dies der Fehler, der zuvor besprochen wurde?).

Oder:

Lassen Sie das Ansichtsfenster-Meta vollständig deaktiviert und die Site wird so skaliert, dass sie zur Seite im Hochformat passt, und der Haltepunkt für Medienabfragen wird nicht eingehalten und überhaupt nicht ausgelöst.

Gibt es noch andere Möglichkeiten?

Vielen Dank. Ich bin auch auf diesen iPad-Fehler / cc @alexgibson gestoßen

Es scheint nicht so, als ob jemand darüber diskutieren möchte. Vielleicht wurde das Problem bereits zu Tode gebracht.

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

Ich bin damit gegangen, kann die Option nicht selbst zoomen. Da ich eine mobile freundliche Website erstelle, die in kleinen Größen funktionieren sollte, mit verkleinerten Bildern und großem Text, sollte das Zoomen nicht erforderlich sein, außer für Menschen mit Sehbehinderung. Wenn jemand andere Vorschläge hat, würde ich sie gerne hören.

Ich kann nur wirklich wiederholen, was

Danke Alex.

Das Zoomen von Websites auf Mobilgeräten ist eine wichtige Erwartung und wird häufig verwendet. Wir möchten nicht standardmäßig ein Problem mit der Zugänglichkeit und Benutzerfreundlichkeit einführen, aber die Boilerplate ist so konzipiert, dass sie je nach Bedarf angepasst werden kann. Im Moment bleiben wir bei der vorhandenen Ansichtsfensteroption, bis etwas Besseres (und Robustes) hinzukommt.

Ich bin wirklich kein Experte auf diesem Gebiet, aber ich habe 5-6 RWD-Sites erstellt und basierend auf dieser Erfahrung sehe ich wirklich keinen Sinn darin, Benutzern die Zoomoption _WENN SIE RWD-SITE_ TUN_ zuzulassen.

Die meisten meiner Tests wurden auf http://responsive.is/ durchgeführt und 320px wurde auf einem Mobiltelefon getestet. Beim Testen auf dem Handy musste ich wirklich selten vergrößern / verkleinern, da alles wirklich gut sichtbar / lesbar war.

Orientierungsänderung war und ist das, was ich an RWD hasse. Das Nicht-Zoomen mit <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1"> zuzulassen, hat mir beim Umgang mit verschiedenen Haltepunkten, Telefonen, Tablets ... sehr geholfen.

Ich denke nicht, dass die Standardeinstellung zufriedenstellend ist, da reaktionsfähige Websites, die auf einem iPad2 im Querformat angezeigt werden, einfach beschädigt sind, dh 768 Pixel, die schlecht in 1024 Pixel interpoliert wurden, wodurch alle Grafiken verschwommen werden. Dies kann vom Betrachter auch nicht wirklich behoben werden, es sei denn, er dreht sich zum Hochformat, die Site bleibt in diesem unscharfen Modus hängen. Meiner Ansicht nach...

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

ist eine bessere Standardoption, da reaktionsfähige Websites sowohl im Hoch- als auch im Querformat korrekt angezeigt werden. Der Fehler, den ich zumindest auf dem iPad sehe, tritt nur beim Drehen von Hochformat zu Querformat auf und kann mit einer einfachen Prise nach unten behoben werden. Leider weiß ich nichts über Fehler auf anderen Geräten.

• "Der Fehler, den ich zumindest auf dem iPad sehe, tritt nur beim Drehen von Hochformat in Querformat auf und kann mit einer einfachen Prise behoben werden."

Der gleiche Fehler tritt auch auf dem iPhone auf. Ich denke, das Verhalten dieses "Fehlers" lässt Websites "defekter" erscheinen als das Betriebssystem, das sein Standardverhalten ausführt, das beim Drehen zoomt.

Es wird jedoch nicht beim Drehen gezoomt. Wenn Sie im Querformat surfen, wird die Site standardmäßig immer so geladen, als wäre sie 768px statt 1024px groß, und der Benutzer kann nichts dagegen tun. Es bleibt bei dieser Auflösung hängen und alles ist permanent verschwommen. Während bei dem anderen beschriebenen Problem der Benutzer das Problem mit einer einfachen Prise lösen kann und es nur auftritt, wenn Sie von Hochformat zu Querformat wechseln, was die Leute IMO nicht oft tun. Menschen neigen dazu, in der einen oder anderen Ausrichtung zu surfen, je nach ihren persönlichen Vorlieben.

Außerdem habe ich tatsächlich gesehen, dass dieser Fehler ziemlich schlechte Ergebnisse hat, insbesondere wenn Sie Elemente voller Breite (wie Oberleisten) mit einem untergeordneten Element mit eingeschränkter Breite verwenden. Sieht völlig kaputt aus, da die Berechnung für das Element voller Breite falsch ist und Sie möglicherweise die Hintergrundfarbe des Körpers in einer Spalte auf der rechten Seite sehen, wobei sich Textteile überlappen usw. Ein Durcheinander.

@fatbat - Vielleicht sollten Sie einfach entscheiden, was für Ihre Website und ihre Benutzer am besten ist. Die Standardeinstellung in Boilerplate ist genau das. Ein Standardstartpunkt, an den Sie sich nicht halten sollten.

Persönlich drehe ich mein iOS-Gerät, um Safari zu vergrößern und Artikel zu lesen. Genau so hat Apple entschieden, dass sich Safari so verhalten soll. Ja, Bilder sehen unschärfer aus (Netzhautbilder sind ein viel größeres Problem), aber CSS und Text sind immer noch scharf. Wenn Sie nicht möchten, dass sich Ihre Website so verhält, liegt es an Ihnen… aber bis Apple das Verhalten des Ansichtsfensters ändert, ist dies die Situation.

@alexgibson Um fair zu sein, kann das Endergebnis dieser Standardeinstellung auf dem iPad ziemlich kaputt aussehen. Ich bin darüber gestolpert und wir haben eine Weile versucht herauszufinden, was CSS verursacht hat, bis wir festgestellt haben, dass es sich um das Meta des Ansichtsfensters handelt.

Vielleicht verdient dies dann mehr Nachforschungen… wäre interessiert, mehr herauszufinden :)

@necolas , hier gleich. Ich saß eine ganze Weile hier und kratzte mir am Kopf, um herauszufinden, was los war :)

@alexgibson , bitte entlassen Sie mich nicht zusammenfassend. Ich bin so ziemlich ein Neuling im Vergleich zu einigen Kenntnissen und Talenten in diesen Bereichen, aber ich denke, das ist ein Problem. Websites funktionieren mit dieser Standardeinstellung nicht wie erwartet und sehen daher auch nicht besonders gut aus. Arbeiten sie wie erwartet mit den anderen zusammen? Wahrscheinlich nicht, aber ich denke, es könnte eine bessere Option geben.

@fatbat - will nicht abweisend sein, deine Meinung und die Zeit, ein Problem zu eröffnen, werden immer geschätzt :)

Ich habe immer noch Vorbehalte gegen diese Immobilie, aber wenn es neue Probleme gibt, lohnt es sich, sie zu erkunden.

f4ca79034d4b0a3905682df4b8c506d98f35c5f6

Dies könnte eine Lösung sein? Es ist eine Zeile von jQuery, mit der Sie initial-scale = 1.0 verwenden können und die den Zoom-Fehler behebt.

@ JCB-K - Dies ist zwar eine sehr clevere Lösung für den Zoom-Fehler (und sollte auf jeden Fall im Wiki verlinkt sein), aber ich denke, wir sollten vorsichtig sein, wenn wir uns entscheiden, dies als Standard aufzunehmen. Es verwendet einen Gerätebeschleunigungsmesser, um auf Orientierungsänderungen zu achten, was ziemlich CPU-intensiv ist und den Akku schneller verbraucht.

@alexgibson Interessant, habe nicht einmal darüber

AFAIK, Beschleunigungsmesser ist immer aktiv, wenn Sie auf Gerätebewegung warten, sodass ständig Daten abgefragt werden.

Dann stimme ich definitiv zu, dass dies keine praktikable Option ist. Hoffen wir nur, dass Apple diesen Fehler in iOS 6 behebt :).

@alexgibson irgendeinen Link über "Beschleunigungsmesser immer an" zu teilen?

Wie werden Orientierungsänderungen normalerweise erkannt?

Auf SO wurde Goldmaterial gefunden:

http://stackoverflow.com/questions/1649086/detect-rotation-of-android-phone-in-the-browser-with-javascript

@Fatbat Unter iOS gibt es verschiedene Möglichkeiten, Bewegungen oder Orientierungen (2 verschiedene Dinge!) Zu erkennen. Normalerweise würden Sie eine API abfragen, die Ihnen die aktuelle Ausrichtung angibt (Sie müssen sie also nicht selbst erkennen), aber das funktioniert für diesen bestimmten Fix nicht. Die Funktionsweise von jQuery besteht darin, dass der Beschleunigungsmesser beobachtet wird, um eine Rotationsänderung zu erkennen, und dann den Zoom schnell deaktiviert. Wenn die Rotation abgeschlossen ist, wird der Zoom wieder aktiviert.

Einige Hintergrundinformationen zu iOS-Ereignis-APIs finden Sie hier .

Hallo Leute! @necolas hat mich gebeten, hier einzuspringen und Hintergrundinformationen zu der oben verlinkten

Die einfachste Möglichkeit, diesen Fehler zu umgehen, besteht darin, den Parameter initial-scale wegzulassen, wie dies in H5bp der Fall war. Dies verhindert zwar, dass eine Seite beim Ändern der Landschaft in iOS über die Einschränkungen des Ansichtsfensters hinaus skaliert, weist jedoch wie alle anderen bekannten Problemumgehungen einige Nachteile auf, die Sie möglicherweise berücksichtigen:

Wenn Sie in die Querformatausrichtung wechseln und initial-scale ausgelassen haben, wird das Hochformat einfach vergrößert, um der Breite des Querformat-Ansichtsfensters zu entsprechen, anstatt das Layout neu zu fließen, um die rund 300 Pixel zu nutzen, die im Querformat verfügbar sind. Dies ist das Verhalten, das Sie heute in h5pb sehen werden. Dies verhindert zwar erfolgreich das Problem mit dem zugeschnittenen Layout, das mit der Verwendung von initial-scale , das Verhalten kann jedoch unerwartet sein, insbesondere wenn Sie gewohnt sind, zu sehen, wie andere Geräte häufig mit Änderungen der Ausrichtung umgehen, oder wenn Sie Websites verwendet haben Dadurch wird die Benutzerskalierung deaktiviert (da dies dazu führt, dass eine Seite wie erwartet reflowt, mit dem erheblichen Nachteil, dass das Zoomen nicht funktioniert).

Der eigentliche Fehler hier (von Apple vor Jahren in ihrem Tracker akzeptiert) ist folgender: Jedes Mal, wenn die Benutzerskalierung aktiviert ist, zoomt iOS die Seite tatsächlich immer um ein Vielfaches von viewport width / viewport height , unabhängig davon, ob initial-scale wird verwendet. Auf dem iPad entspricht das einem Zoom von 130%, und auf dem iPhone ist es meiner Meinung nach etwas mehr. Wenn Ihre Seite Raster-Assets enthält - Bilder, Logos usw. - werden diese wahrscheinlich pixelig und etwas hässlich. Wenn `initial-scale = 1 'verwendet wird, fließt das Layout neu, um die Querformatbreite zu nutzen, was viele von uns erwarten. Da der Zoomfehler jedoch weiterhin auftritt, wird das Layout am Ende breiter skaliert als die Breite des Ansichtsfensters und das kann zu einer ziemlich verwirrenden Erfahrung führen.

Die oben genannte Technik versucht, dieses Problem zu umgehen (Reflow erzwingen), während die Benutzerskalierung beibehalten wird. Dies geschieht durch Abhören von devicemotion -Ereignissen, um festzustellen, wann ein orientationchange vom Hoch- zum Querformat bevorsteht. Wenn ein iOS-Gerät auf eine der verschiedenen Arten gekippt wird, die eine Änderung auslösen, deaktiviert das Skript vorübergehend die Benutzerskalierung, um einen reibungslosen Reflow bei der Änderung der Ausrichtung und nach einer Änderung zu ermöglichen, oder wenn das Gerät wieder aus dem System gekippt wird "Gefahrenzone" wieder, Benutzerskalierung wird wieder aktiviert.

Diese Problemumgehung ist mit Kosten verbunden wie jede andere: Sie führt ein bisschen JavaScript auf der Seite ein, das sonst nicht vorhanden gewesen wäre und das auf Nicht-iOS-Geräten nicht benötigt wird (obwohl eine Reihe von UA ​​darin enthalten ist) um sicherzustellen, dass es zumindest nur in iOS ausgeführt wird).

Das Skript hört aus mehreren Gründen devicemotion Ereignisse statt deviceorientation : breitere iOS-Unterstützung und bessere Akkulaufzeit, da deviceorientation Standortdienste abfragen, wenn sie aktiviert sind, z welcher Grund auch immer. Die Problemumgehung ist im jQuery Mobile-Framework enthalten und daher auf iOS-Geräten sehr gut getestet.

Der Code für die Problemumgehung wird in der Projekt-README -Datei minimiert, und die nicht minimierte Quelle befindet sich hier

Weitere Informationen zu dem Fehler, dieser Problemumgehung und anderen Problemumgehungen finden Sie auch im Tracker für Gerätefehler: https://github.com/scottjehl/Device-Bugs/issues/2

Ich hoffe das hilft!

@scottjehl Danke für die klaren Informationen. Haben Sie genauere Informationen zu den Auswirkungen auf die Akkulaufzeit?

Bemerkenswert zu Scotts Kommentaren:

Unter iOS 5.1.1 scheint devicemotion immer noch regelmäßig Standortdienste abzufragen, wenn ich hier teste. Sie können dies überprüfen, indem Sie zu:

Einstellungen -> Ortungsdienste -> Systemdienste -> und setzen Sie die Kompasskalibrierung auf Ein.

Dadurch erhalten Sie jedes Mal das lila Pfeilsymbol in der Statusleiste, wenn das Gerät einen Geolocation-Anruf tätigt, um die Kompassrichtung zu kalibrieren. Wenn eine Webseite geöffnet ist und devicemotion abfragt, wird das Symbol regelmäßig angezeigt. Dies gilt insbesondere für unterwegs mit 3G (z. B. im Zug).

Ich kann keine genauen Statistiken zu den Effekten abgeben, aber die Verwendung des Beschleunigungsmessers (und der Geolokalisierung) verbraucht viel CPU und leert den Akku zwangsläufig schneller. Dies gilt für native Apps, die Bewegungssensoren verwenden, genauso wie für Safari.

Wirklich interessanter Thread.

Ich bin bei meinem ersten Responsive-Projekt (erst vor wenigen Wochen) auf dieses Problem gestoßen und habe falsch interpretiert, was vor sich ging.

Seien Sie sich also bewusst: Ich befürworte keine der folgenden Aussagen, sondern möchte vielleicht etwas Licht darauf werfen, wie einige Entwickler, die neu bei RWD sind, diese Situation interpretieren könnten.

Ich stellte fest, dass Geräte mit Retina-Displays (z. B. das iPad 3 und das iPhone 4, auf denen ich getestet habe) unterschiedliche Breitenwerte für meine Medienabfragen zurückgaben, um ihre hohe Pixeldichte zu kompensieren. Mit anderen Worten, wenn ich meiner Medienabfrage mitteile, dass der Bildschirm zwei Drittel so breit (in Pixel) ist, wie er tatsächlich ist, damit lesbarer Text auf einer normalen Anzeige nicht kleiner wird und auf der Retina-Anzeige nicht mehr lesbar ist.

Ich habe dieses wahrgenommene Problem umgangen, indem ich Anzeigen mit höherer Pixeldichte abgefragt und darin meine Gesamtschriftgröße geändert sowie größere Hintergrundbilder geladen und mit der Hintergrundgröße verkleinert habe, um so die Unschärfe zu umgehen, die Sie in den Bildern auf diesen sehen Geräte. Keine ideale Lösung, aber es funktionierte in dem Sinne, dass es die Probleme löste, die ich gerade hatte ... Aber jetzt sehe ich, dass ich völlig falsch verstanden habe, was los war.

Ich werde auf jeden Fall darüber nachdenken, wenn ich das nächste Mal an einem RWD-Projekt arbeite.

Ich denke, dass es sich in vielen Fällen lohnt, ein responsives Design für Displays mit höherer Pixeldichte neu auszurichten, aber ich sehe jetzt, dass dies nichts mit dem Problem zu tun hat, das ich hatte!

@scottjehl hat einen tollen Beitrag gemacht. Irgendwelche weiteren Gedanken zu diesem Thema, Leute?

Auch ich würde gerne wissen, welche Auswirkungen der jQuery-Fix ​​auf die Akkulaufzeit haben würde, wenn er auf einer Site implementiert wird. Wäre der Batterieverbrauch viel größer als normal oder vernachlässigbar?

Wir haben generell vermieden, JavaScript-Problemumgehungen (insbesondere jQuery) einzuschließen. Es kann einen gewissen Wert haben, diesen in irgendeiner Form einzuschließen (z. B. nicht tatsächlich verwendet, aber im JS-Verzeichnis bereitgestellt).

Vielen Dank. Nur um zu verdeutlichen, dass diese Problemumgehung nicht von der Abfrage abhängt.
Am 6. Juni 2012, 4:06 Uhr, "Brad Shaw" <
[email protected]>
schrieb:

@scottjehl hat einen tollen Beitrag gemacht. Irgendwelche weiteren Gedanken zu diesem Thema, Leute?

Auch ich würde gerne wissen, welche Auswirkungen die jQuery auf die Akkulaufzeit hat
Fix hätte bei Implementierung auf einer Site. Wäre der Batterieverbrauch viel
größer als normal oder wäre es vernachlässigbar?

---

Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an:
https://github.com/h5bp/html5-boilerplate/issues/1099#issuecomment -6145150

Einige gute Nachrichten Leute, anscheinend ist dies in iOS 6 behoben!

https://twitter.com/wilto/status/212636063762628608

Hab das gestern auch gesehen - tolle Neuigkeiten

Das sind gute Nachrichten. Was ist die ETA unter iOS 6?

@Fatbat Es ist noch kein offizielles Wort bekannt, aber höchstwahrscheinlich um den Oktober herum, was mit dem wahrscheinlichen iPhone-Upgrade zusammenfällt. Die Adoptionsraten unter iOS sind sehr hoch. Ich gehe davon aus, dass bis Ende des Jahres 3/4 der Nutzer 6 sein werden, wenn nicht sogar mehr.

Das ursprüngliche Problem in diesem Bericht wird, wie ich es verstehe, verursacht, wenn Sie das iPad im Querformat haben, aber die Seite mit ihrem Ansichtsfenster-Metaelement angibt, dass die Ansichtsfensterbreite (derzeit der längeren Seite des iPad zugeordnet) gewünscht wird. die Gerätebreite sein (immer die kürzere Seite); Daher verwendet es das 768px-CSS, sieht vergrößert aus usw.

Eine anfängliche Skalierung = 1 würde dies beheben, aber dies hat dann den Rotationsfehler unter iOS. Wie wäre es also mit:

<meta name="viewport" content="initial-scale=1">

Damit Sie einem Landschaftsgerät nicht sagen, dass die Breite des Ansichtsfensters auf die Breite des Porträts eingestellt sein soll.

https://gist.github.com/1410787 hat kein Ansichtsfenster von nur anfänglicher Größe getestet, an dem ich sehr interessiert gewesen wäre. Ich habe dieses Meta-Ansichtsfenster in Android und iOS getestet (obwohl ich meins nicht finden kann) iOS-Testergebnisse, sorry), und es scheint genau das zu tun, was Sie sowohl im Hoch- als auch im Querformat erwarten würden, aber ich gebe voll und ganz zu, dass ich nicht genug Tests durchgeführt habe, um als gut zu gelten (und es ist spät und jetzt bin ich es besorgt, dass es sowieso den iOS-Bug hat und ich habe es vergessen, aber hey). Aber da es nicht in Betracht gezogen worden zu sein scheint, dachte ich, ich würde es erwähnen.

http://developer.apple.com/library/ios/#DOCUMENTATION/AppleApplications/Reference/SafariWebContent/UsingtheViewport/UsingtheViewport.html lautet: "Wenn Sie beispielsweise die Skalierung auf 1,0 festlegen, geht Safari davon aus, dass die Breite geräte- ist. Breite im Hochformat und Gerätehöhe im Querformat. " - was Sie in Bezug auf die Standardeinstellung wünschen würden.

Schließen Sie dies als "wontfix". Die iOS-Fehler existieren seit Jahren und es gibt keine einfache Lösung für sie, und die Behebung ist in iOS6 auf dem Weg. Vielen Dank für alle Beiträge und nützlichen Infos.

Was, wenn überhaupt, würde H5BP das Meta-Tag ändern, wenn nur iOS6 in Betracht gezogen wird?

Da das Mobile Boilerplate wieder initial-scale=1 hinzugefügt hat (siehe h5bp / Mobile-Boilerplate # 140) und iOS6 seit einiger Zeit verfügbar ist, habe ich mich gefragt, ob wir es auch wieder hinzufügen sollten.

Meinungen?

Nach meinem obigen Kommentar haben er und Bruce Lawson nach einem kürzlich veröffentlichten Blog-Beitrag von Stu Robson letzte Woche freundlicherweise einige Tests durchgeführt, um nur initial-scale=1 ohne width=device-width . iOS geht dann gemäß den verlinkten Dokumenten von width=device-width im Hochformat und von width=device-height im Querformat aus. Unter iOS ist device-width auf die Porträtbreite des Geräts festgelegt, während in anderen Browsern (z. B. Firefox ) die Gerätebreite die Breite des Geräts in seiner aktuellen Ausrichtung ist ( device-width , um definitiv die aktuelle Breite oder definitiv die Porträtbreite zu bedeuten, wird manchmal immer fehlschlagen.

Beachten Sie die Apple-Dokumentbeispiele in Abbildung 3-14 (mit initial-scale=1.0 ), Abbildung 3-15 (mit width=device-width auf einem iPhone) und Abbildung 3-17 (mit width=980,initial-scale=1.0 ). . Etwas nervig ist das letzte Beispiel nicht width=device-width ;) Aber mit width=device-width,initial-scale=1.0 iOS die aktuelle Breite des Geräts (nicht die Gerätebreite!) Im Querformat, so als ob die Breite wäre überhaupt nicht vorhanden.

Nur initial-scale=1.0 scheint in mehreren Browsern [1] [2] [3] gut zu funktionieren, abgesehen von WP7, aber WP7 hat anscheinend ein eigenes Problem darin, dass device-width hartcodiert ist, um gleich zu sein bis 320 [1] [2] - ein bisschen blöd, wenn Sie eine 480x800 haben, nehme ich an! Wenn Sie die Breite nicht angeben, ist dies möglicherweise besser für Sie. Ich sehe auch einen Fall aus, in dem die Breite für einige Android-Geräte angegeben werden sagt, es war HTC, 2010, Android 2.2, obwohl Stu sagte, dass 2.2 oben in Ordnung war).

Patrick Lauke stellte freundlicherweise die Testdatei zur Verfügung .

Hoffe, das ist hilfreich bei Ihren Überlegungen. Ich bin definitiv dafür, dass initial-scale eine Verbesserung der Boilerplate darstellt, unabhängig davon, ob width beibehalten wird oder nicht.

Chrome meldet einen Fehler in tatsächlicher Form:

Metaname = "Ansichtsfenster" Inhalt = "Breite = Gerätebreite; Anfangsskala = 1,0"

Viewport-Argumentwert "Gerätebreite;" für Schlüssel "width" ist ungültig und wurde ignoriert. Beachten Sie, dass ';' ist kein Trennzeichen in Ansichtsfensterwerten. Die Liste sollte durch Kommas getrennt sein.

Ich denke zumindest kann dies geändert werden ...

Wie der Fehler besagt, haben Sie anstelle eines Kommas ein Semikolon verwendet. Das aktuelle Boilerplate verwendet auch kein (daher dieses Ticket) / Mobile Boilerplate verwendet ein Komma. Verwenden Sie ein Komma und es ist in Ordnung.

Ich habe nicht bemerkt, dass die aktuelle Version auch nicht verwendet, daher ich
hat meine Kesselplatte vor einigen Tagen aktualisiert ...
Viele Grüße, Attila

Am 13.05.2013 19:29 schrieb Matthew Somerville:

Wie der Fehler besagt, haben Sie anstelle eines Kommas ein Semikolon verwendet. Das
Das aktuelle Boilerplate verwendet auch nicht (daher dieses Ticket) / mobile
Boilerplate verwendet ein Komma. Verwenden Sie ein Komma und es ist in Ordnung.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/h5bp/html5-boilerplate/issues/1099#issuecomment -17823164.

Behoben durch ff37dba6bf025a00f58b2bb12f7c6a827e6643c5