Les variables CSS prises en charge par la bêta de Chrome
Jusque-là, seul Firefox prenait en charge les variables CSS, mais depuis le début de l’année, le rythme s’est accéléré. Après Safari qui ajoute cette fonction avec la version 9.1 sur OS X et iOS (actuellement en bêta), c’est Chrome qui l’a intégrée dans sa bêta. La version 49 qui sera finalisée dans les prochaines semaines et distribuée automatiquement à tous les utilisateurs permet également d’en bénéficier.
Les variables CSS permettent aux concepteurs de sites web de mémoriser un élément de mise en page, comme une couleur ou encore une taille. On définit la variable à un endroit donné et on peut ensuite l’utiliser dans tout le site, mais au lieu de dupliquer la valeur partout, on utilise le nom de la variable. Avantage évident, si on veut changer cette valeur — par exemple, si on voulait passer MacGeneration en violet —, il suffit de la changer une seule fois, au moment où on enregistre la variable. Le changement sera alors répercuté sur tout le document.
Les développeurs utilisaient déjà des variables en CSS, mais ils exploitaient des langages intermédiaires, comme le SASS ou le LESS. Au moment de la publication, ils devaient les convertir en fichiers CSS standard. Avec les variables CSS natives, il n’est plus nécessaire d’utiliser un autre langage et autre avantage, on peut exploiter ces variables sur le site lui-même. Google a mis en place un petit exemple (il fonctionne dans les dernières versions de Chrome et de Firefox, mais bizarrement, pas dans les bêtas de Safari) où le visiteur peut changer l’interface de la page. Avec une petite dose de JavaScript, on peut créer une interface pour changer la couleur, mais aussi le nombre de colonnes et l’espace entre chaque élément.
Pour que les variables CSS puissent vraiment se généraliser, il faudrait que tous les navigateurs le prennent en charge. L’ajout de Chrome est une étape essentielle, d’autant que le navigateur de Google est toujours en tête des parts de marché. Néanmoins, il faudra encore patienter que la version 49 soit disponible partout et notamment sur Android, ce qui ne sera pas si simple. Et puis il manquera encore un navigateur majeur : Microsoft ne semble pas vraiment intéressé pour ajouter ces variables à Edge. Peut-être que l’arrivée de Chrome changera les choses ?
![L’iPhone XS enregistre la nature déchaînée [màj : avec le making of]](https://cdn.mgig.fr/2019/04/mg-51fcf80b-ee2c-4ee1-b768_accroche.jpg)
![Free ressort la fusée… pour une nouvelle annonce ? [MàJ]](https://cdn.mgig.fr/2019/04/mg-d380f426-0866-4fa7-afeb_accroche.jpg)
Sans parler du fait que SASS et LESS font beaucoup plus de choses que des variables ... Le calc() en plus du var() est néanmoins intéressant. L'avantage (ou l'inconvénient, à discuter) est que SASS et LESS peuvent être pré-compilés et donc peut-être plus rapides à éxécuter sur les navigateurs et fonctionnent donc aussi sur tous les navigateurs (puisque la CSS produite n'est que de la CSS classique).
Merci pour cette info.
@pierrot99 :
Je ne sais pas ce que ça donne en pratique, mais en théorie, ces nouveautés sont aussi rapides que le CSS "de base"…
Exactement. SASS ou SCSS apportent beaucoup plus que juste des variables. C'est du CSS pour les développeurs (CSS étant de mon point de vue un truc pour designerpsychopathe et comme bootstrap, foundation et tous les framework passent tous par là, ils ont un bel avenir.
@@Ast2001
"CSS étant de mon point de vue un truc pour les designerpsychopathe..."
Je trouve cette remarque un peu condescendante.
De mon point de vue, CSS est surtout un truc qui permet de faire des sites légers avec le minimum de ressources à exploiter pour la machine.
Pour écrire des css "comme demain", il y'a aussi postcss-cssnext
\o/
On pourra donc s'en servir d'ici de nombreux mois, quand ça sera considéré comme intégré dans la majorité des navigateurs utilisés. D'ici là, je retourne à mon sass...
Je ne vois pas trop l'intérêt non plus, comme c'est dit plus haut, les pré processeurs CSS ( SASS ou LESS ) couplés à Gulp ou Grunt sont bien plus intéressants. Ils permettent de gérer les compatibilités avec les anciens navigateurs, d'utiliser des fonctions et bien d'autres choses.
On avance quand même dans le bon sens avec un CSS qui ressemble de plus en plus à un langage de prog.
L'interet: c'est standard => pas de dependance d'un systeme qui peut etre fermé ou abandonné a tout moment!
Et le jour ou les variables CSS sont généralisées, les sur-langages traduisent alors directement en variables CSS...
Faut aussi comprendre que les implementation de ces surlangage ont un cout, soit coté serveur, soit coté client. Coté client, ça demande de faire tourner du javascript avant d'afficher => ça consomme du temps et de l'énergie et rien de garantit que l'affichage se fait.
Coté serveur, le résultat est garanti, mais ça surcharge le serveur a chaque requête!
Reste la solution statique: une fois le projet terminé le "compilateur" sort un site avec uniquement du HTML et CSS standard, mais alors on perd la "dynamicité" des surlangage.
Faut donc comprendre sur quoi on travaille, avec quels outils et quel est le cout de chaque option.
Si l'objectif c'est de faire un site comme on fait de la mise en page, faut passer par un soft qui permet de dessiner les pages sans taper le moindre code.
@iPoivre :
Le problème est qu'un webdesigner n'est pas forcément programmeur et inversement (surtout inversement ^^)
@Strix :
Dans une agence organisée correctement, le webdesigner n'a pas à toucher au code, contrairement à l'intégrateur qui lui est censé avoir la base de la logique de programmation.
Je ne demande pas que le CSS devienne un langage à part entière, mais plutôt qu'il se dynamise.
@iPoivre
«Je ne demande pas que le CSS devienne un langage à part entière, mais plutôt qu'il se dynamise.»
CSS n'est pas un langage dans ce sens, c'est du balisage déclaratif qui décrit l'aspect. On peut le "parametriser", pour éviter les redondances et les erreurs de répétition (couleur, graisse, type de trait,...), mais de la a en faire un vrai langage impératif ... y a même pas les bases!
Faut rappeler que HTML c'est de l'hypertext: un site web ça se conçoit comme un livre, pas comme un jeu video ou une application graphique (pour ça y a SVG et Canvas)!
Faut aussi comprendre un truc: le HTML et le CSS sont des standards!
Les navigateurs doivent se conformer aux standards et représenter les données de manière similaires: les standards sont la pour une bonne raison!
Si les navigateurs WEB interprètent mal le contenu HTML+CSS, faut mettre la pression sur les éditeurs des navigateurs, faut pas essayer de contourner le standard pour l'adapter au navigateur!
Sinon, autant laisser tomber le HTML et produire que des applications propriétaires alimentées par des serveurs...
Ce que l'on écrit en HTML et CSS doit l'être par rapport au standard pas une interprétation fantaisiste d'une version spécifique d'un afficheur: parce que le HTML+CSS peut être affiché par un navigateur, mais aussi par n'importe quel programme capable d'interpréter le HTML+CSS.
Et le contenu HTML est fait pour exister sans date de péremption: un site WEB peut exister pendant plus de 40 ans et ses informations rester pertinentes et consultables tout ce temps, faut penser a ça!
@iPoivre, t'es un poil contradictoire :) je cite :
"On avance quand même dans le bon sens avec un CSS qui ressemble de plus en plus à un langage de prog."
"Je ne demande pas que le CSS devienne un langage à part entière, mais plutôt qu'il se dynamise."
Le CSS doit faire ce qu'on lui demande, styliser une page web, point. Les variables CSS sont la pour apporter plus de souplesse sur le theming live d'un site (via JavaScript par exemple), ou d'autres applications surement utiles en front dont je n'ai pas encore idée.
Les variables CSS peuvent parfaitement être couplées avec un pré ou post processor, qui sont là uniquement pour améliorer la productivité, la souplesse d'écriture, prefix navigateurs etc.
@Strix :
Non, pas surtout inversement :
Un développeur qui se met au design risque juste de faire quelque chose de moche, tandis qu'un designer sans de solides bases de programmation qui se met au dev *risque* juste de faire un site qui ne marche pas !
@marc_os
«Un développeur qui se met au design risque juste de faire quelque chose de moche, tandis qu'un designer sans de solides bases de programmation qui se met au dev *risque* juste de faire un site qui ne marche pas !»
En fait le pire que puisse faire un graphiste qui se met a la programmation c'est plutot un site qui marche approximativement, surtout pour un navigateur en particulier (ref la domination d'IE), et bourré de failles majeures de securité...
Faut aussi rappeler que le dev web se fait avec 5 langages ayant 4 paradigmes different et chacun une syntaxe differente:
- PHP => procedurale pseudo-orienté objet
- javascript => orienté objet à prototype
- HTML => balisage declaratif
- CSS => balisage declaratif
- SQL => declaratif + procedural
Plus un ensemble de frameworks et librairies, dont beaucoup redondant et ayant chacun une approche specifique souvent incompatible avec les autre...
Deja la majorite des personnes impliquées ne comprennent pas la notion MVC, et ont du mal a comprendre que le HTML ne programme pas une presentation mais definit une semantique indexable, elle meme dissociee du contenu.
Seul le CSS programme une representation statique...
Et Javascript ne sert pas a animer des page web, mais a attribuer des comportements et des proprietes parametrables a des objets contenus par l'objet page WEB...
bref...
"En fait le pire que puisse faire un graphiste qui se met a la programmation c'est plutot un site qui marche approximativement, surtout pour un navigateur en particulier (ref la domination d'IE), et bourré de failles majeures de securité..."
Un graphiste qui se met à la programmation et se forme comme il se doit fera des bon sites. Un sportif qui se met à la cuisine et travaille fort deviendra un bon chef.
Le problème vient des développeurs qui se pensent graphistes et des graphistes qui se pensent développeurs. Mais ça c'est autre chose.
@AirForceTwo
N'importe qui se mettant a étudier sérieusement la programmation pour devenir programmeur (enfin bon y a quand même une forme d'esprit tortueux chez les developpeurs dont tout le monde n'est pas affligé et il subsiste un doute que ce soit totalement acquis) deviendra programmeur.
Si c'est un cuisinier il sera ainsi cuisinier et développeur, s'il est graphiste il deviendra graphiste et développeur.
Le problème c'est même pas les gens qui se pensent autre chose que ce qu'ils sont, mais ceux qui estiment qu'ils peuvent faire aussi bien, sans vraie formation (voire sans formation du tout), que ceux qui sont correctement formés... Le dénigrement (sous categorie du mepris et expression de la megalomanie) est la marque de l'incompétence.
Apres, ce que dit @marc_os est aussi rationnel: au pire le developpeur qui n'a pas de formation de graphiste fera un site moche, sans que ce soit plus dramatique. L'inverse est plus grave en terme de conséquences.
Je rajouterai ici, qu'en plus le développement HTML, nécessiterait en principe quelques connaissances en linguistique, puisque l'on traite avant tout d'une sémantique textuelle.
@mat-u :
Tout ce que je veux dire c'est que les bases du CSS sont vieillissantes et de moins en moins adaptées aux technologies actuelles.
Tu parles de theming live d'un site, chose qui devrait se généraliser pour améliorer de plus en plus l'expérience multiplateformes. Et cela passe par une dynamisation du CSS, qui est encore aujourd'hui trop statique et trop compliqué à modifier en live.
Le theming live par Javascript n'est pas une solution viable car trop compliquée à mettre en place et trop lourde à utiliser.
Ces variables sont un bon début, mais elles devraient pouvoir servir de lien avec le Javascript et être modifiées dynamiquement côté client selon l'appareil utilisé.