Discussion sur la taille des sites Web dans le site Web de l'écran tactile HTML5

Cet article est divisé en deux parties. La première partie discute de la faisabilité des sites Web multiplateformes, et la deuxième partie explique comment la fenêtre est mise en place.

Il est vrai que la largeur et la hauteur de l'étiquette peuvent être adaptables, nous pouvons le faire très tôt. Mais vous constaterez que de nombreux sites Web PC traditionnels corrigent toujours la largeur. (Taobao utilise une largeur de 1000px, SoHU 950px ...) Pourquoi ne permettons-nous pas au site Web de s'adapter à la largeur et à la hauteur? En effet, si nous laissons la largeur de l'étiquette être étirée arbitrairement par le navigateur, cela conduira à une très mauvaise expérience: vous ne voudrez pas que votre barre gauche se transforme en nouilles lorsque le navigateur est mis à l'échelle à 100px; Vous ne voudrez pas non plus que votre site Web ressemble à un netbook pour un élève du primaire lorsque le navigateur est surchargé. Par conséquent, il n'est pas réaliste de s'appuyer sur l'adaptation des étiquettes pour atteindre des plates-formes multiples et se fait au détriment de l'expérience utilisateur. Plusieurs fois, nous devons réparer la largeur et la hauteur.

Nous comptons sur l'appareil HTML5 pour vérifier si l'appareil actuel est un téléphone mobile ou une tablette, et charger le CSS correspondant en conséquence. Par exemple: si vous détectez que votre appareil est une tablette, je peux afficher trois colonnes horizontalement, et s'il s'agit d'un téléphone mobile, je n'afficherai qu'une seule colonne. Cela ne semble pas difficile, mais c'est très compliqué à mettre en œuvre. Nous avons non seulement besoin de développer plusieurs ensembles de modèles pour différents appareils, mais aussi de traiter la taille de l'image. À cet égard, nous pouvons voir comment le Boston Globe utilise HTML5 pour implémenter une conception réactive.

En général, la réalisation de sites Web multiplateformes est trop cher et restreint pour la plupart des sites Web. Que ce soit possible dépend de la situation réelle du site Web.

Les navigateurs mobiles placent la page dans une fenêtre virtuelle (fenêtre). Habituellement, la fenêtre virtuelle (fenêtre) est plus large que l'écran, de sorte que chaque page Web n'a pas à serrer chaque page Web dans une très petite fenêtre (cela détruira la disposition de la page Web qui n'est pas optimisée pour les navigateurs mobiles). Les utilisateurs peuvent voir différentes parties de la page Web via le panoramique et le zoom. Les navigateurs mobiles ont introduit la méta-étiquette de la fenêtre, permettant aux développeurs Web de contrôler la taille et la mise à l'échelle de la fenêtre.

Pixels CSS: unités abstraites utilisées par les navigateurs, principalement utilisées pour dessiner du contenu sur les pages Web.

Pixels de l'appareil: affiche l'unité physique minimale de l'écran, chaque DP contient sa propre couleur et sa luminosité.

La quantité de pixels CSS avec des valeurs équivalents occupez sur l'écran du téléphone n'est pas fixe, elle dépend de nombreux attributs. Après analyse et résumé, nous pouvons trouver une formule: 1 pixels CSS = (devicePixelratio) ^ 2 Pixels de l'appareil (^ 2 signifie carré. Quant à ce qu'est le dispositifPixelratio, il sera expliqué plus tard).

PPI, parfois également appelé DPI, représente le nombre de pixels par pouce. Plus la valeur est élevée, plus l'affichage peut afficher des images. (Remarque: les pixels ici se réfèrent aux pixels de l'appareil.) Après avoir déterminé ce que signifie PPI, nous pouvons facilement comprendre la méthode de calcul de l'IPP. Nous devons d'abord calculer les pixels équivalents diagonaux de l'écran du téléphone mobile, puis placer la diagonale (la taille de l'écran du téléphone mobile est la longueur de la ligne diagonale de l'écran du téléphone mobile), et nous pouvons obtenir l'IPP. Pour les annonces de calcul précises, vous pouvez vous référer à la figure ci-dessous. Ce qui est plus intéressant, c'est que l'IPP de l'iPhone 4 calculé sur la base de la formule est de 330, ce qui est un peu plus élevé que les 326 officiellement annoncés par Apple.

De même, la prise de HTC G7 comme exemple, la résolution de 480 * 800 et 3,7 pouces est calculée pour être un IPP de 252.

Nous calculons PPI pour savoir à quel intervalle de densité à laquelle appartient le périphérique de téléphone mobile, car différents intervalles de densité correspondent à différents rapports de mise à l'échelle par défaut, ce qui est un concept très important.

D'après la figure ci-dessus, on peut voir que les téléphones mobiles avec PPI entre 120-160 sont classés comme téléphones mobiles de basse densité, 160-240 est classé comme densité moyenne, 240-320 est classé comme densité élevée et supérieur à 320 est classé comme une densité ultra-élevée (Apple a donné un nom en amont).

Ces densités correspondent à une valeur de mise à l'échelle spécifique. Prenez l'iPhone 4 ou 4 que nous connaissons le plus, leur PPI est 326, ce qui est un téléphone mobile à ultra-haute densité. Lorsque nous écrivons une page avec une largeur de 320px et la mettons sur l'iPhone à afficher, vous constaterez qu'il est en fait en pleine largeur. En effet, la page est agrandie deux fois par défaut, c'est-à-dire 640px, tandis que la largeur de l'iPhone 4 ou 4S est exactement 640px.

L'image porte le tour du type de densité à haute densité car il s'agit des données statistiques des téléphones Android. Sur le marché national du téléphone Android, les appareils à haute densité représentent la grande majorité de la part de marché. C'est un point très important et c'est aussi un point clé auquel nous devons prêter attention lors de la réalisation d'Android WebApps.

La fenêtre a un total de 5 attributs, comme suit:

<méta name = "Vieille"

contenu = "

height = [pixel_value | Appareil-hauteur],

largeur = [pixel_value | Appareil-largeur],

initial-scale = float_value, minimum-scale = float_value, maximum-scale = float_value, maximum-scale = float_value,

utilisateur-échec = [Oui | Non] ,

Target- densityDpi = [dpi_value | Device-dpi | high-dpi | moyen-DPI | bas-dpi] "/>

Parmi ces propriétés, nous nous concentrons sur Target-DensityDPI , qui peut modifier la mise à l'échelle par défaut de l'appareil. Medium-DPI est la valeur par défaut de Target-DensityDPI. Si nous définissons Target-DensityDpi = Device-DPI, l'appareil rendra la page en fonction du réel DPI. Par exemple, si une image 320 * 480 est placée dans l'iPhone 4, elle occupera l'écran par défaut, mais si Target-DensityDPI = DVICE-DPI est défini, l'image ne représente que le quart de l'écran (une demi-place du carré) car la résolution de l'iPhone 4 est 640 * 960.

Si nous fabriquons la page en fonction du projet de conception large 320px et ne faisons aucun paramètre, la page évoluera automatiquement à une largeur égale à l'écran de téléphone mobile par défaut (ceci est dû au fait que le DPI est la valeur par défaut de la densité cible, et elle est déterminée par différents rapports de mise à l'échelle correspondant à différentes densités, les tous rédigés par les appareils mobiles). Cette solution est donc simple, rugueuse et efficace. Mais il y a un désavantage fatal. Pour les appareils mobiles à haute densité et ultra-haute densité, les pages (en particulier les images) seront déformées, et plus elle est dense, plus elle est déformée.

Dans cette solution, nous utilisons Target-DensityDpi = Device-DPI, afin que l'appareil de téléphone mobile soit rendu en fonction du nombre réel de pixels. En termes professionnels, il s'agit de 1 pixels CSS = 1 pixels de l'appareil. Par exemple, pour un iPhone avec 640 * 960, nous pouvons créer une page avec 640 * 960, et il n'y aura pas de barres de défilement lorsqu'elle est affichée sur l'iPhone. Bien sûr, pour d'autres appareils, des pages de différentes tailles sont également nécessaires, donc cette solution est souvent utilisée pour utiliser les requêtes multimédias pour créer des pages réactives. Cette solution peut être parfaitement présentée à une résolution spécifique, mais avec des résolutions plus différentes à compatibles, plus le coût est élevé, car des codes séparés sont nécessaires pour chaque résolution. Voici un exemple simple:

<meta name = "Viewport" contenu = "cible- densitydpi = device-dpi, width = device-width" />

#Header {

CONTEXTE: URL (moyen-densité-image.png);

}

Écran @media et (- webkit -device-pixel-ratio: 1.5) {

/ * CSS pour les écrans à haute densité * /

#Header {Background: URL (haute densité-image.png);}

}

Écran @media et (- webkit -device-pixel-ratio: 0.75) {

/ * CSS pour les écrans de basse densité * /

#Header {Background: URL (Low-Density-Image.png);}

Pour la grande majorité des appareils Android, les caractéristiques de la densité élevée et de la densité moyenne, nous pouvons adopter une solution de compromis: nous restaurons le projet de conception de 480px de large, mais le système de page est fait à 320px de large (en utilisant la taille de l'arrière-plan pour réduire l'image), puis laisser la page évoluer automatiquement à l'échelle. De cette façon, les téléphones à basse densité ont des barres de défilement (fondamentalement, personne n'utilise ce type de téléphone), les téléphones à densité moyenne gaspilleront un peu de trafic, les téléphones à haute densité seront parfaitement présents et les téléphones androïdes ultra-élevés). Les avantages de cette solution sont très évidents: un seul ensemble de brouillons de conception et un ensemble de codes sont nécessaires (voici seulement la situation des téléphones Android).