Dans cet article, nous allons discuter des composantes essentielles de la conception adaptée, avec des liens vers des informations supplémentaires si nécessaire.

Pour les développeurs web, il est maintenant assez commun d'être appelé pour créer un site web ou une application qui change son interface utilisateur en fonction du navigateur ou du dispositif accédant au site, pour fournir une expérience optimisée. Une première approche pour cela consiste à créer différentes versions de votre site/application pour différentes plates-formes ou navigateurs et les générer de façon appropriée après la détection de la plate-forme ou du navigateur qui se connecte à votre site. Cependant cette méthode est de plus en plus inefficace : la détection de navigateur amène facilement à des erreurs, et la maintenance de plusieurs versions de votre code peut s'avérer un cauchemar.

Il est généralement bien préférable de créer une version unique de votre code qui ne se soucie pas du navigateur ou de la plateforme qui accède au site, mais utilise plutôt des fonctions de test pour savoir quel code est pris en charge par le navigateur ou quelles valeurs de certaines fonctions du navigateur le sont, puis ajuste le code en conséquence. On appelle ça le responsive design ou la conception adaptative, deux approches différentes mais connexes. Pour une discussion sur les différences entre les deux , lire Responsive design versus adaptive design.

C'est un moyen plus sûr, plus facilement maintenable, et plus stable sur le long terme. Vous n'avez pas besoin de construire de nouvelles versions du site pour chaque nouveau navigateur ou nouvelle plateforme, ni d'ajuster le code comme support des fonctionnalités des modifications des navigateurs existants.

Il y a aussi des désavantages à cette approche. Si le contenu, le format et les fonctionalités ont besoin de changer énormément à chaque appareil, ce n'est sûrement pas la meilleure approche. De plus, prendre un site existant et le modifier pour le rendre responsive, pour le rendre agréable sur mobile ou tablette, peut demander plus d'efforts que de simplement créer une version mobile ou une application séparée, surtout si c'est un vaste site d'entreprise. Plus d'info sur les avantages et désavantages du responsive design.

Vous pouvez aussi lire notre discussion sur les bases de responsive design  si vous avez besoin de plus d'informations générales et de bases.

Grilles fluides

La meilleure façon de commencer est d'obtenir des mesures fluides pour le rendu de notre application, qui consiste principalement à utiliser une combinaison de pourcentage et de ems/rems pour ajuster la taille de votre conteneur et du texte, et non pas avec des largeur fixées, par exemple, en pixels. Cela présente de nombreux avantages dont le fait que la forme va s'adapter aux différentes dimensions de viewport. Prenons un exemple.

Nous avons créé un prototype simple, mais fun, d'une application appelée Snapshot, qui prend un flux vidéo de votre webcam (en utilisant getUserMedia()) et vous permet ensuite de capturer des images de ce flux vidéo (en utilisant la fonction HTML5 <canvas>), et de le sauvegarder dans la Galerie. Vous pouvez ensuite regarder les images précédemment capturées et les supprimer. D'autres articles viennent détailler les fonctionalités de cette application, mais nous nous intéresserons ici à la forme de celle-ci.

Note : vous pouvez trouver l'application Snapshot sur Github, regarder le code et aider à l'améliorer. Vous pouvez aussi regarder Snapshot tourner en live. Notez que getUserMedia() est une technologie expérimentale, qui ne fonctionne que sur Google Chrome et Firefox pour ordinateur de bureau. Le support sur Firefox OS est prévu sur la version 1.3. Davantage de fonctionalités et une refonte du style de Snapshot sont prévus dans le futur

Notre application pour bureau de Snapshot est composée de trois colonnes contenant respectivement: une vue de la caméra, une vue de la capture d'image, et une galerie.

Le balisage est très simple:

<x-deck selected-index="0">
  <x-card>
    …
  </x-card>
  <x-card>
    …
  </x-card>
  <x-card>
    …
  </x-card>
</x-deck>

Note : ces étranges éléments x- peuvent ne pas vous être familier. Ils font partie de Brick, une collection de composants d'interface de Mozilla pour les application mobiles web. Nous avons utilisé Brick pour créer l'interface mobile pour Snapshot, dont nous parlons un peu plus ci-dessous.

Pour les avoir côte à côte nous utilisons les règles suivantes:

x-card {
  width: 100%;
}

x-card:nth-child(1), x-card:nth-child(2) {
  width: 30%;
  float: left;
  padding: 2rem;
}

x-card:nth-child(3) {
  width: 40%;
  float: left;
  height: 100%;
  overflow: auto;
  padding: 2rem;
}

Nous donnons aux deux premières colonnes une propriété width de 30%, et la troisième une propriété width de 40%, et des indications "float (flottant) : left (gauche)" dans toutes les colonnes. Ainsi elles restent côte à côte, et leurs proportions restent inchangées quelles que soient les variations de largeur de la fenêtre. Ce n'est qu'un exemple de grille fluide, mais vous pouvez très bien appliquer ce principe à des modèles de grilles plus complexes.

Dimensionnement avec border-box

Le padding n'affecte pas la hauteur et la largeur générale des conteneurs car nous avons mis les propriétés box-sizing a border-box:

*, *:before, *:after {
  -webkit-box-sizing: border-box;
  -moz-box-sizing: border-box;
  box-sizing: border-box;
}

Cela signifie que width et {cssxref("height")}} incluront la bordure dans leur définition de la taille et non pas juste le contenu. Donc si vous mettez width: 40%; la boite sera toujours à 40% de la taille de son parent, et padding ainsi que border seront soustraits à la taille du contenu, non ajoutés. Vraiment utile ! Plus d'informations sur * { Box-sizing: Border-box } FTW, par Paul Irish.

Repositionnement d'éléments flexibles

Les choses fonctionnent plutôt bien jusqu'à maintenant, mais il subsiste encore quelque problèmes qui attendent d'être résolus. Pour commencer, regardons ce qui se passe si nous incluons <video> et <img> dans nos deux colonnes, sans aucun style.

Parce que la taille des éléments est dictée par la taille du media interne, et que le média possède une taille fixe, ils explosent leur conteneur et détruisent la mise en page. C'est plutôt horrible, mais généralement ce genre de problème peut facilement être résolu à l'aide d'une simple règle CSS:

img, video {
  max-width: 100%;
}

Cette règle oblige l'élément à rester dans les dimensions de son conteneur, quel qu'il soit. Cependant si cet élément n'est pas aussi grand que son conteneur, il ne va pas s'étirer pour le remplir. Pour l'exemple de SnapShot, nous utilisons un code légèrement différent:

x-card:nth-child(1) video, x-card:nth-child(2) img {
  width: 100%;
    …
}

Car dans notre cas, nous voulons en fait que la vidéo et l'image remplissent toujours leur conteneur, quel qu'il soit - une différence subtile mais importante par rapport à max-width - et gardent ainsi toujours la même taille. La vidéo se redimensionne toujours dynamiquement, mais pas l'image capturée de l'écran. De ce fait, lors du redimensionnement de l'écran, on peut se retrouver avec des éléments de tailles différentes en utilisant max-width: 100%; comme :

Media queries

Les grilles fluides sont un bon début, mais vous noterez qu'à certains points (connus sous le nom de breakpoints) l'agencement commence à se casser. À ce moment-là, vous aurez envie de modifier la disposition pour éviter ce problème, et ceci peut être fait en utilisant media queries.

Note : Media queries est une fonctionalité CSS3 qui vous permet de sélectionner les règles CSS à appliquer selon les résultats des tests sur le média. Pour plus d'informations, lire Media queries.

Positionnement bureau classique

Dans notre exemple, nous avons un positionnement de bureau, comme nous l'avons déjà vu. Il est créé en utilisant des règles CSS incluses en haut de notre feuille de style, avant tout media queries.

Positionnement mid-width

Nous avons aussi un positionnement mid-width, pour les tablettes et les ordinateurs aux écrans étroits. Ceci est réalisé à l'intérieur de notre première media query :

@media all and (max-width: 1024px) {
  x-card:nth-child(1), x-card:nth-child(2) {
    width: 50%;
  }

  x-card:nth-child(3) {
    width: 100%;
    clear: left;
  }
 
  x-card:nth-child(3) img {
    width: 20%;
  }
}

Ici nous altérons la largeur de nos colonnes et nous supprimons le flottement de la troisième colonne (ainsi qu'un clear pour éviter tout soucis de flottement). Nous avons aussi modifié la largeur des images dans le troisième conteneur (qui n'est plus une colonne, mais une galerie) pour en avoir cinq par ligne (contre trois précédemment).

Positionnement pour mobile/écran étroit

Nous avons ensuite un positionnement pour les écrans étroits, convenant à une application mobile ou une application Web ouverte (par exemple, une application Firefox OS). Ceci est fait en plusieurs parties. Premièrement, comme prévu, il y a une media query dans notre CSS principal, qui est assez lourd, nous allons donc l'expliquer en plusieurs parties.

@media all and (max-width: 480px) {  
  x-card:nth-child(1), x-card:nth-child(2), x-card:nth-child(3) {
    width: 100%;
    float: none;
    padding: 0;
  }
 
  button {
    margin-top: 0;
    border-radius: 0;
  }
 
  x-card:nth-child(1) video, x-card:nth-child(2) img {
    border-radius: 0px;
    border: none;
    padding: 0;
    background-color: 0;
  }

Ce premier bloc reconfigure un certain nombre d'éléments par rapport au positionnement pour écran classique qui ne sont plus requis pour l'application mobile.

  x-card:nth-child(1) video, x-card:nth-child(2) img, x-card:nth-child(3) {
    margin-top: 17.5vw;
  }
 
  x-card:nth-child(1) button, x-card:nth-child(2) button {
    position: absolute;
    bottom: 0;
  }
 
  x-card:nth-child(2) button:nth-of-type(2) {
    bottom: 5.9rem;
  }
  
  x-card:nth-child(1) button {
    font-size: 7vw;
  }
 
  x-card:nth-child(2) button {
    font-size: 7vw;
  }

Les règles suivantes redimensionnent les boutons dans les deux premiers éléments, et donnent à tous les contenus de ces éléments une marge haute pour ne pas perdre le contenu sous les boutons de navigation (voir ci-dessous). Ceci est nécessaire car Mozilla Brick (voir ci-dessous aussi) force les composants à être à 100% de la hauteur/largeur de l'écran. Nous utilisons les unités vw (viewport width) pour cela. 1 vw est équivalent à 1% de la largeur du viewport. Ceci permet le redimensionnement adapté à la largeur du viewport. Finalement, nous avons placé de façon absolue les boutons en bas de leur cadre, donc le positionnement semble correct pour différentes variations de viewport. Nous ajoutons ensuite une règle qui positionne le second bouton plus haut dans le cadre. Lorsque vous cliquez sur une image dans la galerie, les options pour supprimer ou quitter l'image apparaissent, et vous ne voulez pas que les boutons se placent l'un au-dessus de l'autre.

x-card:nth-child(3) img {
  width: 50%;
}

Cette règle change simplement la largeur de la galerie d'images pour en avoir deux par ligne.

  nav {      
    width: 100%;
    position: absolute;
    z-index: 1000;
     
    display: -webkit-flex;
    display: -moz-flex;
    display: -ms-flexbox;
    display: flex;
  }
 
  nav button {
    font-size: 6.8vw;
    
    -webkit-flex: 1;
    -moz-flex: 1;
    -ms-flex: 1;
    flex: 1;
    
    border-left: 1px solid rgba(100,100,100,0.4);
  }
 
  nav button:first-child {
    border-left: 0;
  }
}

Dans ce dernier lot de règles, nous changeons la valeur display de <nav> à "flex", pour le montrer (il était réglé à none dans le CSS, par défaut en haut de notre feuille de style, puisqu'il n'était pas utilisé dans les autres vues). Nous utilisons ensuite le positionnement absolu et z-index pour ne mettre aucun écart dans le document, et le placer en haut des x-cards ( c'est pourquoi nous avons donné une propriété top-margin aux x-cards plus tôt).

Ensuite, le font-size des boutons est reglé à 6.8vw. Pourquoi ? Parce que le top-margin de x-cards à été mis à 17vw plus tôt. Tous les boutons de l'applications ont été réglés pour avoir une line-height de 2.5 en haut de la feuille de style CSS par défaut (vous pouvez vérifier si vous ne me croyez pas). Et 6.8 * 2.5 = 17.

Ensuite, nous utilisons flex: 1; pour faire en sorte que les boutons utilisent tous le même espace sur la ligne. Regardons d'un peu plus près le positionnement, dans l'image ci-dessous.

single column layout for mobile app view, with three buttons to navigate between cards, an image viewer, and a Save Picture button at the button.Mais nous avons d'autres tours dans notre sac pour la forme de cette application mobile ! Comme mentionné ci-dessus,  nous utilisons Mozilla Brick, une collection de composants d'interface mobile prêts à l'emploi, pour composer l'application mobile. Nous utilisons en particulier le composant deck pour le bel effet de transition entre les cadres quand un bouton est pressé. Pour plus d'informations sur Brick, lire Mozilla Brick: ready made UI components.

Ce qui est plus pertinent pour cet article est que nous ne voulons pas que Brick CSS ainsi que les fichiers JavaScript soient appliqués au balisage tant que ne sommes pas dans la vue mobile. Pour faire cela, nous appliquons Brick CSS à la page en utilisant un <link> séparé avec un attribut media:

<link href="dist/brick.css" type="text/css" rel="stylesheet" media="all and (max-width: 480px)">

Cet attribut indique que la feuille de style ne doit pas être ajoutée à  l'HTML tant que la largeur de viewport est de 480px ou moins. Passons au JavaScript, les éléments <script> n'acceptent pas les attributs média, donc nous devons procéder différemment. Heureusement il existe une fonction appelée window.matchMedia(), qui peut faire tourner ou non le Javascript selon qu'une media query retourne true ou non. Nous ouvrons brick.js et englobons le tout dans la condition suivante :

if (window.matchMedia("(max-width: 480px)").matches) {
  // The whole of brick.js goes here!
}

Ceci fait, rien ne se passe dans brick.js tant que la largeur du viewport est supérieur à 480px. Problème résolu.

Écrans très larges

Vous aurez peut-être remarqué que quand le viewport devient très grand (comme sur un affichage cinéma), la disposition arrête de s'agrandir, et ne fait que se recentrer dans l'espace disponible. C'est assez simple à faire. Vous pouvez utiliser une média query avec min-width pour régler la largeur de <body> à un certain point:

@media all and (min-width: 1400px) {
  body {
    width: 1400px;
    margin: 0 auto;
  }
}

Mais il est plus simple de définir cette règle à la place, et de ne pas s'embêter avec un media query:

body {
  max-width: 1400px;
  margin: 0 auto;
}

Problème d'orientation

Nous sommes face à certains problèmes avec l'orientation : l'agencement mobile de notre application est conçue pour une orientation en portrait, et paraît horrible sur un appareil en format paysage. Pour réparer cela, nous ajoutons une media query qui n'applique sa règle sur le contenu que si l'appareil est en format paysage :

@media all and (max-width: 480px) and (orientation: landscape) {
  nav {   
    width: auto;
    
    -webkit-flex-direction: column;
    -moz-flex-direction: column;
    -ms-flex-direction: column;
    flex-direction: column;
  }
 
  nav button {
    font-size: 6.8vh;
  }
 
  nav button {
    border-left: 0;
  }
 
  x-card:nth-child(1) video, x-card:nth-child(2) img, x-card:nth-child(3) {
    margin-top: 0;
  }
 
  x-card:nth-child(1) button, x-card:nth-child(2) button {
    font-size: 2rem;
  }
}

Ces spécifications permettent :

  • d'ajuster les boutons nav, de changer la direction du flexbox dans laquelle ils sont disposés, et de modifier la taille de police et les bords pour les faire rentrer verticalement plutôt qu'horizontalement.
  • de supprimer les marges en haut du contenu de x-card pour ne pas finir avec un écart en haut de l'écran en mode paysage.
  • de changer la taille des boutons de contrôle (comme Take Picture, Delete Photo) pour qu'ils n'aient pas l'air trop gros et se placent correctement sur l'écran.

Et l'image suivante donne le rendu de ces modifications :

Note: Une autre solution, pour respecter l'orientation, pourrait être de bloquer l'orientation de votre application : soit portrait, soit paysage. Si vous travaillez sur une application installée ou sur Firefox OS, vous pouvez le faire facilement avec le champ d'orientation du manifeste. Si vous désirez une solution fonctionnelle sur les applications web en général, vous pouvez utiliser l'API Screen Orientation, et/ou envoyer un message pour demander à l'utilisateur de tourner son écran s'il utilise la mauvaise orientation (par exemple, si window.innerWidth est plus grand que window.innerHeight, on peut supposer que le jeu est en mode paysage, et on affiche donc un message "Veuillez tourner l'écran".)

Viewport

Un dernier problème à résoudre pour notre application exemple concerne les navigateurs mobile et les media queries. Si nous avions vu mon exemple dans un navigateur mobile, dans l'état présent, nous n'aurions pas vu notre beau positionnement mobile, mais plutôt l'image ci-dessous .

Vous serez d'accord avec moi pour dire que ce n'est pas tout à fait ce que nous voulions n'est-ce pas? Pourquoi est-ce arrivé ? En bref, les navigateurs mobile méntent. Ils ne donnent pas un rendu de page web avec leur véritable largeur de viewport. Au lieu de cela, ils le font avec une largeur plus haute (quelque chose approchant l'écran d'ordinateur portable), et le rétrécissent pour rentrer dans l'écran mobile. C'est un méchanisme de défense sensible, la plupart des vieux sites qui n'ont pas de media queries aurait l'air horrible avec un rendu direct, 320px par 480px. Mais cela ne nous aide pas, nous les développeurs web, qui avons écrit des dispositions pour petit écran dans notre CSS en utilisant des media queries et qui voulons que l'application affiche ceux-là !

Il existe un moyen d'outrepasser ce comportement mobile : le viewport, qui est inséré dans nos pages HTML sous la forme d'une balise <meta>. Dans mon exemple, ajoutons ce qui suit dans notre <head> HTML:

<meta name="viewport" content="width=480">

Cela oblige le navigateur à positionner notre application mobile correctement. width=480 dit au navigateur "donne une apparence de 480 pixels de largeur", à partir de quoi les media queries le font correctement. Il existe de nombreuses options disponibles pour la balise meta viewport, sur laquelle vous pouvez vous documenter en vous rendant sur Utiliser la balise meta viewport pour contrôler la mise en page sur les navigateurs mobiles.

Note: Il existe une spécification pour le device adaptation, qui définit les mêmes fonctionalités mais en CSS, en utilisant la règle @viewport . C'est probablement un lieu plus logique pour indiquer ce genre d'informations, mais cette spécifications n'est pas aussi bien supportée que la balise meta viewport, donc vous devriez préférer celle-ci pour le moment.

Images/vidéos adaptatifs

Un problème de plus en plus récurrent ces derniers temps est le poids des images/vidéos "responsive" (poids en Ko) et les dimensions de l'image sur l'écran. Vous voulez que les images soient contenues dans l'Interface utilisateur de l'application, que ce soit sur ordinateur ou sur mobile, mais vous devriez aussi considérer le fait que les application mobiles possèdent des dimensions plus petites que sur ordinateur, donc vous devriez rendre les images plus légères à télécharger. Les mobiles en général (plus communément dans certaines parties du monde que d'autres) possèdent une bande passante plus faible et ont moins de mémoire disponible que les ordinateurs de bureau. Donc oui, ces kilo-octets supplémentaires comptent.

Une autre difficulté vient avec les écrans à très grande résolution, les graphismes conçus pour les petites résolutions risquent d'apparaître tous petits quand ils sont affichés sur un écran à haute résolution. Les appareils appliquent donc souvent un facteur de zoom par défaut, pour le rendu des pages. Le problème de cet automatisme, c'est que les images zoomées ainsi peuvent apparaître pixelisées.

Images de fond CSS

Pour les images de fond CSS, c'est un problème simple à résoudre. Si vous utilisez la méthodologie mobile first, vous créerez votre agencement mobile dans votre CSS par défaut, avant que les media queries ne soient appliquées. Les media queries appliquent ensuite le CSS sur les balises, lorsque le viewport est au-dessus d'une certaine largeur. Voici un exemple :

header {
  height: 300px;
  width: 100%;
  background: url(images/small-header.jpg) center;
}

@media all and (min-width: 480px) {
  header {
    background: url(images/large-header.jpg) center;
  }
}

Cela signifie que les navigateurs mobiles ne téléchargeront que l'image pour mobile - et non l'image pour ordinateur de bureau - car ils échoueront au test de media queries et ignoreront donc celle-ci. Vous pouvez aussi proposer un meilleur graphisme pour les appareils à plus haute résolution, en utilisant une media query de résolution comme :

button {
  background: url(images/low-res-header.jpg) 1rem center ;
}

@media only screen and (-webkit-min-device-pixel-ratio: 2),
       only screen and ( min-resolution: 192dpi),
       only screen and ( min-resolution: 2dppx) { 
  button {
    background: url(images/high-res-header.jpg) 1rem center ;
  } 
}

Ça peut sembler compliqué, mais ça ne l'est pas en réalité, nous fournissons plusieurs options de media queries, à ce jour, plusieurs navigateurs supportent différents types de résolution de media queries et aussi d'unités. Brett Jankord a fait un bonne explication sur Cross Browser Retina/High Resolution Media Queries.

<video>

HTML5 Vidéo est assez bien pris en charge en termes de capacités d'adaptation. Si vous le souhaitez, vous pouvez indiquer plusieurs fichiers vidéo via les attributs <source> , chacun avec sa propre source et le type MIME:

<video controls>
  <source src="videos/720/crystal720.mp4" type="video/mp4">
  <source src="videos/720/crystal720.webm" type="video/webm">
</video>

Mais vous pouvez aller encore plus loin. Vous pouvez inclure des attributs sur l'élément <source> contenant les media queries - la vidéo chargée dans le navigateur dépendra à la fois du format que le navigateur prend en charge, et des résultats des tests de médias. Ainsi, par exemple:

<video controls>
  <source src="videos/320/crystal320.mp4" type="video/mp4" media="all and (max-width: 480px)">
  <source src="videos/320/crystal320.webm" type="video/webm" media="all and (max-width: 480px)">
  <source src="videos/720/crystal720.mp4" type="video/mp4" media="all and (min-width: 481px)">
  <source src="videos/720/crystal720.webm" type="video/webm" media="all and (min-width: 481px)">
</video>

Cela permet à votre site de servir différents fichiers vidéo, en fonction de l'espace disponible afin d'optimiser l'expérience de l'utilisateur.

<img>

Les images HTML représentent une proposition de résolution plus difficile. Il n'y a aucun mécanisme inhérent aux images HTML pour servir différents fichiers d'image selon la taille de la fenêtre, et, en raison d'un certain nombre de pénibles réalités concernant le comportement des navigateurs, les solutions d'ensemble sont plus difficiles à trouver que vous ne pouvez l'imaginer. Il existe actuellement des propositions de normes dans les travaux qui fourniraient cela — dans le cadre de W3C, le groupe de la communauté responsive images débat de ce problème depuis de nombreuses et années et a abouti à l'élément <picture> , qui fournit une structure de balisage similaire à <video> , avec <source> et des alternatives sélectionnables via les résultats d'une media query. Une autre proposition, srcset, a été présentée par Apple et adopte une approche légèrement différente : fournir un nouvel attributsrcset pour <img> à l'intérieur duquel les références d'image sont placées avec "hints", que le navigateur peut utiliser pour déterminer quelle image est la plus appropriée à afficher compte-tenu de la taille de la fenêtre, de la résolution, etc. Ces propositions ne sont pas destinées à être mutuellement exclusives.

Tout cela semble bien. Mais ces solutions ne sont certainement pas encore prêtes pour la production - les deux sont dans un stade très précoce de la normalisation et n'ont aucun support dans les navigateurs. Actuellement, nous devons compter sur divers polyfills et autres solutions ; aucun de ces outils n'étant parfait et capable de répondre à toutes les situations, de sorte que vous devez décider lequel est approprié pour votre situation particulière. Certaines solutions disponibles sont les suivantes :

HiSRC
Un branchement  jQuery  qui vous permet de créer des petites, moyennes et grandes versions d'une image, puis sert l'image appropriée en fonction de la résolution du navigateur et de la vitesse de réseau disponible.
Mobify.js capturing
Une technique très intelligente de Mozilla, qui vous permet de capturer la source de la page avant qu'elle ne soit analysée. De cette façon, vous pouvez échanger des valeurs src d'image avec JavaScript selon les fonctionnalités du navigateur, contournant les problèmes de préchargement du navigateur. Ceci est prometteur, mais ne fonctionne pas très bien sur les anciens navigateurs.
Picturefill
Un polyfill basé sur JavaScript pour <picture>, qui fonctionne bien mais nécessite beaucoup de marquage personnalisé.
Adaptive images
Une solution côté serveur, qui enregistre la taille de la fenêtre dans un cookie, puis redimensionne les images via une combinaison de PHP et .htaccess à une taille plus appropriée, le cas échéant. Cela ne nécessite pas de balisage ou de script, mais présente un certain nombre de limites.

SVG et autres graphiques vectoriels

Pour certaines exigences d'image , une bonne solution consiste à utiliser des graphiques vectoriels (pas pour les photographies, mais pour les icônes et les éléments de l'interface utilisateur qui sont bien adaptés). Étant donné que les images vectorielles sont calculées en fonction d'algorithmes mathématiques, plutôt que de contenir des données distinctes sur chaque pixel de l'image, elles ont tendance à être plus petites (taille du fichier) et sont infiniment évolutives lorsqu'elles sont agrandies ou affichées sur des appareils haute résolution (au moins en théorie). Certaines des idées suivantes, qui contribuent également à réduire le nombre de requêtes HTTP - un autre facteur clé de la performance de l'application mobile :

  • Vous pouvez essayer d'utiliser les fonctionnalités CSS3  pour générer par programme des effets graphiques, si possible, plutôt que de s'appuyer sur des fichiers image. cela inclut les coins arrondis, les gradients et les ombres tombantes. Ceux-ci s'élargissent au fur et à mesure que la résolution change ou le navigateur zoome et, bien qu'ils ne soient pas très bien pris en charge sur les navigateurs plus anciens tels que Internet Explorer 6-8, cela ne préoccupe pas grandement lorsque les effects sont créés pour une interface destinée à des appareils modernes tels que l'OS Firefox, et ils ont aussi tendance à se dégrader gracieusement.
  • Vous pouvez aussi essayer d'utiliser SVG pour créer des éléments d'interface. SVG produit des graphiques vectoriels et est bien pris en charge dans les navigateurs modernes, avec les polyfills disponibles pour un support de navigateur plus ancien.
  • L'utilisation de Web fonts pour afficher des icônes est une technique efficace pour réduire la taille du fichier et les requêtes HTTP, et cela est bien pris en charge dans les navigateurs modernes et anciens.

See also

Étiquettes et contributeurs liés au document

 Contributeurs à cette page : loella16, diomabb, Ilphrin, Goofy, stephaniehobson, robertino
 Dernière mise à jour par : loella16,