La grande erreur de requête multimédia CSS

Vous arrive-t-il de vous sentir bizarre lorsque tout le monde autour de vous fait quelque chose que vous penseriez normalement être mal [ou pas tout à fait idéal à tout le moins], mais d'une manière ou d'une autre, personne ne semble vouloir dire quoi que ce soit pour une raison ou une autre ? C'est un sentiment très étrange de voir tout le monde faire sa meilleure impression d'un observateur malheureux. Cela me rappelle en quelque sorte cette vieille fable, "Les vêtements neufs de l'empereur".

J'ai en quelque sorte toujours ressenti cela à propos des requêtes média CSS. Pourquoi tout le monde accepte-t-il tellement une technologie qui ne semble tout simplement pas faire le travail ? Pourquoi, en tant que communauté, ne nous sommes-nous pas réunis pour l'améliorer de manière réelle et significative ? Pourquoi n'avons-nous pas trouvé quelque chose de mieux ?

Aujourd'hui, les requêtes multimédias CSS se trouvent être la pierre angulaire fonctionnelle de la conception Web réactive. Mais, il n'a jamais été conçu pour l'usage que tout le monde en fait aujourd'hui, et la preuve en est dans la pratique. Je tombe encore souvent sur des sites Web lorsque j'utilise une tablette qui, au premier abord, semble bien conçue, mais qui semble et se sent carrément bancale lorsque vous les mettez à l'épreuve.

Il y a quelque chose de fondamentalement faux dans cette approche de la conception Web réactive que nous n'avons pas encore correctement abordée, et j'aimerais être l'une des rares voix à appeler l'empereur pour sa nudité sur celui-ci. Heureusement cependant, de nos jours, je suis heureux qu'il n'y ait presque aucune chance d'être brûlé sur le bûcher pour avoir ce point de vue alternatif.

Quel est le problème avec les requêtes média CSS

Les requêtes multimédia CSS ont été conçues pour quelque chose, mais cette chose n'est pas une conception Web réactive. D'après mon expérience, voici sept (7) gros problèmes que j'ai rencontrés lorsque j'ai essayé de les utiliser pour travailler avec des sites Web :

1. Pas intuitif :

"Les requêtes multimédia CSS sont intuitives", n'a jamais dit aucun concepteur de sites Web. La façon dont vous définissez une requête multimédia est assez simple, mais il n'est pas toujours clair exactement comment les choses se dérouleront sur de vrais navigateurs, sur de vrais appareils et dans une myriade de scénarios.

 Écran @media uniquement et (min-width : 320px) et (max-width : 480px) {
    /** Les règles CSS vont ici **/
}

Le code ci-dessus s'applique à la fenêtre lorsqu'elle est comprise entre 320 et 480 pixels. Cependant, ce n'est pas exactement définitif [ou intuitif] lorsque vous voulez faire quelque chose de plus spécifique, comme appliquer une règle de style lorsque l'appareil est une tablette en mode paysage. Il n'est pas impossible de [en quelque sorte] définir une requête média pour ce faire, mais ce n'est certainement pas intuitif – ou définitif.

2. Conditionnalité limitée :

Les requêtes média CSS sont dynamiques et vous permettent de définir des instructions conditionnelles dans votre CSS. Par exemple, si la fenêtre se situe entre ceci et cela, faites l'autre. Cependant, vous êtes principalement limité aux considérations de la fenêtre d'affichage, et il existe de nombreux autres scénarios conditionnels qui auraient du sens dans la conception Web moderne.

Supposons que vous construisez une application Web progressive. Il y a des moments où il serait utile de styliser certains éléments de l'interface utilisateur différemment en fonction du système d'exploitation. Par exemple, il est d'usage d'avoir la barre d'onglets en bas pour les appareils iOS, alors que pour Android c'est l'inverse. Alors, comment feriez-vous exactement pour que cela fonctionne avec les requêtes média CSS ?

Vous ne pouvez pas, car les requêtes média CSS ne sont pas construites avec une fonctionnalité qui vous le permettrait. En plus de cela, il se peut que vous deviez effectuer de nombreuses autres personnalisations via CSS, mais les requêtes multimédias ne sont pas une option lorsque vous avez besoin de degrés variables de conditionnalité simple à avancée.

3. Non extensible nativement :

Les requêtes média CSS sont des fonctionnalités intégrées au navigateur. Cela signifie qu'il n'est pas nativement extensible. En d'autres termes, vous ne pouvez pas ajouter de fonctionnalités supplémentaires et améliorées aux requêtes média CSS de manière native via l'interface CSS.

Même si de nouvelles fonctionnalités de requête multimédia CSS sont approuvées par le processus de normalisation Web [qui souffre depuis longtemps], il faut encore du temps avant que ces fonctionnalités ne deviennent utilisables en raison de l'ubiquité. De plus, toutes les fonctionnalités ajoutées ne peuvent pas vous être utiles, il vous reste donc à trouver un autre moyen de résoudre votre défi spécifique si vous n'obtenez pas ce que vous voulez.

Bien sûr, il existe un moyen d'étendre CSS, mais vous devez vraiment bien connaître JavaScript, et ce n'est pas un processus pratique pour la plupart des concepteurs de sites Web.

4. Ne convient pas pour la rénovation :

Certains pourraient trouver cela difficile à croire, mais avant l'apparition des appareils mobiles, il existait en fait de nombreux sites Web, et aucun d'entre eux n'était adapté aux mobiles. En conséquence, ces sites Web de l'ère des ordinateurs de bureau devaient être mis à niveau.

Malheureusement, les requêtes média CSS ne sont pas une très bonne option pour cette tâche. Parce que ces sites Web ont été créés avant que les appareils mobiles ne soient pertinents, beaucoup d'entre eux ont des éléments de conception qui ne se prêtent pas à une conception Web réactive, par exemple des barres latérales, des mises en page basées sur des tableaux, du contenu à onglets, etc. De plus, une proportion importante de ces sites Web sont construit sur un système de gestion de contenu (CMS) comme WordPress, Drupal, Magento, etc., et l'intégration efficace des requêtes média CSS [front-end] à partir du back-end est extrêmement difficile, voire impossible à coordonner.

J'ai dû moderniser des sites Web alimentés par Magento Enterprise, WordPress et un autre qui utilisait un CMS personnalisé basé sur Coldfusion, et tous les projets auraient été carrément impossibles à l'aide de requêtes média CSS [ce que tous mes clients ont essayé avant d'utiliser notre alternative approcher].

5. Code non efficace :

L'utilisation de requêtes média CSS pour rendre une page Web réactive nécessite une multiplication de code à grande échelle. En raison de la façon dont ces directives fonctionnent [avec vos points d'arrêt], vous devez définir des règles de style individuelles dans chaque bloc de requête multimédia.

 section {largeur : 960px ;}

/* Portrait */
Écran @media only et (min-device-width : 320px) et (max-device-width : 480px) et (-webkit-min-device-pixel-ratio : 2) et (orientation : portrait) {
    section {largeur : 100 %}
}
/* Paysage */
Écran @media only et (min-device-width : 320px) et (max-device-width : 480px) et (-webkit-min-device-pixel-ratio : 2) et (orientation : paysage) {
    section {largeur : 100 % ;}
}

Lors de l'écriture du code ci-dessus, mon intention initiale était de rendre les éléments <section> de ma page fluides [largeur de 100 %] sur tous les appareils mobiles. Cependant, comme je n'ai pas de capacité native de détection de périphérique, je dois faire des compromis et définir une règle de style dans chaque bloc de requête multimédia CSS orienté mobile pour m'assurer que la nouvelle propriété s'appliquera dans tous les scénarios pertinents.

Cela signifie que l'efficacité fonctionnelle de la cascade de feuilles de style et les bons principes de développement de Do-not-Repeat-Yourself doivent passer au second plan.

6. Augmente la complexité du flux de travail :

Les requêtes multimédia CSS ne traitent qu'un aspect très spécifique de la conception Web réactive qui est presque entièrement axée sur le redimensionnement de la mise en page. Ergo, pour faire autre chose que cela, vous devez compter sur JavaScript pour combler la différence. Cela introduit des exigences d'apprentissage supplémentaires pour le code et les outils.

De plus, la manière non définitive dont il [les requêtes multimédias] gère les points d'arrêt signifie que vous devez passer plus de temps [et d'argent] à tester vos pages Web sur de nombreux appareils virtuels et/ou physiques pour vous assurer que les choses fonctionnent comme vous l'aviez prévu à l'origine. . Et, vous devez tout retester à nouveau lorsque vous apportez des modifications importantes à votre mise en page.

Par l'action simple et ciblée d'utiliser des requêtes média CSS, vous augmentez considérablement le nombre d'étapes nécessaires pour créer une page Web moderne.

7. Diminue les performances :

En raison du fonctionnement des requêtes média CSS, vous aurez besoin de beaucoup plus de code CSS qu'autrement pour rendre votre site Web réactif / adapté aux mobiles. Selon les données de HTTPArchive.org, la taille des fichiers CSS a augmenté de 114 % au cours des cinq dernières années. L'augmentation de la taille des fichiers HTML a culminé à environ 53 % au cours de la même période.

Cette situation particulière a des implications sur les performances de votre site Web, car il est inévitable qu'il soit plus lent après la mise en œuvre des requêtes média CSS [dans un contexte de conception Web réactif] qu'il ne l'a jamais été auparavant, en particulier pour les appareils mobiles utilisant des réseaux haut débit mobiles moins qu'idéaux.

Et, mis à part le problème de l'augmentation de la taille des fichiers, il n'existe aucun mécanisme interne dans les requêtes média CSS pour réellement améliorer les performances de votre page Web. Pour cela, vous devrez tirer parti des techniques JavaScript avancées pour activer ces améliorations.

Pourquoi l'utilisons-nous encore ?

Si je vous demandais quel pourcentage de sites Web utilisaient des requêtes média CSS, quelle serait votre réponse ? Avec tout le stress que les concepteurs de sites Web ont dû endurer au fil des ans, vous penseriez que nous aurions probablement surmonté le problème de l'adoption, mais vous auriez tout à fait tort.

Le pourcentage de sites Web utilisant des requêtes média CSS sur l'ensemble du Web est d'environ 0,2 %. Comparez cela avec le pourcentage de sites Web utilisant jQuery à 18%. Cela signifie que vous avez 90 fois plus de chances de tomber sur un site Web alimenté par jQuery que sur un site Web réactif [sans compter ceux qui se trouvent être les deux].

Pourquoi une boîte à outils basée sur une technologie de base [JavaScript] que certaines personnes semblent trouver compliquée et superflue serait-elle si en avance sur une qui est apparemment moins complexe [CSS] et destinée à résoudre un problème sans doute plus important [convivialité mobile] ? De toute évidence, il y a quelque chose de grave qui ne va pas ici qui entrave l'adoption, et il faut y remédier.

Les requêtes multimédia CSS ont trouvé leur chemin dans les navigateurs Web pour gérer un défi spécifique, mais elles ont ensuite été rédigées pour porter tout le poids de la conception Web réactive sur ses épaules. C'est un peu comme s'entraîner pour un récital de flûte à bec de 3e année, pour ensuite être transporté par magie au Royal Albert Hall pour rendre un solo de trombone du Messie de Haendel; Pas juste!

Avec tous les défis de la conception Web moderne, il est extrêmement surprenant que nous soyons toujours dans cette affaire de requête multimédia. Cela ne va pas assez loin pour traiter certains problèmes hérités importants, en plus de certains nouveaux dans de nouveaux domaines comme la conception progressive d'applications Web. En tant que tel, je pense qu'il est temps que nous trouvions une alternative. Mais qu'est-ce que ce serait exactement ?

Quelle est la solution?

La solution à tout cela est vraiment très simple : JavaScript. Maintenant, avant de prendre cette fourche, donnez-moi une chance de m'expliquer.

JavaScript est le seul composant de la trinité HTML5 où l'extensibilité n'est pas un gros mot. Vous ne pouvez pas étendre le balisage HTML en utilisant plus de HTML, et vous ne pouvez certainement pas étendre le CSS nativement avec CSS. Cependant, vous pouvez étendre JavaScript nativement en utilisant JavaScript, et vous pouvez même faire de même pour CSS.

La manipulation de CSS avec JavaScript est largement abordée dans le programme Web Standards Curriculum du W3C. L'interface DOM document.stylesheets nous permet d'accéder aux feuilles de style appliquées à une page Web, y compris toutes les feuilles de style externes référencées à l'aide de la balise <link> de HTML. Ce n'est pas une chose facile à faire, mais c'est possible.

Je devrais donc développer la réponse initiale : ce n'est pas simplement du JavaScript, c'est du CSS assisté par JavaScript . JavaScript est une plate-forme géniale avec des fonctionnalités comme vous ne le croiriez pas, mais CSS est l'endroit où travaillent la plupart des concepteurs de sites Web. Si nous pouvions en quelque sorte créer une sorte de pont fonctionnel entre ces deux où un concepteur Web pourrait écrire un ensemble de règles CSS pour tirer parti de la fonctionnalité JavaScript, cela changerait quelque peu la donne pour la conception Web.

Montre-moi du code

Depuis environ deux ans, je travaille sur une nouvelle boîte à outils CSS assistée par JavaScript appelée rKit. L'idée était de créer un outil convivial pour les concepteurs non seulement pour remplacer les requêtes multimédias CSS pour une conception Web réactive, mais pour résoudre certains des défis connus [et inconnus] auxquels les concepteurs/développeurs Web sont confrontés lors de la création de sites Web et d'applications Web modernes.

Il y a beaucoup de choses dans le concept, mais voici un petit extrait de code CSS pour l'expliquer :

 #my-element[rk="if @viewport.width entre 320 et 480"]{background-color : #0000ff;}

Avec rKit, les règles CSS ressemblent à des sélecteurs de valeur d'attribut modifiés. Vous pouvez ensuite définir une expression dans la section valeur. La syntaxe de cette expression est conçue pour être simple et intuitive.

Remarque : rk est un identificateur d'attribut constant.

Le code ci-dessus est fonctionnellement équivalent à la requête multimédia CSS ci-dessous :

 Écran @media uniquement et (min-device-width : 320px) et (max-device-width : 480px) {
    #mon-élément {background-color:#0000ff;}
}

Cependant, vous pouvez faire beaucoup plus avec rKit. Voici un autre exemple rapide :

 #my-element[rk="if @self.width entre 320 et 480"]{background-color : #00ff00;}

En changeant simplement la référence d'entité de @viewport en @self , nous avons essentiellement configuré ce que l'on appelle communément une requête d'élément. Donc, ce qui se passe maintenant, c'est que lorsque la largeur de #my-element est comprise entre 320 et 480 pixels, la déclaration donnée [ background-color: #00ff00 ] s'appliquera.

Vous pouvez également utiliser des classes au lieu de déclarations pures :

 #my-element[rk="if @self.width entre 320 et 480 then addClass(c_mobile_320)"]{}
.c_mobile_320 {couleur de fond : #00ff00 ;}

Ce n'est que la partie émergée de l'iceberg. Avec rKit, vous pouvez faire des choses assez impressionnantes comme la gestion des événements, l'observation des mutations, les requêtes de quantité, le routage, la liaison de données [jusqu'à 7 voies] et une foule d'autres trucs sympas, le tout en utilisant du code CSS pur et sans écriture une seule ligne de JavaScript.

rKit sera gratuit et open source lors de son lancement. Et, il comportera également un pack de performances spécial que vous pouvez installer de manière à garantir l'absence de blocage du rendu, de sorte que la page Web se charge comme une fusée sur des rails.

Il a fallu un certain temps pour mettre cela en place, mais ce sera bientôt là [définitivement avant Godot], et je suis vraiment intéressé de voir ce que les concepteurs Web [et les développeurs] sont capables d'en faire.

Conclusion

J'espère que vous ne quitterez pas cet article en pensant que je dénigre les requêtes multimédia CSS juste parce que. Je ne suis pas. Ce serait comme frapper une tomate pour finir dans une salade de fruits. Comme je l'ai dit plus tôt, les requêtes multimédia CSS n'ont jamais été conçues pour la conception Web réactive. Il a été coopté par opportunité, et nous avons tous fait le faux pas d'essayer de l'utiliser pour résoudre tous les problèmes.

Malheureusement, en tant que communauté Web, nous n'avons jamais vraiment réussi à corriger cette erreur initiale en l'améliorant de manière significative ou en proposant une meilleure alternative. Mais hélas, les spectacles doivent continuer, les sites Web doivent être construits et le progrès doit prévaloir. Il est temps pour un changement.

rKit n'est qu'une option et une réponse. Ce n'est pas le premier, et ce ne sera certainement pas le dernier. Mais, à tout le moins, c'est un bon pas dans la bonne direction. Une opportunité de résoudre certains problèmes du passé, puis d'itérer pour résoudre ceux du présent et du futur. Il serait intéressant de voir comment cela correspond au statu quo.

Au final, se tromper n'est pas une fin en soi ; cela devrait être une expérience d'apprentissage. Avec un peu de chance, nous apprendrons à utiliser le bon outil pour le bon travail la prochaine fois. Je veux dire, ce n'est pas parce que vous pouvez faire du vélo sur une route goudronnée que vous devez en apporter un au Nurburgring. Apportez une Porsche!