Créez un site réactif en une semaine: requêtes médias (partie 4)

Contenu

• 01. Ajout de requêtes multimédias
• 02. Anatomie d'une requête médiatique
• 03. Encore une chose…
• 04. Choix des points d'arrêt
• 05. Ajuster nos miniatures
• 06. Pas seulement la largeur

• Connaissances nécessaires: CSS et HTML intermédiaires
• A besoin: Éditeur de texte, navigateur moderne, logiciel graphique
• Temps du projet: 1 heure (5 heures au total)
• Dossier de support

Partie relativement nouvelle de la spécification CSS, les requêtes multimédias sont sans aucun doute l'aspect le plus excitant de la conception Web réactive et un domaine propice à d'autres expérimentations.

Ayant accepté le besoin de mises en page adaptatives, certains ont vu les requêtes multimédias comme un moyen de moderniser les mises en page adaptatives sur des sites à largeur fixe existants. Parmi ceux qui ont adopté les mises en page réactives, beaucoup l'ont fait du point de vue du bureau, cachant le contenu et les fonctionnalités à mesure que la fenêtre se rétrécit.

Tout au long de ce didacticiel, nous avons adopté une approche alternative, d'abord mobile. Maintenant que nous cherchons à inclure les requêtes multimédias, nous pouvons penser à ajouter caractéristiques à mesure que la surface de l'écran augmente, sachant que le balisage et la conception qui sous-tendent notre site fournissent une base de référence respectable.

Aujourd'hui, nous allons aller au-delà de notre portefeuille de modèles et créer les pages individuelles requises pour notre site Web. Ce faisant, nous verrons comment les requêtes multimédias sont construites et les implémenterons de manière vraiment réactive.

01. Ajout de requêtes multimédias

Avec les composants de notre portefeuille de modèles complets et fonctionnant en dehors des limites de toute mise en page, il est temps de les déplacer dans les différentes pages qui composent notre site.

Nous allons commencer par notre page d'accueil. À partir de la conception orientée bureau, nous pouvons voir que dans les fenêtres plus larges, notre disposition doit apparaître comme suit:

En prenant des mesures de notre conception, nous pouvons décrire la zone de document en CSS comme suit:

.document {
rembourrage: 0 5%;
}
.principale {
largeur: 74,242424242424%; / * 784/1056 * /
float: gauche;
}
.complementary {
largeur: 22,727272727273%; / * 240/1056 * /
Flotter à droite;
}

Comme nous l'avons appris dans la deuxième partie de ce didacticiel, nous utilisons la formule suivante pour calculer le pourcentage de largeur de ces colonnes:

(cible / contexte) * 100 = résultat

Lorsque nous redimensionnons notre navigateur, nous verrons que la disposition de notre bureau passe du plus petit écran au plus grand. Bien sûr, pour les petites tailles, les colonnes sont trop étroites et les lignes si courtes que le contenu est difficile à lire. Nous ne voulons cette mise en page que lorsqu'il y a suffisamment d'espace disponible pour qu'elle fonctionne.

C'est là que les requêtes multimédias entrent en jeu. En supposant que cette mise en page ne devrait prendre effet que lorsque le navigateur est plus large que 768 pixels, nous pouvons ajouter le CSS suivant:

.document {
rembourrage: 0 5%;
}
@ écran multimédia et (largeur min: 768px) {
.principale {
largeur: 74,242424242424%; / * 784/1056 * /
float: gauche;
}
.complementary {
largeur: 22,727272727273%; / * 240/1056 * /
Flotter à droite;
}
}

Désormais, lorsque la fenêtre est plus étroite que 768 pixels, tout ce qui se trouve à l'intérieur de la requête multimédia sera ignoré. Il sera ignoré par tout navigateur qui ne prend pas en charge les requêtes multimédias.

02. Anatomie d'une requête médiatique

Pour comprendre ce qui se passe ici, voyons comment une requête multimédia est construite. Nous pouvons le diviser en deux parties:

• @ écran multimédia: La première partie d'une requête média est la type de support. Vous pouvez reconnaître cette syntaxe si vous avez déjà inclus des styles d'impression dans votre CSS. Vous pouvez également reconnaître le nom du type dans le médias attribut sur le lien> élément. En effet, les deux acceptent l'ensemble approuvé de types de supports trouvés dans la spécification CSS 2.1.
• (largeur min: 768px): La deuxième partie est le mettre en doute. Cela inclut le fonctionnalité à interroger (dans ce cas, la largeur minimale de la fenêtre) et les valeur pour tester (768px).

Lorsque nous parlons de conception Web réactive, il y a une tendance à se concentrer sur la largeur, mais il existe d'autres fonctionnalités que nous pouvons également tester:

• (min- | max-) largeur et (min- | max-) hauteur: Ceux-ci nous permettent d'interroger la largeur et la hauteur de la fenêtre (c'est-à-dire la fenêtre du navigateur).
• (min- | max-) largeur de l'appareil et (min- | max-) hauteur de l'appareil: Ceux-ci nous permettent d'interroger la largeur de l'ensemble de l'affichage. D'après mon expérience, il est généralement plus judicieux de baser les mises en page sur la fenêtre plutôt que sur l'affichage.
• orientation: Vous pouvez immédiatement penser aux possibilités ici; pensez aux applications qui affichent un contenu différent en fonction de l'orientation de votre téléphone - la même chose est possible sur le Web.
• (min- | max-) rapport hauteur / largeur: Cela nous permet d'adapter les mises en page en fonction du ratio de la fenêtre du navigateur ...
• (min- | max-) ratio d'aspect de l'appareil: … Et cela nous permet de faire de même en fonction du rapport hauteur / largeur de l'appareil. Owen Gregory a écrit un merveilleux article l'année dernière qui expliquait comment nous pouvons utiliser cette requête pour lier nos créations aux appareils sur lesquels elles apparaissent.
• (min- | max-) monochrome: Nous pouvons également tester si un appareil dispose d'un écran monochrome ou non. Imaginez à quel point cela serait utile si les appareils Kindle e-ink d'Amazon ne mentaient pas et signalaient leurs écrans comme des couleurs!

La dernière partie de notre requête est probablement la plus utile. En utilisant et, nous pouvons tester plusieurs fonctionnalités dans une seule requête. Par example:

@ écran multimédia et (largeur min: 768px) et (orientation: paysage) {
...
}

Comme vous pouvez le voir, les requêtes médiatiques peuvent nous aider à créer des expériences assez convaincantes - et je n'ai touché que la surface. Si vous recherchez une lecture légère au coucher, vous pourriez faire pire que de lire la spécification de requête multimédia du W3C qui décrit toutes les fonctionnalités que nous pouvons tester.

03. Encore une chose…

Même si nous avons inclus des requêtes multimédias dans notre CSS, si nous visualisons notre site sur un appareil mobile, vous remarquerez que notre site est toujours affiché comme si l'affichage était plus large que 768px.

Pour comprendre pourquoi cela se produit, nous devons suivre une brève leçon d'histoire.

Lorsque l’iPhone original a été annoncé en 2007, l’un de ses principaux arguments de vente était la possibilité de naviguer sur le «vrai Web», même si cela signifiait des sites à largeur fixe orientés bureau qui devaient être écrasés pour s'adapter à son petit écran. L'iPhone a pu le faire en signalant que son écran mesurait 980 pixels de large, avant de réduire les pages Web pour les adapter à son écran de 320 pixels de large.

Mais l'iPhone a été introduit avant l'avènement du responsive design. Maintenant que les auteurs conçoivent des sites conçus pour les mobiles, cette fonctionnalité est moins utile. Heureusement, Apple a inclus un moyen de contourner ce comportement, et depuis qu'il a été adopté par d'autres fabricants, il est devenu presque un de facto la norme. Il s'agit simplement d'ajouter un seul méta élément de notre balisage:

meta name = "viewport" content = "initial-scale = 1.0, width = device-width" />

Cela indique aux navigateurs prenant en charge les fenêtres qu'un site Web ne doit pas être réduit et que la largeur de la fenêtre du navigateur doit être traitée de la même manière que la largeur globale de l'appareil. Une fois que nous avons ajouté cette ligne, notre site Web apparaîtra avec la mise en page prévue:

04. Choix des points d'arrêt

Revenons à notre requête média:

@ écran multimédia et (largeur min: 768px) {
...
}

Les valeurs auxquelles une mise en page s'adapte sont communément appelées points d'arrêt. Si vous vous en souvenez, dans la deuxième partie, j'ai dit que l'utilisation de pixels est une indication de manque de réponse, mais ici, j'ai choisi 768px, probablement parce que c'est la largeur d'un appareil familier.

Au lieu de choisir des points d'arrêt en fonction des caractéristiques des appareils courants, il peut être plus efficace d'examiner les valeurs dérivées de notre contenu, par exemple, des longueurs de ligne confortables pour la lecture ou la taille maximale d'une image.

Notre type étant dimensionné à l'aide d'ems, il semble judicieux que nos requêtes multimédias utilisent également des ems. En fait, cela présente un avantage supplémentaire. Lorsqu'un utilisateur redimensionne le texte dans le navigateur, les pages s'adapteront pour utiliser des points d'arrêt plus petits. Non seulement notre site Web s'adaptera en fonction de la taille de la fenêtre d'affichage, mais aussi de la taille de la police. En fait, ce n'est que lorsque j'ai vu Jeremy Keith faire la démonstration de requêtes médiatiques basées sur em que j'ai réalisé à quel point elles pouvaient être puissantes.

Bien que notre conception puisse fournir une indication des points d'arrêt possibles, la meilleure façon de les choisir est souvent l'expérimentation. En ajustant la largeur de la fenêtre du navigateur, j'ai décidé que 800 px est une bonne largeur pour passer à une mise en page plus complexe.

Comment pouvons-nous exprimer 800px dans EMS? Encore une fois, nous pouvons utiliser notre formule, mais quel est le contexte? Lors du calcul des ems pour les requêtes multimédias, le contexte est toujours la taille de police par défaut du navigateur peu importe si cette valeur a été remplacée dans votre CSS. Cette valeur par défaut est généralement de 16 pixels, ce qui nous donne:

800 / 16 = 50

Nous pouvons maintenant mettre à jour notre requête média comme ceci:

@ écran multimédia et (largeur min: 50em) {/ * 800px * /
...
}

05. Ajuster nos miniatures

Vous vous souviendrez que dans la partie 2, nous avons conçu nos vignettes pour qu'elles soient réactives. Pourtant, une fois que les images dans ces vignettes atteignent leur pleine largeur, une zone d'espace blanc apparaît à droite de chaque image. Encore une fois, les requêtes multimédias nous permettent de résoudre ce problème.

Voici notre CSS original:

ol.media li.media-item {
couleur d'arrière-plan: #fff;
marge: 0 4.16666666667% 4.16666666667% 0;
largeur: 47,91666666667%;
float: gauche;
}
ol.media li.media-item: nth-child (2n) {
marge droite: 0;
}

Le point auquel cet espace blanc apparaît est juste au moment où le navigateur devient plus large que le 560px.Nous choisirons cette valeur à laquelle basculer pour afficher trois vignettes par ligne. Nous pouvons le faire en ajoutant le CSS suivant:

@media screen et (min-width: 35em) {
.media-item {
largeur: 30,612244897959%; / * 240/784 * /
marge: 0 4,081632653061% 1,1429em 0; / * 0 32/784 16px 0 * /
}
.media-item: nth-child (3n) {
marge droite: 0;
}
}

Notez que nous n'avons pas besoin de réécrire tous les styles requis pour la vignette à l'intérieur de cette requête multimédia, seulement les parties que nous souhaitons adapter.

En visualisant ce changement dans le navigateur, vous remarquerez qu'il n'y a pas de marge à droite de chaque seconde vignette. En effet, la règle CSS suivante reste toujours active:

ol.media li.media-item: nth-child (2n) {
marge droite: 0;
}

Nous devons modifier le CSS dans notre requête multimédia pour réinitialiser cette valeur:

@media screen et (min-width: 35em) {
.media-item {
largeur: 30,612244897959%; / * 240/784 * /
marge: 0 4,081632653061% 1,1429em 0; / * 0 32/784 16px 0 * /
}
.media-item: nth-child (2n) {
marge droite: 4,081632653061%;
}
.media-item: nth-child (3n) {
marge droite: 0;
}
}

Lors de la création de requêtes multimédias, soyez toujours conscient des problèmes d'héritage comme celui-ci.

06. Pas seulement la largeur

Il est important de penser aux requêtes multimédias non seulement en termes de largeur, mais également à d'autres variables. Par exemple, la vidéo sur notre page d'éléments multimédias est partiellement masquée lorsque la hauteur de la fenêtre diminue. Nous avons la technologie:

.media-object-wrapper {
rembourrage bas: 56,25%;
largeur: 100%;
hauteur: 0;
position: relative;
}
@ écran multimédia et (hauteur max: 35em) et (orientation: paysage) {/ * 560px * /
.media-object-wrapper {
largeur: 60%;
rembourrage bas: 33,75%;
}
}

J'ai même inclus une requête d'orientation pour affiner davantage ce comportement.

Nous pouvons suivre une approche similaire pour les autres parties de notre conception, en échangeant une version plus grande de l'en-tête et en déplaçant les liens de navigation vers le haut de la page une fois que l'espace devient disponible.

• Consultez notre page d'accueil responsive
• Consultez notre page d'éléments multimédias réactifs

Et là, nous l'avons! Nous avons construit un site Web réactif - et avec une journée à perdre! Enfin, pas tout à fait. Les mises en page flexibles, les images et les requêtes multimédias ne sont que le début du processus de conception réactive.

Demain: Dans la dernière partie de ce didacticiel, nous irons au-delà de la conception Web réactive et verrons comment nous pouvons créer des sites Web vraiment réactifs.

Paul est un concepteur d'interactions basé à Brighton, en Angleterre. Il est plus heureux de créer des interfaces simples mais attrayantes natives du Web.