Variables CSS natives ajout bienvenu ou énorme erreur?

La communauté du développement Web a récemment reçu de grandes nouvelles. Bien que pas encore dans les nightlies, les expérimentations sont à nouveau en cours, ce qui, en cas de succès, nous fournira un support natif pour les variables CSS, les mixins et les modules dans les navigateurs. La question est, cependant, est-ce une bonne chose?


Avantages

  • Maintenir les projets plus facilement
  • Écrire moins de "code"
  • Intégration plus simple avec JavaScript
  • Mettre à jour les paramètres et paramètres du site avec un seul changement de valeur

Les inconvénients

  • CSS devrait-il être compliqué?
  • Barrière d'entrée supérieure pour les concepteurs
  • La syntaxe proposée actuellement semblera trop déroutante pour certains

Comment ça marche?

Avant de progresser, gardez à l'esprit que ces développements n'en sont encore qu'au stade expérimental. Ils n'ont encore été implémentés dans aucun navigateur.

Si vous êtes un peu familiarisé avec les préprocesseurs CSS, tels que Less ou SASS, vous aurez une compréhension de base de ce à quoi s'attendre de ces ajouts. (Cela dit, la syntaxe proposée est malheureusement un peu différente.) À l'avenir, vous aurez la possibilité de créer des variables (globales et locales) et des mixins, que vous pouvez considérer comme une collection de styles pouvant être facilement supprimés. référencé.

Ce qui a pris si longtemps?

Pour autant que je m'en souvienne, la communauté réclamait des variables CSS. Alors, quel était le problème? En un mot: désaccord. En fait, en 2008, Webkit travaillait avec cette fonctionnalité - même au point de la mettre en place dans les nightlies - bien que la proposition soit bloquée peu de temps après. Beaucoup ont estimé que transformer le CSS en un plus comme un programmeur le langage n'introduirait que de la frustration; certains ont même pensé que cela pourrait confondre les concepteurs. Par exemple, si la couleur primaire de votre projet est stockée dans une variable - probablement en haut de votre feuille de style - le concepteur devra alors faire référence à deux emplacements..

 @myColor: rouge;
 / * Moins de syntaxe * / #someElem color: @myColor; 

Bien que cet argument soit valable dans une certaine mesure, il n’a pas beaucoup de poids. La plupart des designers maintiennent un ensemble de couleurs du site en haut de leur feuille de style, qu'ils utilisent comme référence. L'introduction de variables pour contenir ces valeurs est une solution logique.


La syntaxe proposée

Les fans de Less ou de SASS seront habitués à définir des variables telles que:

 / * Moins * / @primary_color: rouge; / * SASS * / $ primary_color: rouge;

La syntaxe proposée complique un peu les choses en rendant les variables typées. Par exemple:

 / * Declaration * / @var primary_color couleur rouge; / * Utilisation * / body color: var (primary_color); 

À noter

  • Toutes les variables sont préfacées par @var
  • Les variables sont tapées. Notez l'utilisation de la Couleur mot-clé dans le code ci-dessus.
  • Pour accéder à la valeur de cette variable, nous utilisons le var fonction et passe le nom de la variable.

Je dois admettre que cela semble un peu redondant d’utiliser le @var directif. La syntaxe utilisée par SASS et Less semble plus appropriée et plus propre. @myVar est plus succinct que @var myVar.

Les types de variables sont un ajout bienvenu, d'autre part.

Les variables sont tapées. Chaque type de valeur primitive, chaque propriété et quelques types de commodité supplémentaires existent. Cela nous permet d’exposer les nouveaux éléments CSSOM sur eux: document.styleSheets [0] .vars ['primaire_color']. alpha = .5;
-- xanthir.com

Variables locales

Les variables auront également la possibilité d’être étendues à une boîte de déclaration, via l’utilisation de @local directif. Cela peut être utile lorsqu'une variable ne doit être utilisée qu'une ou deux fois dans un projet..

 .box / * Declaration * / @local box_gradient background-gradient linéaire (haut, noir, blanc); / * Usage * / background: var (dégradé de boîte); 

Mix-ins

Les mix-ins peuvent être incroyablement utiles. En fait, nous avons abordé le processus de création d’un fichier de classe de mixages récemment sur Nettuts +. Vous pouvez lire à ce sujet ici, tout en gardant à l'esprit que la ou les techniques présentées dans cet article reposent sur le préprocesseur Less. Encore une fois, les nouvelles expériences utilisent une syntaxe légèrement différente.

 / * Moins * / .border-radius (@radius: 3px) -webkit-border-radius: @radius; -moz-border-radius: @radius; border-radius: @radius;  / * SASS * / @mixin border-radius ($ radius: 3px) -webkit-border-radius: $ radius; -moz-border-radius: $ radius; border-radius: $ radius;  / * Et éventuellement la solution native ?? * / @mixin border-radius (rayon de longueur 3px) -webkit-border-radius: var (rayon); -moz-border-radius: var (rayon); border-radius: var (rayon); 

Notez les similitudes entre SASS et la solution native proposée pour mixins. Cela est dû au fait que les membres de l’équipe SASS servent de conseillers.

Nidification

Comme vous le savez peut-être, Less et SASS vous permettent de nid sélecteurs. Cela peut réduire considérablement la taille de vos feuilles de style, car cela élimine le recours au même sélecteur à plusieurs reprises..

 / * La manière actuelle * / #content … #content p … #content pa … #content pa: hover … / * Less et SASS * / #content … p … a … & : survol … / * Et nativement ?? * / #content … @this> p … @this> a … @this: survol …

Alors que la syntaxe proposée est plus verbeux, à son crédit, il a une belle syntaxe semblable à celle de OO, ce qui fera que beaucoup de développeurs se sentiront comme chez eux.

Mais rappelez-vous - tous les concepteurs ne sont pas des développeurs.

Noms de noms

Par défaut, dans Less, toutes les variables sont globalement globales. En conséquence, il devient difficile de distribuer du code car les noms de variables existants peuvent être écrasés. La solution native potentielle consistera à implémenter des modules, ou espaces de noms. Ils peuvent alors être inclus dans un bloc en ajoutant le @utilisation directif.

 @module Site @var primary_color color # 292929; @var secondary_color couleur blue; @mixin border-radius (rayon, longueur 3px) … border-radius: 3px;  / * Utilisation incorrecte * / body color: var (primary_color); // Le nom de la variable n'est pas défini / * Correct * / body @use Site; couleur: var (primary_color); // # 292929 (Works)

Conclusion

Comme indiqué au début de cet article, la documentation indiquée ci-dessus en est encore au stade expérimental. Il est possible - probablement même - que la syntaxe change en fonction de votre retour d'information. Alors allons-y. Est-ce que l'idée de variables natives dans mixins dans votre CSS vous excite… ou vous fait peur?

Moi? Eh bien, je suis pour. Je pense que la syntaxe proposée pourrait nécessiter un peu de travail, car elle effraiera sans aucun doute les concepteurs parmi nous. Cela dit, si la syntaxe a été un peu simplifiée, je suis à 100%. Et vous?