Présentation des compétences d'attribut de méta-fenêtre dans les pages Web HTML

Description de l'attribut HTML de la méta-fenêtre

Qu'est-ce que Viewport

Les navigateurs mobiles placent la page dans une "fenêtre" virtuelle (portée d'affichage), généralement cette "fenêtre" virtuelle est plus large que l'écran, de sorte que chaque page Web n'a pas besoin d'être compressée dans une petite fenêtre (cela détruirait la mise en page des pages Web qui ne sont pas optimisées pour les navigateurs mobiles. Les utilisateurs peuvent effectuer un panoramique et un zoom pour voir les différences entre les pages Web). . partie. La version mobile du navigateur Safari a récemment introduit la balise méta viewport, qui permet aux développeurs Web de contrôler la taille et le zoom de la fenêtre. D'autres navigateurs mobiles la prennent également en charge.

Principes de base de Viewport

La balise méta viewport d'une page couramment utilisée optimisée pour les pages Web mobiles est à peu près la suivante :

Le code est le suivant :

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

largeur : Contrôlez la taille de la fenêtre d'affichage. Vous pouvez spécifier une valeur, telle que 600, ou une valeur spéciale, telle que la largeur de l'appareil, qui est la largeur de l'appareil (l'unité est). Pixels CSS lors d'une mise à l'échelle à 100 %).
Hauteur : Correspondant à la largeur, précisez la hauteur.
initial-scale : Le taux de mise à l'échelle initial, c'est-à-dire le taux de mise à l'échelle lorsque la page est chargée pour la première fois.
échelle maximale : l'échelle maximale sur laquelle l'utilisateur est autorisé à zoomer.
échelle minimale : l'échelle minimale à laquelle l'utilisateur est autorisé à zoomer.
Évolutif par l'utilisateur : si l'utilisateur peut zoomer manuellement

Quelques questions sur la fenêtre d'affichage

La fenêtre d'affichage n'est pas seulement un attribut unique sur iOS, il existe également des fenêtres d'affichage sur Android et Winphone. Le problème qu'ils veulent résoudre est le même, c'est-à-dire ignorer la résolution réelle de l'appareil et réinitialiser directement la résolution entre la taille physique et le navigateur via dpi. Cette résolution n'a rien à voir avec la résolution de l'appareil. Par exemple, si vous prenez un iPhone 3 gs de 3,5 pouces-320*480, un iPhone 4 de 3,5 pouces-640*960 ou un iPad 2 de 9,7 pouces-1024*768, bien que les résolutions et les tailles physiques des appareils sont différents, vous pouvez définir la fenêtre d'affichage pour qu'ils aient la même résolution dans le navigateur. Par exemple, si votre site Web a une largeur de 800 px, vous pouvez définir la largeur de la fenêtre d'affichage sur 800 afin que votre site Web puisse être affiché sur tout l'écran sur ces trois appareils différents.

Je crois que tout étudiant qui a un peu de connaissances en viewport devrait déjà connaître les connaissances ci-dessus. Ce n’est pas l’objet de ce que je veux dire aujourd’hui. Ce que je veux expliquer, ce sont quelques différences dans les performances de la fenêtre d'affichage sur iOS et Android.

En recherchant des connaissances sur la fenêtre d'affichage sur Internet, toutes les informations sont essentiellement les suivantes :

Le code est le suivant :

<meta name="viewport" content="width=device-width,  initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0,  user-scalable=no" />

La signification de ce code est, laissez La largeur de la fenêtre d'affichage est égale à la résolution réelle sur l'appareil physique et ne permet pas à l'utilisateur de zoomer. Toutes les applications Web grand public sont configurées de cette manière. Sa fonction est d'abandonner délibérément la fenêtre d'affichage et de ne pas mettre à l'échelle la page. De cette façon, le dpi doit être le même que la résolution réelle de l'appareil. Sans aucune mise à l'échelle, la page Web le fera. paraître plus haut. Les étudiants qui jouent à PS devraient tous savoir à quoi cela ressemblera lorsque vous redimensionnerez directement une image de 1 000 * 1 000 à 500 * 500 points, n'est-ce pas ? La distorsion de l’image ne peut être évitée.

Mais l'application que je veux créer est tout le contraire. Elle doit utiliser la fenêtre d'affichage et le zoom. Quelle que soit la résolution réelle, quelle que soit la taille physique, je souhaite avoir une résolution uniforme dans le navigateur et ne pas permettre à l'utilisateur de zoomer. Les appareils que j'ai utilisés pour les tests incluent : l'iPhone 4, l'iPad 2, le G11 de HTC, le téléphone Aquos d'un fabricant inconnu (système Android), le pad Android d'ASUS et le winphone de Dell. Ensuite, j'ai rencontré les problèmes suivants en cours de route :

1) Si la fenêtre d'affichage n'est pas définie explicitement, la largeur par défaut est de 980. Si la largeur de tous les éléments de la page est inférieure à 980, la largeur est de 980. Si la position la plus large de la page dépasse 980, alors la largeur est égale à la largeur maximale. Bref, la page entière peut être affichée de gauche à droite par défaut. Si la fenêtre d'affichage est définie, par exemple, user-scalable=no est simplement défini, comme , alors la largeur sera toujours affichée à 980 sous iOS (c'est-à-dire que par défaut, il sera mis à l'échelle en dpi), mais il ne sera plus mis à l'échelle sous Android et Winphone. La résolution du navigateur est cohérente avec la résolution réelle des paramètres.

2) Pour les appareils iOS, le réglage de la largeur prendra 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. Sur Android, la largeur que vous définissez n'est pas valide. Ce que vous pouvez définir est un champ spécial target-densitydpi. Autrement dit, il y a trois variables : largeur du navigateur, largeur réelle de l'appareil, 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 qu'un 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 l'utilisateur- scalable= no ne prend pas effet, c'est-à-dire : , ce qui 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, et la largeur du navigateur peut être garantie quel que soit l'écran horizontal ou vertical. Elle est égale à la valeur définie dans la fenêtre, donc lorsque l'écran est horizontal ou vertical, 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 bande 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 n'est pas visible. 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.

Pour plus d'informations sur les techniques d'attributs de méta-fenêtre dans les pages Web HTML, veuillez prêter attention au site Web PHP chinois pour les articles connexes !