dotCSS 2014

Vendredi après-midi avait lieu la première conférence dotCSS. Comme d'habitude pour les dot conferences, le lieu était magique. Cette fois-ci, au théatre des variétés, sur les grands boulevards.

La demi-journée a été riche en informations autour de CSS, depuis sa création, jusque son futur, les choses bizarres qu'on peut faire avec, les outils qui tournent autour et son intégration au sein d'une équipe aux compétences diverses.

Le talk d'ouverture était de Daniel Glazman, co-chairman du W3C. Il a rappellé qu'il était "juste" co-chairman, et pas co-boss. Que ce n'était pas lui qui prenait les décisions finales quand à l'orientation du web, mais qu'il avait plus un rôle d'huile entre les différentes pièces, un facilitateur de débats (souvent houleux).

Le W3C est un consortium de représentant de sociétés privées et des grands acteurs du web, de fabricants de navigateurs, de sites à fort traffic, de fabricant de hardware, etc. Ils se mettent d'accord pour donner un axe de travail pour l'amélioration des technos du web (CSS entre autres). Mais chaque membre a son propre planning, ses propres objectifs et le rôle du W3C est de réussir à trouver un compromis qui conviennent à tout le monde. Et parfois, ces consensus donnent quelque chose d'hybride qui ne convient réellement à personne.

Retrospectivement, on peut dire que plusieurs erreurs ont été faites lors de la création de CSS selon ce principe. Par exemple la fusion des marges, le principe du box-model, ou la complexité à réussir à centrer verticalement du texte. Pour leur défense, il faut bien avouer que CSS était initialement prévu pour donner un peu de style à des rapports académiques, à du texte pur et dur, pas à faire des mises en pages complexes dépendantes de la résolution d'écran, de la vitesse de la bande passante et de la densité de pixels comme on lui demande aujourd'hui.

Glazou a terminé par nous présenter, non sans trolls, les prochaines shiny features de CSS. Les tant attendues variables arrivent enfin ! Sauf que c'est pas exactement des variables, ce sont des Custom Inherited Properties qui ne sont donc pas globales, mais qui cascadent depuis un élément parent vers ses descendants.

Pour aligner du texte verticalement, on a le fantastique flexbox qui permet de faire les mises en pages les plus folles au prix d'une syntaxe complexe avec X propriétés différentes pouvant prendre Y valeurs possibles.

Et puis, il y a le nouveau sélecteur :matches() qui est plus du sucre syntaxique et qui permet de simplifier l'écriture de certains sélecteurs (par exemple :matches(section, article) :matches(h1, h2) plutôt que d'écrire section h1, section h2, article h1, article h2.

Dans le même ordre d'idées, des améliorations à :nth-child() sont dans le pipe, pour pouvoir préciser un sélecteur afin de ne compter que certains éléments.

On parle aussi d'une syntaxe proposée pour pouvoir sélectionner un élément autre que celui qui se trouve en bout de chaine d'un sélecteur. Aujourd'hui on peut écrire div p pour sélectionner tous les paragraphes dans des divs, mais on ne peut pas écrire de sélecteur pour sélectionner tous les divs qui contiennent des paragraphes.

Mais les modifications sans doute les plus importantes à mon sens seraient de pouvoir avoir accès au moteur de parsing CSS, en read-only, depuis Javascript. Ne plus être obligé de reparser les règles CSS à la main pour calculer la taille d'une font en pixels ou la valeur d'une couleur à un point x au milieu d'un linear-gradient. Puisque le parser CSS a déjà fait ce travail, il serait bon qu'on puisse y accéder directement.

Une très bonne intro, aussi bien tournée vers le passé que le futur, pour commencer ces conférences dotCSS !

Bridging the gap between developers and designers

Le second speaker faisait parti de ces nombreux speakers français qui ont fait l'effort de présenter en anglais pour l'auditoire en grande partie non-francophone. Kaelig travaille aujourd'hui au NY Times après avoir bossé au Guardian.

Sa présentation n'était pas réellement technique, mais portait plus sur la manière de faire en sorte que les développeurs front et les designers travaillent mieux ensemble. Il est indispensable pour lui que cela passe par un partage d'un langue commune. Que quand un designer indique que le header doit être "gris clair", il n'y ai pas d'ambiguité sur quel gris il faut utiliser.

Pour cela, ils utilisent une feuille recensant toutes les couleurs utilisées dans leur site, en donnant un nom à chacun (du type neutral-1, corporate-color, etc) et la valeur hexadécimale qui va avec. En faisant ainsi, designers et développeurs parlent bien toujours des mêmes couleurs et se sont créés un dictionnaire de mots partagés. Le nom de la couleur que les designers emploient à l'oral pour discuter entre eux est aussi le nom de la variable dans les fichiers CSS. La communication entre les deux mondes est alors grandement simplifiée.

Ils appliquent le même principe pour les fonts, en créant une matrice des différentes combinaisons de font/size utilisées, en les réferencant par leur fonction comme par exemple heading-3 ou maintext-2. Ici aussi, le vocabulaire des designers a été uniformisé, et les mêmes termes sont utilisés dans les feuilles de styles, ce qui aide en plus à développer directement en peer programming designer/developer dans le browser.

Pour les breakpoints RWD, même histoire, ils ont arreté de mettre des valeurs en em dans leurs media-queries car cela n'évoque rien à la lecture. A la place, ils ont créé des mixins qui peuvent être facilement comprises à la lecture et ont abstrait les détails en dessous. Par exemple, mq(from:tablet), mq(from:phone, to:tablet), mq(until:tablet).

Niveau grille, même combat, création de helpers pour pouvoir rapidement définir "je veux trois colonnes, mais en desktop en avoir 7". Le code SCSS directement lisible exprime bien cette intention, on a des helpers pour définir des règles différentes pour phone et desktop, et on exprime avec d'autres helpers le nombre de colonnes qu'on souhaite. Toute la complexité de largeur de colonnes, largeur des marges, breakpoints est cachée dans ces mixins (qui sont le territoire des devs), alors que l'intention est exposée un niveau plus haut (territoire partagé dev/designer).

Le fait de partager la même langue pour parler de la même chose aide à la cohésion de l'équipe et à l'appropriation du projet. Il est plus facile de modeler le code pour qu'il suive les idées du designer que de remodeler le designer pour qu'il parle comme du code. En partageant tout cela entre les deux territoires, on augmente l'appropriation du code par les designers et l'appropriation du design par les devs.

Ten principles for effective front-end dev

Harry Roberts, créateur de inuit.css nous a ensuite parlé de quelque chose d'un peu plus meta que le CSS.

D'après lui, dans un projet web, il vaut mieux avoir une connaissance générale de tous les métiers qui vont prendre part au projet, plutôt que d'être expert uniquement de la partie qui nous concerne. Dans cette optique, il nous a donné 10 conseils pour ne pas perdre de vue l'essentiel. Plusieurs de ses conseils se recoupaient, je vais donc les synthétiser.

Tout d'abord, l'option la plus simple est souvent la meilleure. Plus on va vite, moins ça coûte cher au client. Le meilleur code est l'absence de code, plus on écrit de code, plus on écrit de PPOF (Potential Point of Failure). En réduisant la complexité d'une solution, on la rends plus légère et donc plus facile à comprendre, à apprendre à quelqu'un, à maintenir et à débugguer. Une solution simple aura moins tendance à casser, et nécessite moins d'overhead du codeur pour la comprendre. "Le mieux est l'ennemi du bien", il vaut mieux avoir quelque chose de good enough aujourd'hui, que quelque chose de parfait demain.

Ensuite, il ne faut pas oublier l'objectif. Le code n'est qu'un outil pour atteindre cet objectif. Il est nécessaire de comprendre ce qui coûte et ce qui apporte de la valeur au client, afin de ne pas lui faire perdre d'argent. Pour cela, il est nécessaire d'aller voir les autres personnes, d'autres métiers qui travaillent sur le même projet. Le travail d'un intégrateur web n'est pas de reproduire des PSDs, enfermé dans sa bulle avec son casque sur les oreilles. Il lui faut aller voir les autres, et faire ce qui est bon pour le produit final.

Finalement, il ne faut pas être trop attaché à son code. Le code est jetable et s'il est modulable il est facile d'en jeter un morceau en gardant le reste. Les demandes du projet vont changer régulièrement, il faut être prêt à accepter le changement, à jeter du code, à en écrire du nouveau. Dans le même ordre d'idée il est inutile de prévoir à l'avance tout les cas particuliers, car ils n'arriveront peut-être jamais, peut-être la fonctionnalité va-t'elle changer en cours de route.

Keep Calm and Write Sass

Hugo Giraudel nous a ensuite parlé de Sass, avec une liste de bonnes pratiques et de choses à ne pas faire. Il a aussi abordé un peu le tooling autour de Sass.

Sass est un preprocesseur CSS, qui apporte des briques habituellement trouvées dans les langages de prog : variable, conditions, boucles, fonctions, etc. C'est assez facile de vouloir en faire trop avec Sass, juste parce qu'on peut le faire. Mais ça ne sert à rien, et il faut rester KYSSS (Keep Your Sass Simple and Straightforward).

Il ne faut pas oublier que Sass permet de se positionner une couche au dessus de CSS, et qu'il permet donc d'exposer des méthodes pour générer du CSS. Il faut que ces méthodes soient peu nombreuses, avec une API publique simple. Ici, les bonnes pratiques du Clean Code habituelles s'appliquent : des noms explicites, des comportements devinables, pas des tas d'arguments différents pour gérer plusieurs cas de figures différents, etc.

Sass incite aussi au nesting de sélecteurs à outrance. C'est très facile à faire en Sass, mais ça donne des feuilles de styles finales avec des sélecteurs bien trop précis et bien trop difficiles à overrider. Il faut limiter au maximum le niveau de nesting.

Finalement, il a évoqué plusieurs outils comme scss-lint qui est un linter de fichiers Sass, sassdoc qui permet de générer une documentation HTML avec des exemples à partir de fichiers source Sass et enfin True qui permet de faire des tests unitaires sur les retours des fonctions Sass.

WTF CSS ?!

The dotPost

Et la dernière conférence à laquelle j'ai pu prendre des notes avant que la batterie de mon laptop et les neurones de mon cerveau ne lachent fut celle d'Estelle Weyl.

Estelle nous a montré quelques astuces tout droit tirées des coins les plus reculés du monde du CSS. Tout d'abord, grâce à counter-increment, il est possible de garder un compteur en CSS. Par exemple la page actuelle de sa présentation était indiquée grâce à ce système, et elle nous a montré comment afficher le nombre d'erreurs d'un formulaire rien qu'avec du css.

Elle nous aussi rappellé qu'il existait un grand nombre de pseudo-selecteurs dans la même veine que :valid et :invalid mais qu'ils ne sont pas encore correctement implémentés partout (notamment :default et :placeholder-shown).

On a ensuite fait un petit rappel des spécificités des sélecteurs (récapitulé sous forme de poisson sur Specifishity, et appris que les sélecteurs >, +, ~ et :not() n'ont aucune spécificité. Donc div p a le même poids que p + p et img pèse aussi lourd que :not(img). Il est bon de le rappeller.

Elle a ensuite parlé de l'horreur absolue qu'est !important dans du CSS, qui permet d'overrider toutes les autres règles et qui est lui-même impossible à overrider. Mais elle a aussi donné une astuce pour réussir à overrider un !important... astuce que je ne donnerai pas ici, vous pourriez avoir envie de l'utiliser ! :)

Pour finir, elle nous a montré un moyen de faire du browser sniffing directement depuis le navigateur, pour peu que celui-ci supporte @supports (recursive joke inside). En testant des propriétés prefixées -webkit ou -moz on peut comme ça appliquer certaines règles uniquement à un moteur de rendu ou un autre. Pas sur que ce soit une brillante idée, mais ça peut dépanner.

Fin des talks

Les trois derniers talks étaient de Nicolas Gallagher qui nous a parlé de comment ils ont modularisé leur UI chez Twitter, en utilisant des Web Components. Ce qu'il mettait en avant faisait echo à pas mal de choses dites précedemment : aligner les developpeurs et les designers sur un langage commun, masquer la complexité en dessous et laisser une API publique simple et qui exprime bien l'intention.

Bert Bos, co-créateur de CSS nous a parlé des challenges que posent les différents règles de typographie des différents pays du monde pour le CSS. Différents types de guillemets selon les langues, espaces avant la ponctuation ou non, italique qui s'applique ou non à la ponctuation, etc. C'était plus une lettre ouverte pour sensibiliser à ces questions.

Et finalement Ana Tudor nous a complétement bluffé en nous faisant faire des cos et sin pour dessiner des tracés chromatiques à coup de boucles en Sass.

Conclusion

Toutes ces conférences l'ont très bien rappellé : le langage CSS est riche, et il est possible de faire des choses formidables avec, mais il est aussi complexe à comprendre et demande de s'y plonger avec sérieux. Nous devons mettre en œuvre pour CSS toutes les bonnes pratiques que nous utilisons déjà pour les autres langages : modularisation, clean code, API publiques, tests unitaires.

Cela est d'autant plus important que le CSS est la partie partagée entre les développeurs et les designers, et celle-ci se doit d'être la plus claire et robuste possible pour la cohésion du projet au sein des équipes et sa maintenabilité sur la durée.

Ce post est cross-posté sur le blog Octo

Tags : #dotcss

Want to add something ? Feel free to get in touch on Twitter : @pixelastic