Les pré-processeurs tels que Sass nous aident à assouplir nos muscles de développement dans presque tous les domaines de notre CSS. Les variables, les mixins, l'héritage et de nombreuses autres fonctionnalités rendent le codage plus facile et plus concis que jamais.
Alors, qu'en est-il de l'utilisation de Sass pour la conception réactive, ou plus spécifiquement pour les requêtes des médias? Y a-t-il des fonctionnalités de Sass qui se marient particulièrement bien avec les requêtes multimédia? Y a-t-il quelque chose que vous devriez éviter? Rejoignez-moi pour expérimenter et découvrir les réponses.
Comment les fonctionnalités Sass de base fonctionnent-elles avec les requêtes multimédia?
J'ai récemment fait beaucoup d'expérimentation avec Sass et les requêtes des médias pour voir ce qui fonctionne et ce qui ne fonctionne pas. Les résultats sont assez mitigés: certaines choses fonctionnent et d’autres pas. Dans l’ensemble, il n’ya vraiment rien d’impressionnant pour changer complètement la façon dont vous utilisez les requêtes des médias, mais cela vaut toujours la peine de donner quelques exemples qui illustrent la manière dont les deux travaillent ensemble.
Variables à l'intérieur d'une requête multimédia: oui
Notre premier test examine si une variable définie dans Sass est reportée dans le corps d'une requête multimédia. La question est l'une de portée: Puis-je définir une variable en dehors d'une requête multimédia et l'utiliser ensuite dans une requête multimédia?
Il s'avère que cela fonctionne très bien. Notre variable de taille de police générique définit efficacement la taille de la police sur 10px dans la requête multimédia.
Variables en tant que points d'arrêt: Non
Ma prochaine question était de savoir si je pouvais ou non utiliser des variables pour définir mes points d'arrêt. Je ne suis pas sûr que ce soit une bonne idée, mais la question fondamentale était de savoir si c'était possible ou non. Qu'est-ce qui se passe quand j'essaie de faire ça?
Ce n'est apparemment pas une utilisation valide des variables Sass car ce code génère une erreur et ne sera pas compilé. J'ai essayé la même chose dans LESS et j'ai obtenu des résultats également inutiles. Cette fois, il a compilé sans générer d'erreur, mais la valeur n'a pas été correctement reportée.
Extension de l'intérieur d'une requête multimédia: sorte de?
Extension des travaux avec les requêtes des médias, mais il est important de savoir Comment cela fonctionne parce que les résultats pourraient ne pas être ce que vous pensez.
Notre premier exemple utilise @extend comme s'il était destiné à être utilisé. Ici, j'ai dit à la classe errorTwo d'hériter des styles de la classe errorOne et de définir la couleur sur bleu.
De manière prévisible, cela produit exactement le résultat que nous voulons. @Extend ne se soucie pas du fait que ce soit dans une requête multimédia, cela fonctionne de la même manière que partout ailleurs.
Alors que se passe-t-il lorsque nous modifions un peu cette structure et plaçons une partie de notre code en dehors de la requête du média? Ici, j'ai défini les styles pour errorOne et errorTwo en dehors de la requête multimédia, puis j'ai tenté d'utiliser des pratiques d'héritage douteuses en réinitialisant les styles errorTwo dans la requête multimédia via l'extension de errorOne.
Voici le CSS compilé à partir de ce code. L'espoir était que les styles errorOne en dehors de la requête multimédia soient appliqués à errorTwo à l'intérieur de la requête multimédia, mais @extend fonctionnait comme prévu: il combinait les sélecteurs à l'emplacement d'origine et appliquait les styles partagés.
Il est important de noter que le code ci-dessus est très différent du CSS souhaité, qui est présenté ci-dessous. Ici, errorOne et errorTwo sont définis individuellement avec des styles différents, puis lorsque la requête de support prend effet, errorTwo est défini pour correspondre à errorOne avec l'ajout d'un changement de couleur.
Mixins à l'intérieur d'une requête multimédia: oui
Comme avec les variables, nous pouvons déclarer un mixin en dehors d'une requête multimédia et l'appliquer à l'intérieur d'une requête multimédia. Par exemple, ici, j'ai mis en place un mélange de polices avec quelques styles de texte, puis je l'ai appelé dans une requête multimédia.
Lancer une requête multimédia dans un mixage: Non
À partir de là, vous vous demandez peut-être si vous pouvez réellement transformer une requête multimédia en un mixin, puis transmettre des arguments lorsque vous souhaitez l’implémenter. Autant que je sache, il n'y a aucun moyen de faire cela avec Sass, LESS ou Stylus.
Imbrication de requêtes multimédia
Jusqu'ici, nous n'avons pas eu de grandes surprises. Pour la plupart, tout fonctionne à peu près comme prévu, à l'exception peut-être des points d'arrêt n'acceptant pas les variables. Notre prochain sujet d’exploration est une fonctionnalité intégrée à Sass qui a été spécialement créée pour les requêtes de média: imbrication.
Sass vous permet d'imbriquer tout type de code. Ce n'est certainement pas une obligation lors du codage avec Sass, mais la fonctionnalité est présente si vous le souhaitez. Par exemple, supposons que nous voulions une méthode plus concise pour écrire le code CSS suivant:
Avec Sass, nous pouvons éviter de créer un bloc de déclaration séparé et imbriquer les styles de survol à l'intérieur de la classe de boutons.
Cette même logique peut être utilisée pour appliquer des requêtes multimédia à des éléments spécifiques. Au lieu de créer une section dédiée incluant toutes vos requêtes multimédia, vous pouvez toutes les imbriquer et les associer ainsi aux styles qu'ils modifient. Voici un exemple:
Avantages et inconvénients des requêtes de média imbriquées
L'idée derrière les requêtes de média d'imbrication est une idée décente, du moins en surface. Comme je l'ai mentionné ci-dessus, les requêtes des médias sont collées dans les styles d'origine qu'elles modifient, ce qui est un schéma d'organisation décent. Cela réduit également la répétition nécessaire des sélecteurs, ce qui est une bonne chose.
Malheureusement, à mon avis, ces avantages sont compensés par le fait que cela produit du code compliqué. Ce problème se présente clairement lorsque votre code devient plus complexe. Nous avons ici deux éléments différents, chacun tirant parti de la fonctionnalité de requête multimédia imbriquée.
Le Sass ci-dessus sera compilé dans le CSS ci-dessous. Comme vous pouvez le constater, chaque requête multimédia est écrite individuellement et apparaît juste après les styles auxquels elle est associée.
Si vous travaillez avec responsive design, vous avez probablement immédiatement des problèmes avec la manière dont ce code est compilé. Pour voir ce que je veux dire, voyons comment je le coderais à la main en CSS pur si je le faisais à la main.
Appelez-moi fou, mais je pense que c'est supérieur à ce que Sass a craché. J'ai un réel problème avec le fait que des déclarations de requête multimédia identiques ne sont pas combinées. Nous voyons ici qu'il n'y avait aucune raison d'écrire la requête 300px deux fois, alors que nous pouvions simplement l'écrire une fois et jeter les deux blocs de déclaration à l'intérieur.
De plus, l'organisation ici est plus propre et plus facile à suivre. Généralement, lorsque vous travaillez avec des requêtes multimédia, vous devez apporter beaucoup de modifications. Avec la méthode Sass, vous êtes obligé de parcourir votre code et de trouver chaque élément à modifier. Si votre fichier SCSS contient des centaines de lignes de code, cela pourrait être brutal. Avec CSS à la vanille, nous pouvons regrouper toutes nos requêtes multimédia au même endroit et les ajuster ensemble.
Directives de contrôle
Bien que je ne sois pas particulièrement enthousiasmé par les résultats obtenus en mélangeant Sass avec des requêtes de médias, un domaine qui, à mon avis, mérite une exploration, concerne les directives de contrôle. C'est un sujet délicat car, si vous n'êtes pas programmeur, les directives de contrôle semblent beaucoup trop complexes pour CSS. Gardez juste à l'esprit avant de me laisser un commentaire désagréable que je suis en train de jouer avec quelques possibilités ici
Compte tenu de la nature des requêtes multimédia, je pense que les directives de contrôle pourraient contenir des fonctionnalités intéressantes. Après tout, une requête multimédia ressemble beaucoup à une instruction if: si viewport = x, do y. En utilisant du Sass sophistiqué, nous pouvons aller beaucoup plus loin. Voyez si vous pouvez comprendre ce qui se passe ici.
Fondamentalement, j'ai configuré un élément avec une largeur qui réduit sa largeur de 100 pixels pour chaque requête multimédia. Ensuite, j'ai mis en place un mixin qui change la couleur de l'élément si sa largeur est inférieure à un certain point.
Cette technique peut être utile pour beaucoup de choses différentes, telles que le remplacement d'une police de script par un élément standard lorsque la taille devient trop petite. Voici une version légèrement modifiée qui surveille jusqu'à ce que l'objet ait une largeur inférieure à 400 pixels, puis définit la hauteur à la moitié de la largeur.
Voici comment cela se compile. Comme vous pouvez le constater, la hauteur n'a pas changé lors de la première requête de média, car sa largeur n'est pas inférieure à 400 px. Sur la deuxième requête de média, si la largeur est de 300 pixels, la hauteur a été modifiée à 150 pixels. Le bon côté de ceci est que le code compilé est concis et n’a aucune de la logique folle d’en haut.
Conclusion
J'aurais vraiment aimé avoir présenté une discussion sur le fait que Sass est un changeur de jeu en ce qui concerne les requêtes des médias, mais pour le moment, je pense que l'inverse est vrai. Il est probablement préférable d'éviter tout ce qui est Sass dans la mise en œuvre des requêtes multimédia. N'hésitez pas à utiliser des variables et des mixins comme d'habitude (acceptez dans la déclaration de point d'arrêt), mais faites attention à ce que l'héritage ne fonctionne pas comme prévu et réfléchissez-y à deux fois avant d'imbriquer une requête multimédia, car à long terme, vous créez probablement plus de travail pour vous-même. .
Les directives de contrôle, qui sont assez avancées et offrent des possibilités fascinantes lorsqu'elles sont combinées à des requêtes de support, constituent une exception à laquelle je peux penser.
Avez-vous essayé d'implémenter Sass en conjonction avec des requêtes de médias? Avez-vous découvert des astuces intéressantes ou avez-vous décidé d'éviter complètement la pratique? Faites le nous savoir dans les commentaires.