Contenu
- Images réactives
- Performance
- Chargement conditionnel et paresseux
- Typographie réactive
- Requêtes multimédias en JavaScript
- Amélioration progressive
- Mise en page
- Disposition de la grille CSS
- Pour terminer
La conception Web réactive semble incroyablement simple. Optez pour des grilles flexibles pour la mise en page, utilisez des supports flexibles (images, vidéo, iframes) et appliquez des requêtes multimédias pour mettre à jour ces mesures afin d'organiser au mieux le contenu sur n'importe quelle fenêtre. Dans la pratique, nous avons appris que ce n’est pas vraiment si simple. De minuscules problèmes qui surgissent au cours de chaque projet nous font nous gratter la tête et parfois même creuser des tranchées d'ongles sur nos bureaux.
Depuis que j'ai commencé à organiser la newsletter hebdomadaire Responsive Design, j'ai eu la chance de parler avec de nombreux membres de la communauté Web et d'écouter leurs expériences. Je voulais savoir exactement ce que la communauté voulait vraiment apprendre, alors j'ai fait circuler un sondage auprès des lecteurs. Voici les meilleurs résultats:
- Images réactives
- Améliorer les performances
- Typographie réactive
- Requêtes multimédias en JavaScript
- Amélioration progressive
- Mise en page
Avec ces sujets à l'esprit, j'ai diffusé une série de podcasts demandant à certains de nos chefs de file de l'industrie leur avis. Dans leurs réponses, un point était unanime: concentrez-vous sur les bases avant de commencer à vous soucier des techniques excitantes et avancées. En ramenant les choses à l'essentiel, nous sommes en mesure de créer une interface robuste pour tout le monde, en superposant des fonctionnalités lorsque l'appareil ou le contexte de l'utilisateur le permet.
"Alors ... qu'en est-il de ces techniques avancées?" Je vous entends demander. Je pense que Stephen Hay a le mieux résumé la situation en disant: «La technique ultime de RWD est de commencer par n’utiliser aucune technique avancée de RWD. Commencez avec du contenu structuré et progressez. N'ajoutez un point d'arrêt que lorsque la conception est interrompue et que le contenu le dicte et ... c'est tout. »
Dans cet article, je vais commencer par les bases et ajouter des couches de complexité au fur et à mesure que la situation le permet, pour développer ces techniques avancées. Commençons.
Images réactives
Les médias fluides étaient un élément clé de RWD lorsqu'il a été défini pour la première fois par Ethan Marcotte. largeur: 100%; , largeur max: 100%; fonctionne toujours aujourd'hui, mais le paysage d'image réactif est devenu beaucoup plus compliqué. Avec un nombre croissant de tailles d'écran, de densité de pixels et d'appareils à prendre en charge, nous avons besoin d'un plus grand contrôle.
Les trois principales préoccupations ont été définies par le Responsive Images Community Group (RICG):
- La taille en kilo-octets de l'image que nous envoyons sur le fil
- La taille physique de l'image que nous envoyons aux appareils à haute résolution
- Le recadrage de l'image sous la forme d'une direction artistique pour la taille particulière de la fenêtre
Yoav Weiss, avec l’aide d’Indiegogo, a réalisé la majorité du travail sur l’implémentation de Blink - le fork de Google WebKit, et au moment où vous lirez ceci, il sera livré dans Chrome et Firefox. Safari 8 livrera srcset, cependant l'attribut size n'est que dans les versions nocturnes et picture> n'est pas encore implémenté.
Avec l'arrivée de quelque chose de nouveau dans notre processus de développement Web, il peut être difficile de démarrer. Passons en revue un exemple étape par étape.
img! - Déclarez l'image de remplacement pour tous les navigateurs qui ne supportent pas les images -> src = "horse-350.webp"! - Déclarez toutes les tailles d'image dans srcset. Incluez la largeur de l'image en utilisant le descripteur w pour informer le navigateur de la largeur de chaque image .--> srcset = "horse-350.webp 350w, horse-500.webp 500w, horse-1024.webp 1024w, horse.webp 2000w "! - Les tailles informent le navigateur de la mise en page de notre site. Ici, nous disons que pour toute fenêtre de 64em et plus, utilisez une image qui occupera 70% de la fenêtre -> tailles = "(min-width: 64em) 70vw,! - Si la fenêtre n'est pas ça big, alors pour toute fenêtre de 37,5em et plus, utilisez une image qui occupe 95% de la fenêtre -> (largeur min: 37,5em) 95vw,! - et si la fenêtre est plus petite que cela, utilisez une image qui occupe 100% de la fenêtre -> 100vw "! - toujours avoir un texte alternatif .--> alt =" Un cheval "/>
Du point de vue des performances, peu importe si vous utilisez min-width ou max-width dans l'attribut des tailles, mais l'ordre source importe. Le navigateur utilisera toujours la première taille correspondante.
N'oubliez pas non plus que nous codons en dur l'attribut des tailles pour qu'il soit directement défini par rapport à notre conception. Cela peut entraîner des problèmes pour avancer. Par exemple, si vous redéfinissez votre site, vous devrez revoir tous les img> ou picture> et redéfinir les tailles. Si vous utilisez un CMS, cela peut être résolu dans le cadre de votre processus de construction.
WordPress a déjà un plugin pour vous aider. Il définit le srcset sur les variétés d'images standard WP et vous permet de déclarer les tailles dans un emplacement central. Lorsque la page est générée à partir de la base de données, elle échange toutes les mentions sur img> et les remplace par le balisage d'image.
De base
- Demandez-vous si vous avez vraiment besoin d'inclure une image. Le contenu principal de l'image est-il ou est-il décoratif? Une image en moins signifie un temps de chargement plus rapide
- Optimisez les images que vous devez inclure à l'aide d'ImageOptim
- Définissez des en-têtes d'expiration pour vos images sur votre serveur ou fichier .htaccess (voir les détails sous «Performances»)
- PictureFill fournit un support polyfill pour les images
Avancée
- Chargement paresseux de vos images à l'aide du plug-in Lazy Load de jQuery
- Utilisez HTMLImageElement.Sizes et HTMLPictureElement pour la détection des fonctionnalités.
- Le plugin avancé PictureFill WP, trouvé sur Github, vous permettra de définir des valeurs de largeurs et de tailles d'image personnalisées
Performance
Pour obtenir les performances les plus rapides perçues sur nos pages, nous avons besoin de tout le HTML et du CSS requis pour rendre la partie supérieure de notre page dans la première réponse du serveur. Ce nombre magique est de 14 Ko et est basé sur la taille maximale de la fenêtre de congestion au cours du premier temps d'aller-retour (RTT).
Patrick Hamann, responsable technique frontend du Guardian, et son équipe ont réussi à franchir la barrière des 1000ms en utilisant un mélange de techniques frontend et backend. L’approche du Guardian consiste à s’assurer que le contenu requis - l’article - est livré à l’utilisateur le plus rapidement possible et dans le nombre magique de 14 Ko.
Examinons le processus:
- L'utilisateur clique sur un lien Google vers une actualité
- Une seule demande de blocage est envoyée à la base de données pour l'article. Aucune histoire ou commentaire connexe n'est demandé
- Le HTML est chargé contenant du CSS critique
- dans la tête>
- Un processus «Couper la moutarde» est entrepris et tous les éléments conditionnels basés sur les fonctionnalités de l'appareil de l'utilisateur sont chargés
- Tout contenu lié à ou prenant en charge l'article lui-même (images d'articles connexes, commentaires d'article, etc.) est chargé paresseusement en place
Optimiser le chemin de rendu critique de cette manière signifie que la tête> fait 222 lignes. Cependant, le contenu critique que l'utilisateur est venu voir fait toujours partie de la charge utile initiale de 14 Ko lorsqu'il est gzippé. C’est ce processus qui permet de briser cette barrière de rendu de 1 000 ms.
Chargement conditionnel et paresseux
Le chargement conditionnel améliore l'expérience de l'utilisateur en fonction de la fonctionnalité de son appareil. Des outils tels que Modernizr vous permettent de tester ces fonctionnalités, mais sachez que ce n'est pas toujours parce qu'un navigateur dit qu'il offre une assistance que cela signifie une assistance complète.
Une technique consiste à retarder le chargement de quelque chose jusqu'à ce que l'utilisateur montre son intention d'utiliser cette fonctionnalité. Cela serait considéré comme conditionnel. Vous pouvez suspendre le chargement des icônes sociales jusqu'à ce que l'utilisateur survole ou touche les icônes, ou vous pouvez éviter de charger une carte Google Map iframe sur des fenêtres plus petites où l'utilisateur est susceptible de préférer un lien vers une application de cartographie dédiée. Une autre approche consiste à «couper la moutarde» - voir l’encadré ci-dessus pour plus de détails à ce sujet.
Le chargement différé est défini comme quelque chose que vous avez toujours l'intention de charger sur la page - des images qui font partie de l'article, des commentaires ou d'autres articles connexes - mais qui n'ont pas besoin d'être là pour que l'utilisateur commence à consommer le contenu.
De base
- Activez gzipping pour les fichiers et définissez des en-têtes d'expiration pour tout le contenu statique (netm.ag/expire-260)
- Utilisez le plugin jQuery Lazy Load. Cela charge les images à l'approche de la fenêtre, ou après un certain laps de temps
Avancée
- Configurez Fastly ou CloudFlare. Les réseaux de distribution de contenu (CDN) fournissent votre contenu statique aux utilisateurs plus rapidement que votre propre serveur, et ont des niveaux gratuits
- Activez SPDY pour les navigateurs compatibles http2 pour profiter des fonctionnalités http2 telles que les requêtes http parallèles
- Social Count permet le chargement conditionnel de vos icônes sociales
- L'utilisation de l'API Static Maps vous permettra de remplacer les cartes Google interactives par des images. Jetez un œil à l'exemple de Brad Frost sur netm.ag/static-260
- Ajax Include Pattern chargera des extraits de contenu à partir d'un attribut data-before, data-after ou data-replace
Typographie réactive
La typographie consiste à rendre votre contenu facile à digérer. La typographie réactive étend cela pour assurer la lisibilité sur une grande variété d'appareils et de fenêtres. Jordan Moore admet que ce type est une chose sur laquelle il ne veut pas bouger. Déposez une image ou deux si vous en avez besoin, mais assurez-vous d'avoir un texte de qualité.
Stephen Hay suggère de définir la taille de la police HTML à 100% (lire: laissez-la telle quelle) car chaque fabricant de navigateur ou de périphérique fait une valeur par défaut raisonnablement lisible pour une résolution ou un périphérique particulier. Pour la plupart des navigateurs de bureau, il s'agit de 16 pixels.
D'autre part, Moore utilise l'unité REM et la taille de police HTML pour définir une taille de police minimale pour certains éléments de contenu. Par exemple, si vous voulez que la signature d'un article soit toujours 14px, définissez-la comme taille de police de base sur l'élément HTML et définissez .byline {font-size: 1rem;}. Lorsque vous mettez à l'échelle le corps: font-size: en fonction de la fenêtre, vous n'aurez pas d'impact sur le style .by-line.
Une bonne longueur de ligne de lecture est également importante - visez entre 45 et 65 caractères. Vous pouvez utiliser un bookmarklet pour vérifier votre contenu. Si vous prenez en charge plusieurs langues avec votre conception, la longueur de la ligne peut également varier. Moore suggère d'utiliser: lang (de) article {max-width: 30em} pour couvrir tous les problèmes.
Pour maintenir le rythme vertical, définissez margin-bottom par rapport aux blocs de contenu, ul>, ol>, blockquote>, table>, blockquote> et ainsi de suite, à la même hauteur que votre ligne. Si le rythme est interrompu avec l'introduction d'images, vous pouvez le corriger en ajoutant Baseline.js ou BaselineAlign.js.
De base
- Basez votre police sur un corps à 100%
- Travailler en unités em relatives
- Réglez vos marges à la hauteur de votre ligne pour maintenir le rythme vertical dans votre conception
Avancée
- Améliorez les performances de chargement des polices avec Enhance.js ou le chargement de polices différé
- Utilisez Sass @includes pour les en-têtes sémantiques.
- Souvent, nous devons utiliser le style h5 dans un widget de la barre latérale qui nécessite un balisage h2. Utilisez les mixins typographiques de Bearded pour contrôler la taille et rester sémantique avec le code ci-dessous:
.sidebar h2 {@include rubrique-5}
Requêtes multimédias en JavaScript
Depuis que nous sommes en mesure de contrôler la mise en page dans une variété de fenêtres via des requêtes multimédias, nous cherchons un moyen de lier cela à l'exécution de notre JavaScript. Il existe plusieurs façons de déclencher JavaScript sur certaines largeurs, hauteurs et orientations de fenêtre, et certaines personnes intelligentes ont écrit des plugins JS natifs faciles à utiliser comme Enquire.js et Simple State Manager. Vous pouvez même le construire vous-même en utilisant matchMedia. Cependant, vous rencontrez le problème dont vous avez besoin pour dupliquer vos requêtes multimédias dans votre CSS et JavaScript.
Aaron Gustafson a une astuce intéressante qui signifie que vous n’avez pas à gérer et à faire correspondre vos requêtes multimédias dans votre CSS et votre JS. L'idée est venue à l'origine de Jeremy Keith et, dans cet exemple, Gustafson l'a mise en œuvre complètement.
En utilisant getActiveMQ (netm.ag/media-260), injectez div # getActiveMQ-watcher à la fin de l'élément body et cachez-le. Ensuite, dans l'ensemble CSS # getActiveMQ-watcher {font-family: break-0;} à la première requête multimédia, font-family: break-1; au second, font-family: break-2; au troisième et ainsi de suite.
Le script utilise watchResize () (netm.ag/resize-260) pour vérifier si la taille de la fenêtre a changé, puis relit la famille de polices active. Vous pouvez maintenant l'utiliser pour accrocher des améliorations JS telles que l'ajout d'une interface à onglets à une dl> lorsque la fenêtre le permet, la modification du comportement d'une lightbox ou la mise à jour de la disposition d'une table de données. Consultez le code getActiveMQ sur netm.ag/active-260.
De base
- Oubliez JavaScript pour les différentes fenêtres. Fournissez du contenu et des fonctions de site Web aux utilisateurs de manière à ce qu'ils puissent y accéder dans toutes les fenêtres. Nous ne devrions jamais avoir besoin de JavaScript
Avancée
- Étendez la méthode de Gustafson en utilisant Breakup comme liste prédéfinie de requêtes multimédias et en automatisant la création de la liste des familles de polices pour getActiveMQ-watcher
Amélioration progressive
Une idée fausse courante sur l'amélioration progressive est que les gens pensent: "Eh bien, je ne peux pas utiliser cette nouvelle fonctionnalité", mais en réalité, c'est le contraire. L'amélioration progressive signifie que vous pouvez proposer une fonctionnalité si elle n'est prise en charge que dans un seul navigateur, voire pas, et avec le temps, les utilisateurs bénéficieront d'une meilleure expérience à mesure que de nouvelles versions arriveront.
Si vous regardez la fonction de base de n'importe quel site Web, vous pouvez le fournir au format HTML et demander au serveur de faire tout le traitement. Paiements, formulaires, likes, partage, e-mails, tableaux de bord - tout peut être fait. Une fois la tâche de base établie, nous pouvons ensuite superposer les technologies impressionnantes, car nous avons un filet de sécurité pour attraper celles qui échouent. La plupart des approches avancées dont nous avons parlé ici sont basées sur une amélioration progressive.
Mise en page
La mise en page flexible est simple à dire, mais elle comporte de nombreuses approches différentes. Créez des mises en page de grille simples avec moins de balisage en utilisant: nth-child () selector.
/ * déclare la première largeur du mobile pour la grille * / .grid-1-4 {float: left; largeur: 100%; } / * Lorsque la fenêtre d'affichage est au moins 37,5em, définissez la grille sur 50% par élément * / @media (largeur min: 37,5em) {.grid-1-4 {largeur: 50%; } / * Efface le flottant tous les deux éléments APRÈS le premier. Ceci cible le 3ème, 5ème, 7ème, 9ème ... dans la grille. * / .Grid-1-4: nth-of-type (2n + 1) {clear: left; }} @media (min-width: 64em) {.grid-1-4 {width: 25%; } / * Supprime le précédent clear * / .grid-1-4: nth-of-type (2n + 1) {clear: none; } / * Efface le flotteur tous les 4 éléments APRÈS le premier. Ceci cible le 5e, 9e ... dans la grille. * / .Grid-1-4: nth-of-type (4n + 1) {clear: left; }}
Dites adieu à l'utilisation de la position et du flottement pour vos mises en page. Bien qu'ils nous aient bien servis à ce jour, leur utilisation pour la mise en page a été un hack nécessaire. Nous avons maintenant deux nouveaux enfants sur le bloc qui aideront à résoudre tous nos problèmes de mise en page - Flexbox et Grids.
Flexbox est idéal pour les modules individuels, contrôlant la disposition des éléments de contenu dans chacun des modules. Il y a des mises en page que nous essayons de fournir qui peuvent être plus facilement réalisées à l'aide de Flexbox, et cela est encore plus vrai avec les sites réactifs. Pour en savoir plus, consultez le guide CSS Tricks sur Flexbox ou Flexbox Polyfill.
Disposition de la grille CSS
La grille est plus destinée à la mise en page au niveau macro. Le module Grid layout vous donne un excellent moyen de décrire votre mise en page dans votre CSS. Bien qu'il soit encore au stade de brouillon pour le moment, je recommande cet article sur la mise en page CSS Grid de Rachel Andrew.
Pour terminer
Ce ne sont là que quelques conseils pour étendre votre pratique réactive. Lorsque vous abordez tout nouveau travail réactif, prenez du recul et assurez-vous de bien maîtriser les bases. Commencez avec votre contenu, votre HTML et superposez des expériences améliorées sur eux et il n'y aura aucune limite à l'endroit où vous pouvez utiliser vos conceptions.
Cet article a été initialement publié dans le numéro 260 de magazine net.
