Maison >interface Web >tutoriel HTML >Attribut de fenêtre méta HTML description_HTML/Xhtml_production de pages Web

Attribut de fenêtre méta HTML description_HTML/Xhtml_production de pages Web

WBOY
WBOYoriginal
2016-05-16 16:38:091485parcourir

Qu'est-ce que Viewport

Les navigateurs mobiles placent la page dans une « fenêtre » virtuelle (port d'affichage). Habituellement, cette « fenêtre » virtuelle (port d'affichage) 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 brisera 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 différentes parties de la page Web. 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.

Bases de la fenêtre d'affichage

Une balise méta de fenêtre d'affichage couramment utilisée pour les pages optimisées pour les mobiles est à peu près la suivante :

width : contrôle 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 en pixels CSS lors d'un zoom à 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 : indique si l'utilisateur peut évoluer manuellement

Quelques questions sur la fenêtre d'affichage

Viewport n'est pas seulement un attribut unique sur iOS, il existe également des fenêtres 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 pixels, vous pouvez définir la largeur de la fenêtre d'affichage sur 800 pour permettre à votre site Web de s'afficher entièrement à 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.

Lors de la recherche de connaissances sur la fenêtre d'affichage sur Internet, toutes les informations sont essentiellement les suivantes :

La signification de ce code est de rendre la largeur de la fenêtre égale à la résolution réelle sur l'appareil physique et de ne pas permettre à 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 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. 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. La compatibilité 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 mode paysage ou portrait, il ajustera automatiquement le dpi. Quel que soit l'écran paysage ou portrait, il peut garantir que la largeur du navigateur est la même. égale à la valeur définie dans la fenêtre, donc la largeur du navigateur sera égale à la valeur définie dans la fenêtre. Lorsque l'écran est allumé, 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 sera invalide 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.

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn