Detaillierte Beschreibung der Erstellung von HTML-Meta-Ansichtsfensterattributen_HTML/Xhtml_Webseiten

Was ist Viewport?

Mobile Browser platzieren die Seite in einem virtuellen „Fenster“ (Viewport). Normalerweise ist dieses virtuelle „Fenster“ (Viewport) breiter als der Bildschirm, sodass nicht jede Webseite gestaucht werden muss . In einem sehr kleinen Fenster (was das Layout einer Webseite zerstören würde, die nicht für mobile Browser optimiert ist) können Benutzer schwenken und zoomen, um verschiedene Teile der Webseite anzuzeigen. Die mobile Version des Safari-Browsers hat kürzlich das Viewport-Meta-Tag eingeführt, mit dem Webentwickler die Größe und den Zoom des Ansichtsfensters steuern können. Auch andere mobile Browser unterstützen dies grundsätzlich.

Grundlagen des Ansichtsfensters

Ein häufig verwendetes Ansichtsfenster-Meta-Tag für eine für mobile Webseiten optimierte Seite lautet ungefähr wie folgt:



Breite: Steueransichtsfenster Die Größe kann als Wert angegeben werden, z. B. 600, oder als spezieller Wert wie Gerätebreite, die die Breite des Geräts angibt (in CSS-Pixeln bei Skalierung auf 100 %).
Höhe: Geben Sie entsprechend der Breite die Höhe an.
Anfangsskalierung: Das anfängliche Skalierungsverhältnis, also das Skalierungsverhältnis, wenn die Seite zum ersten Mal geladen wird.
maximaler Maßstab: Der maximale Maßstab, auf den der Benutzer zoomen darf.
Minimalmaßstab: Der Mindestmaßstab, auf den der Benutzer zoomen darf.
Benutzerskalierbar: Ob der Benutzer manuell zoomen kann

Einige Fragen zum Ansichtsfenster

Ansichtsfenster sind nicht nur ein einzigartiges Attribut auf iOS, es gibt auch Ansichtsfenster auf Android und Winphone. Das Problem, das sie lösen möchten, ist das gleiche, nämlich das Ignorieren der tatsächlichen Auflösung des Geräts und das direkte Zurücksetzen der Auflösung zwischen der physischen Größe und dem Browser über dpi. Diese Auflösung hat nichts mit der Auflösung des Geräts zu tun. Wenn Sie beispielsweise ein 3,5-Zoll-320*480 iPhone 3 gs, ein 3,5-Zoll-640*960 iPhone 4 oder ein 9,7-Zoll-1024*768 iPad 2 nehmen, obwohl die Auflösungen und physischen Größen der Geräte unterschiedlich sind, können Sie das festlegen. Das Ansichtsfenster sorgt dafür, dass sie im Browser die gleiche Auflösung haben. Wenn Ihre Website beispielsweise 800 Pixel breit ist, können Sie die Breite des Ansichtsfensters auf 800 Pixel festlegen, damit Ihre Website auf diesen drei verschiedenen Geräten vollständig auf dem Bildschirm angezeigt werden kann.

Ich glaube, dass jeder Schüler, der ein wenig über Viewport-Kenntnisse verfügt, die oben genannten Kenntnisse bereits kennen sollte. Dies ist nicht der Schwerpunkt dessen, was ich heute sagen möchte. Was ich erklären möchte, sind einige Unterschiede in der Leistung von Viewport auf iOS und Android.

Bei der Suche nach Wissen über Ansichtsfenster im Internet lauten im Grunde alle Informationen wie folgt:



Die Bedeutung dieses Codes besteht darin, die Breite des zu bestimmen Ansichtsfenster entspricht dem physischen Gerät. Echte Auflösung aktiviert, keine Benutzerskalierung möglich. Alle gängigen Web-Apps sind so eingerichtet, dass sie bewusst auf das Ansichtsfenster verzichten und die Seite nicht skalieren. Auf diese Weise muss die Auflösung der tatsächlichen Auflösung der Webseite entsprechen höher erscheinen. Schüler, die PS spielen, sollten alle wissen, wie es aussieht, wenn man ein 1000 * 1000-Bild direkt auf 500 * 500 Punkte skaliert, oder? Der Verzerrung des Bildes kann man sich nicht entziehen.

Aber die Anwendung, die ich erstellen möchte, ist genau das Gegenteil. Sie muss Ansichtsfenster und Zoom verwenden. Unabhängig von der tatsächlichen Auflösung und der physischen Größe möchte ich eine einheitliche Auflösung im Browser haben und dem Benutzer kein Zoomen ermöglichen. Zu den Geräten, die ich zum Testen verwendet habe, gehören: iPhone 4, iPad 2, HTC G11, Aquos Phone (Android-System) eines unbekannten Herstellers, ASUS Android Pad und Dell WinPhone. Dann stieß ich auf die folgenden Probleme:

1) Wenn der Ansichtsbereich nicht explizit festgelegt ist, beträgt die Breite standardmäßig 980. Wenn die Breite aller Elemente auf der Seite weniger als 980 beträgt, beträgt die Breite 980. Wenn die breiteste Position der Seite 980 überschreitet, entspricht die Breite der maximalen Breite. Kurz gesagt, die gesamte Seite kann standardmäßig von links nach rechts angezeigt werden. Wenn das Ansichtsfenster beispielsweise einfach auf user-scalable=no gesetzt ist, z. B. , wird die Breite unter iOS immer noch mit 980 angezeigt (d. h. standardmäßig wird sie mit dpi skaliert), aber Unter Android und Winphone wird sie nicht angezeigt. Nach der Skalierung stimmt die Browserauflösung mit der tatsächlichen Einstellungsauflösung überein.

2) Pour les appareils iOS, le réglage de la largeur peut prendre effet, mais pour Android, le réglage de la largeur ne prendra pas effet. Pour les appareils iOS, le rapport de mise à l'échelle, c'est-à-dire le dpi, est automatiquement calculé en fonction de la largeur que vous définissez et de la résolution réelle. Cependant, sous Android, la largeur que vous définissez n'est pas valide. Ce que vous pouvez définir est un champ spécial target-densitydpi. . Vous pouvez vous référer à target-densitydpi pour plus d'informations : http://hi.baidu.com/j_fo/blog/item /748361279ebccd18908f9d7d.html. En d’autres termes, il existe trois variables : la largeur du navigateur, la largeur réelle de l’appareil et le dpi. Utilisons simplement une formule pour exprimer la relation entre elles (pas une relation réelle, juste pour une explication simple) Largeur réelle de l'appareil * dpi = largeur du navigateur ici, la largeur réelle de l'appareil est une valeur connue que nous ne pouvons pas utiliser. . , nous pouvons définir l'une des deux autres variables pour qu'elle affecte l'autre. Dans iOS, ce que nous pouvons modifier, c'est la largeur du navigateur, et le dpi est automatiquement généré. Dans Android, ce que nous pouvons modifier, c'est le dpi et la largeur du navigateur. est généré automatiquement. Pour Android, quelle que soit la manière dont nous définissons la largeur, cela n’affectera pas la largeur du navigateur.

ps : Laissez-moi parler d'un autre problème étrange ici : dans le g11 de HTC (je n'ai que ce seul téléphone HTC, et je n'ai pas testé les autres), si le dpi est défini sans définir explicitement la largeur, alors user -scalable=no ne prend pas effet, c'est-à-dire : , on ne peut pas empêcher l'utilisateur de redimensionner l'écran. Nous devons définir explicitement la valeur de la largeur. Même si cette valeur n'a aucun impact sur la résolution du navigateur sous Android (elle aura toujours un impact sur iOS), nous devons quand même la définir, et cette valeur doit être supérieure à 320. S'il est inférieur ou égal à 320, user-scalable=no ne peut pas prendre effet. Ce problème ne se produit que sur le téléphone HTC G11, pas sur le téléphone Aquos. Être compatible avec Android est vraiment un casse-tête @_@ Je ne sais pas combien d'embûches il y aura dans le futur. Sur Winphone, le résultat est encore plus étrange : si je règle la largeur de la fenêtre sur une valeur supérieure à 480, user-scalable=no ne sera pas valide, mais si je définis une valeur inférieure à 480, user-scalable=no prendra effet. Mais quelle que soit la valeur que j'ai définie pour la largeur de la fenêtre d'affichage, elle n'a pas l'impact attendu sur la largeur réellement affichée par Winphone, et target-densitydpi n'a aucun impact non plus. Définissez la largeur. Si elle est inférieure à 480, l'écran sera mis à l'échelle, mais le rapport de mise à l'échelle est complètement différent de ce à quoi je m'attendais. Je ne sais pas s'il s'agit d'un problème Winphone ou d'un problème d'implémentation Dell.

3) Cet article doit être directement lié au précédent : lorsque l'appareil iOS est en écran horizontal ou vertical, il ajustera automatiquement le dpi. Quel que soit l'écran horizontal ou l'écran vertical, il peut assurer. que la largeur du navigateur est égale à la valeur définie dans la fenêtre, donc lorsque l'écran est en mode paysage ou portrait, la taille du contenu affiché sur la page sera automatiquement mise à l'échelle et modifiée. Lorsque le téléphone Android est en mode paysage ou portrait, le dpi ne changera pas, et lorsque l'écran est en mode paysage ou portrait, la page Web ne sera pas zoomée. Pour cette raison, iOS peut garantir que les pages d'écran horizontales et verticales n'auront pas de barres de défilement et ne rempliront pas l'écran, mais Android ne peut pas garantir cela. Si l'écran est plein horizontalement, il ne peut pas être plein écran verticalement, et vice versa.

4) Pour les appareils ios, si la largeur d'affichage est définie et que la position la plus large de la page dépasse la largeur, la largeur n'est pas valide et sera toujours affichée selon la largeur la plus large (il n'y aura pas de barre de défilement ). Mais un problème très étrange surviendra à ce moment-là. Après avoir basculé plusieurs fois l'écran de votre téléphone entre paysage et portrait, vous constaterez que votre page est automatiquement agrandie et qu'une barre de défilement apparaît, mais en fait, la largeur agrandie ne l'est pas. la même chose que la largeur que vous définissez. Cela n'a pas d'importance. Pour éviter cela, vous devez définir une largeur supérieure ou égale à la partie la plus large de la page.