Écrivez de meilleurs CSS en empruntant des idées aux fonctions JavaScript — Smashing Magazine

J’aime penser à l’écriture CSS comme à des fonctions d’écriture qui décrivent comment les mises en page réagissent aux changements. Lorsque nous oublions les principes d’écriture d’une bonne fonction, voici une partie de ce qui peut arriver :

• Nous perdons du temps.
  Lorsque nous devons nous soucier des effets secondaires, les changements prennent plus de temps.
• Nous créons des erreurs.
  Mon exemple préféré est une boutique en ligne où les boutons « Acheter » ont été masqués en raison d’une mauvaise utilisation des unités de fenêtre.
• Nous créons moins de fonctionnalités.
  Lorsque les changements sont effrayants et prennent du temps, ils ne se produisent souvent pas.

Voyons comment nous pouvons emprunter les meilleures pratiques et idées de l’écriture de bonnes fonctions JavaScript pour écrire du CSS facile à utiliser, sans effets secondaires indésirables et résistant au changement.

Éviter les effets secondaires indésirables

Lorsque vous changez quelque chose dans votre système, vous ne devriez pas changer autre chose par surprise. C’est aussi vrai pour CSS que pour les fonctions JavaScript.

Regardons cette icône de flèche encerclée comme exemple :

Ça a l’air bien, mais disons que nous voulons une icône de flèche plus étroite :

Maintenant, le cercle contenant est écrasé ! Ceci est un exemple d’effet secondaire indésirable. L’utilisation d’une flèche plus étroite ruine la forme du cercle.

Si nous inspectons l’élément dans DevTools, nous pouvons voir que la forme du cercle contenant dépend de la taille de l’icône intérieure et le rembourrage autour de l’icône.

Idéalement, l’icône intérieure ne devrait pas modifier la forme du cercle qui l’entoure. Voici une démonstration de la façon de réparer l’icône écrasée :

Il y a deux améliorations dans cet exemple :

1. Les dimensions du conteneur ont été isolées du contenu.
   De cette façon, nous pouvons utiliser différentes icônes sans encombrer le conteneur.
2. La taille du conteneur a été séparée de l’emplacement de l’icône.
   Comme nous utilisons Flexbox pour centrer l’icône horizontalement et verticalement, la position de l’icône ne sera pas modifiée lorsque vous redimensionnerez le conteneur.

Les améliorations de cet exemple peuvent ne pas convenir à tous les cas d’utilisation. Par exemple, si vous avez besoin que la forme et la taille du conteneur changent avec l’icône à l’intérieur, la version « avant » du code pourrait vous convenir mieux.

Quand je dis éviter les effets secondaires indésirables, le mot-clé est « junk ». Certains effets secondaires sont souhaitables ! Par exemple, si j’ai trois paragraphes et que j’ajoute plus de texte au premier, j’aimerais que le reste du contenu lui fasse de la place lorsque je fais défiler la page.

Je suppose que ce que je veux dire, c’est que mon but ici n’est pas de dicter une façon précise de faire les choses. J’espère que vous considérerez les effets secondaires (anticipés et autres) que vous pourriez rencontrer, puis que vous choisirez un plan d’action qui répond à vos besoins. Trop souvent, nous recherchons des solutions publiées aux problèmes des autres, que ce code crée ou non plus de problèmes qu’il n’en résout.

écrire un code pratique

Les paramètres de fonction en JavaScript offrent un moyen pratique de définir les entrées que vous souhaitez contrôler. C’est comme décider quelles télécommandes mettre sur un téléviseur.

Nous pouvons écrire du CSS qui est tout aussi facile à contrôler. Pour cela, voyons comment éviter deux problèmes que l’on peut rencontrer lors de l’écriture d’une fonction JavaScript :

• Trop de paramètres.
  Plus de configurations créent plus de frais généraux et deviennent difficiles à utiliser.
• Il n’y a pas assez de paramètres.
  Moins de paramètres peuvent ne pas fournir un contrôle suffisant pour vos cas d’utilisation.

Trop de paramètres

Supposons que nous ayons une fonction JavaScript qui allume et éteint une ampoule. Si notre objectif est de rendre la fonction aussi facile à utiliser que possible, nous voudrions probablement un paramètre qui détermine l’état de l’ampoule.

Voici une fonction pratique et facile à utiliser :

switchLightbulb(ON);

Comparez cela à cette fonction douloureusement complexe :

switchLightbulb(getConnectedWires, isCompleteCircuit, setUpBattery, batteryStatus, isUsingWallOutlet, hasPowerOutage, isElectricityBillPaid, etc);

Dans ce cas, on veut juste allumer l’ampoule, mais quand on a trop de paramètres, on a trop d’étapes à réaliser. Bien sûr, tous ces autres paramètres sont clairs et peuvent être utiles dans certaines situations. Ou peut être pas. Cependant, ils sortent du cadre de la finalité essentielle de la fonction : basculer entre un ON état et un OFF État.

Une idée similaire s’applique au CSS. Disons que nous avons une carte avec une image, un titre, un corps de texte et un bouton. Nous voulons changer facilement la largeur de la carte.

Ce one-liner est facile à utiliser et à comprendre :

.card {
  max-width: 300px;
}

Une approche beaucoup moins pratique consiste à définir explicitement la max-width décennie .card composant:

.card-image {
  max-width: 300px;
}
.card-title-text {
  max-width: 300px;
}
.card-body-text {
  max-width: 300px;
}
.card-button {
  max-width: 300px;
}

Si nous voulons changer la taille de la carte dans le deuxième exemple, nous devons faire quatre mises à jour pour effectuer un changement. Pour notre cas d’utilisation, le premier exemple est beaucoup plus pratique à utiliser.

trop peu de paramètres

Maintenant que nous avons vu ce qui peut mal se passer trop paramètres voyons ce qui peut arriver avec très peu. Supposons que nous ayons une fonction qui définit la vitesse d’une voiture et son angle de virage en degrés. Nous aurons besoin d’au moins deux paramètres pour ces propriétés.

Notre fonction pourrait ressembler à ceci :

setCarState({ speed: 60, turnAngleDegrees: 2 });

On pourrait essayer d’être plus concis et combiner les paramètres :

setCarState({ speedAndTurnAngle: 60 });

Bien sûr, c’est concis, mais c’est aussi terrifiant à utiliser. Imaginez une voiture où l’accélération fait aussi tourner le volant ! Nous ne voulons certainement pas regrouper la vitesse et l’angle dans un seul paramètre car ce paramètre ne fournit pas suffisamment de contrôle et produit des effets secondaires alarmants.

En CSS, il existe des cas similaires où nous voulons contrôler un paramètre sans en affecter un autre. Par exemple, nous avons peut-être un autre composant de carte, cette fois avec une photo, un nom, une courte biographie et un bouton « Lire la suite », et nous voulons modifier la largeur de la carte sans affecter les dimensions de la photo.

Malheureusement, le max-width L’approche que nous avons utilisée précédemment dans le conteneur de cartes fournira très peu de paramètres pour nos besoins :

.card {
  max-width: 300px;
}

Comme nous l’avons noté précédemment, les éléments enfants de la carte s’adapteront à la largeur du conteneur de carte jusqu’à 300px. Cela inclut l’image, qui rétrécira à mesure que la largeur du conteneur diminue ensuite. 300px.

Ce dont nous avons besoin, c’est d’un paramètre supplémentaire pour la photo :

.card {
  max-width: 300px;
}
.photo {
  width: max(150px, 50%);
}

Puisque nous voulons changer la largeur de la photo quelle que soit la carte, nous avons besoin de suffisamment de paramètres pour avoir ce niveau de contrôle. Dans ce cas, cela signifie donner à la photo une largeur différente de celle de la carte en définissant cette largeur dans une classe du champ photo.

Que vous ayez besoin de plus ou moins de paramètres, l’important est considérez votre cas d’utilisation.

Écrire des styles résilients

Lors de l’écriture d’une fonction, il est utile de se demander, Qu’advient-il de la sortie lorsque l’entrée change ?

Nous pouvons faire des variations de cette même question en CSS, comme :

• Si la largeur d’un élément est contrainte, qu’advient-il de sa hauteur ?
• Si un élément glisse sur le côté de la fenêtre, qu’advient-il de l’accessibilité de la page ?
• Si l’utilisateur passe de la souris au toucher, qu’advient-il des interactions au survol ?

Disons que nous avons une mise en page avec trois cartes disposées horizontalement dans un conteneur.

Ensembles CSS max-width: 900px dans le conteneur, et chaque carte a un petit reniflard avec padding: 5vw. Cela peut sembler bon en surface, mais il y a un problème : le conteneur a une limite supérieure alors que le rembourrage n’en a pas. À mesure que l’écran s’élargit, le contenu est écrasé.

Les solutions possibles incluent :

• Utiliser des points d’arrêt de fenêtre ou de conteneur pour contrôler le rembourrage,
• Utilisation du CSS min() fonction pour définir une limite supérieure sur le remplissage, ou
• Utiliser des unités fixes, comme des pixels, qui ne grandiront pas indéfiniment avec la fenêtre.

Ce que ces solutions ont en commun, c’est qu’elles tiennent compte de ce qui se passe lorsque la largeur de la fenêtre d’affichage change. De même, nous pouvons éviter de nombreux problèmes CSS en considérant la mise en page comme une sortie et en anticipant ce qui pourrait arriver lorsque les entrées changent.

Ahmad Shadeed a un grand nom pour cette technique : CSS défensif. L’idée est que nous pouvons « pérenniser » les styles en les considérant comme des entrées qui génèrent une interface utilisateur et en anticipant les situations qui réduiraient la convivialité de la sortie.

conclusion

Coder une mise en page ne consiste pas à mettre des éléments sur une page, mais à décrire comment ils réagissent au changement. Pour cette raison, il est risqué de traiter CSS comme des constantes au lieu de fonctions.

Heureusement, les mêmes idées qui nous aident à écrire de bonnes fonctions peuvent nous aider à écrire de bons CSS, à savoir :

• Évitez les effets secondaires indésirables.
• Utilisez les bons paramètres.
• Considérez comment les entrées modifient les sorties.

Qu’est-ce qui relie ces idées est une question que j’espère que vous vous poserez la prochaine fois que vous écrirez du CSS, Comment cette conception devrait-elle réagir au changement ?

Lecture supplémentaire sur SmashingMag

(jj, et k, le)