Share
Les requêtes multimédia constituent un élément essentiel de la conception Web moderne, mais elles ne sont pas toujours parfaites. Dans cet article, nous allons examiner l’idée de «requêtes d’éléments»; ce que beaucoup discutent est l'avenir de la conception Web réactive.
L'article d'Ethan sur Responsive Web Design a changé la façon dont nous construisons des sites Web, pour toujours. Son article a inspiré et a été rapidement adopté par les concepteurs et les développeurs Web. Des approches telles que «Mobile First», «Desktop First» et «Device Agnostic» ont émergé, des modèles de conception ont été développés depuis, de nouvelles normes telles que
Nous ne construisons plus de sites Web pour des tailles d'écran, des navigateurs ou des appareils particuliers. Nous les construisons à la place pour qu'ils soient aussi agréables sur tous les appareils, quelle que soit la taille de l'écran. Pour ce faire, nous utilisons des «requêtes multimédia» sans oublier la balise méta de la fenêtre d'affichage..
Les requêtes de média sont conçues pour nous permettre d’adapter les règles de style à un environnement spécifique. L’une des utilisations les plus courantes des requêtes multimédia consiste à modifier les styles dans une certaine plage de largeurs de fenêtres. Le code suivant, par exemple, masque la barre latérale lorsque le site Web est accessible via une fenêtre jusqu’à 720 pixels de large..
.site-sidebar display: flex; flex: 1 1 320px; @media (largeur maximale: 720px) .site-sidebar display: none;
Les requêtes multimédia ont évolué, de même que les appareils, avec plusieurs fonctionnalités supplémentaires telles que orientation et résolution. L'exemple suivant montre comment utiliser l'une de ces fonctionnalités pour créer une image plus grande sur un écran haute résolution.
.logo du site a display: inline-block; background: url (images / logo.png) no-repeat; @ écran multimédia et (résolution minimale: 2dppx) background: url (images/[email protected]);
Les requêtes multimédias sont devenues un élément essentiel pour offrir une expérience réactive. Familiarisez-vous avec les articles, tutoriels et astuces permettant de mieux comprendre les requêtes des médias sur nos précédents articles dans Tuts +, ainsi que sur Internet..
Les requêtes médiatiques ne sont pas la solution miracle à toutes les situations en matière de conception Web réactive. En fait, cela n'a jamais été supposé être le cas..
Aujourd'hui, il existe sur le marché une large gamme d'appareils de différentes tailles et caractéristiques, brouillant la ligne de démarcation entre «mobile» et «bureau» (je vous regarde «ordinateurs portables hybrides»). Pour cette raison, maintenir l’esthétique du site Web, une expérience utilisateur exceptionnelle et des performances optimales n’a jamais été aussi difficile..
À Google IO 2015, Google permet aux développeurs de consulter leur site Web sur plus de 100 appareils différents..Et une fois que vous ajoutez des éléments tels que des annonces, des tableaux et du contenu existant dans le mix, la situation peut être encore pire. Bientôt, vous rencontrerez les aspects «pas très bons» des requêtes des médias.
Prenons l'exemple suivant. Nous avons un composant d'interface utilisateur pour afficher le profil de notre membre d'équipe. Nous souhaitons utiliser ce composant dans plusieurs endroits de notre site Web. Cet exemple montre comment l’interface utilisateur est agencée à 780px largeur de la fenêtre.
Dans la page "profil de l'utilisateur", nous plaçons l'avatar de l'utilisateur à gauche et le nom d'utilisateur ainsi que la biographie à droite..
Présentation du profil utilisateur dans le profil "Utilisateur".Dans la page «équipe» de notre site Web, toutefois, la disposition change; l'image de l'avatar de l'utilisateur est maintenant placée en haut, et le nom d'utilisateur ainsi que la biographie sont en dessous. La taille de la police pourrait aussi être un peu plus petite.
Présentation du profil utilisateur dans la page "équipe".Cette situation peut être corrigée avec des requêtes multimédia. Nous pouvons, par exemple, écrire le CSS, comme suit:
/ ** * Profil * / .team-profile text-align: center; .team-profile .bio margin-top: 20px; taille de police: 14px; @media (min-width: 480px) .team-profile text-align: left; affichage: flex; .team-profile .avatar flex: 0 0 120px; .team-profile .bio taille de la police: 16px; flex: 0 1 580x; / ** * Carte de profil. * / .team-profile-card text-align: center; .team-profile-card .bio marge supérieure: 20px; taille de police: 14px; / ** * Probablement, certains remplacent * / .page .team-profile-card …
C'est réparable, tant que nous utilisons des classes d'identification supplémentaires: .profil de l'utilisateur et .profil-utilisateur.
Cependant, cela va également à l'encontre du fait que notre interface utilisateur est un composant réutilisable; une interface utilisateur pouvant être placée n'importe où sur le site Web, pouvant s'adapter à son environnement.
Dans cet exemple, nous souhaitons que la disposition de notre composant s'adapte lorsqu'elle est encapsulée dans un petit conteneur plutôt que lorsqu'elle est comprimée par la fenêtre du navigateur. Donc, plutôt que de s’appuyer sur la taille de la fenêtre du navigateur pour changer la disposition, pourquoi ne pouvons-nous pas le faire à la place? niveau de l'élément?
L'idée des requêtes d'éléments est apparue vers le début de 2012; Quelques années après que Responsive Web Design devienne la méthodologie principale. Malheureusement, il n'y avait probablement pas beaucoup de raisons convaincantes de considérer cela comme une norme Web à cette époque: le monde commençait toujours à s'habituer à la mollesse..
@ianstormtaylor ouais "élément de requêtes" est venu de temps en temps
- Paul Irish (@paul_irish) le 24 janvier 2012
Les communautés Web ont lancé leurs propres initiatives. RICG (Responsive Issue Community Group), le même groupe qui a lancé la
Les requêtes d'élément fonctionnent de la même manière que les requêtes multimédia. sauf qu'ils écoutent la taille de l'élément à la place de la fenêtre du navigateur. Cela nous permet de construire un système d’interface utilisateur vraiment modulaire avec une base de code DRY-er. À partir du même exemple, nous pourrions réécrire les styles de notre composant d'interface utilisateur avec EQCSS, comme suit:
.team-profile text-align: center; .team-profile .bio margin-top: 20px; taille de police: 14px; @element ".team-profile" et (min-width: 480px) .team-profile display: flex; .team-profile .avatar flex: 1 1 120px; .team-profile .bio text-align: left; taille de police: 16px; flex: 1 1 580x;
Ici, nous ne nous soucions pas de la largeur de la fenêtre. Comme vous pouvez le voir ci-dessus, tant que le UI est tendu à 480px ou plus large, nous affichons le .avatar et le .bio cote à cote. Lorsque la largeur de l'interface utilisateur diminue en dessous 480px nous laissons .avatar et .bio empiler et aligner le contenu au centre.
Juste pour clarifier les choses, je ne dis pas qu’utiliser des requêtes avec les médias est mauvais, pas du tout. Les requêtes des médias sont merveilleuses et nous en avons été témoins sur de nombreux sites Web construits aujourd'hui. Les requêtes multimédia et les requêtes d'éléments peuvent certainement coexister. Cependant, il existe de nombreux scénarios de conception dans lesquels l'utilisation de requêtes d'éléments aurait plus de sens que l'utilisation de requêtes multimédias..
Malheureusement, les requêtes d'éléments ont encore un très long chemin à parcourir avant de passer finalement au standard Web; notre espoir en cela repose avec toutes les bonnes personnes chez RICG.
En attendant, nous pouvons explorer le potentiel des requêtes d’éléments grâce à une bibliothèque JavaScript telle que EQCSS. Et c'est exactement ce que nous allons faire dans le prochain tutoriel. Restez à l'écoute!
Accentsconagua