Bonne idée ou non, choix ergonomique ou pure fantaisie futile, l'idée de modifier graphiquement ou fonctionnellement les barres d'ascenseur du navigateur à sa guise est un souhait récurrent dans le domaine du Webdesign.

De nos jours, différentes actions peuvent être mises en œuvre pour améliorer l'aspect ou l'usage des scrollbars. Nous allons en détailler plus particulièrement trois dans cet article :

• Décorer les ascenseurs,
• Faire défiler progressivement,
• Créer des "points d'accroche".

Décorer les ascenseurs (scrollbars)

Aussi curieux que cela puisse paraître, il n'existe pas encore de méthode universellement reconnue pour apporter un style personnalisé à vos barres d'ascenseur.

Différentes pistes sont aujourd'hui à étudier :

1. Les propriétés scrollbar réservées à Internet Explorer
2. Les pseudo-éléments ::scrollbar
3. Les propriétés scrollbar-width et scrollbar-color

Les scrollbars d'Internet Explorer

Depuis la préhistoire du Web (IE5.5) et jusqu'à IE11, Internet Explorer s'est doté de méthodes propriétaires pour décorer les barres de scroll. Ces propriétés ont été abandonnées depuis sur Edge.

Voici comment nous pourrions les mettre en œuvre :

div {
  -ms-scrollbar-3dlight-color: hotpink;
  -ms-scrollbar-arrow-color: tomato;
  -ms-scrollbar-base-color: chocolate;
  -ms-scrollbar-darkshadow-color: salmon;
  -ms-scrollbar-face-color: olive;
  -ms-scrollbar-highlight-color: orange;
  -ms-scrollbar-shadow-color: lime;
}

Inutile de passer plus de temps que nécessaire sur des propriétés abandonnées, enchaînons de ce pas sur des méthodes plus utiles en production, à savoir ::scrollbar.

Les pseudo-éléments ::scrollbar

L'élément ::scrollbar constitue en fait un ensemble de pseudo-éléments permettant de décorer les barres d'ascenseur présentes sur le navigateur.

Bien que cet élément existe depuis plus de 10 ans à l'heure où cet article est rédigé, il ne figure curieusement dans aucune spécification officielle.

La raison est sans doute liée au fait qu'il s'agisse d'une méthode purement propriétaire du moteur Webkit.

• ::-webkit-scrollbar applique des styles sur l'ensemble de la barre.
• ::-webkit-scrollbar-button concerne les flèches de défilement du haut et du bas.
• ::-webkit-scrollbar-thumb désigne la "poignée" de la barre, c'est à dire la partie qui se déplace.
• ::-webkit-scrollbar-track représente la "gouttière" de la barre de défilement
• ::-webkit-scrollbar-track-piece désigne la partie de la gouttière qui n'est pas couverte par les flèches de défilement.
• ::-webkit-scrollbar-corner désigne le coin où les barres horizontales et verticales se rencontrent.
• ::-webkit-resizer représente le bouton qui apparaît dans le coin inférieur de certains éléments et qui permet de les redimensionner.

Voici comment appliquer quelques-uns de ces pseudo-éléments parmi les plus utiles :

/* scrollbar styling non-standard version */
html::-webkit-scrollbar {
  width: 2rem;
  background-color: rgba(0,0,0,.15); 
}
html::-webkit-scrollbar-thumb {
    background: #000; 
}

Contrairement aux techniques réservées à Internet Explorer précédemment abordées, les pseudo-éléments ::webkit-scrollbar peuvent sans risque être employées en production car leur support est excellent. En effet, et cela va peut-être vous étonner, le préfixe -webkit- est ici reconnu par Chrome, Safari, Opera, Android, Samsung Internet et même Blackberry. Seul Edge manque encore à l'appel, mais ce ne sera bientôt plus le cas puisque Edge 75 sera bâti sur Webkit lui aussi.

Dernier rescapé non-Webkit, le navigateur Firefox a pour sa part décidé de suivre une toute autre voie… celle proposée dans un brouillon de spécification nommé "CSS scrollbars".

La version "officielle"

Depuis le mois de mars 2019, un document de travail du W3C tente de standardiser la faculté de décorer les barres d'ascenseur.

À ce jour, seul Firefox (depuis la version 64) implémente ce très récent standard.

La spécification "CSS scrollbars" ne comporte que deux propriétés :

• scrollbar-width qui représente l'épaisseur de la barre et dont les valeurs peuvent être auto, thin ou none (il n'est pas possible d'attribuer une taille sur mesure)
• scrollbar-color qui,… avouez que vous savez déjà. Deux valeurs sont possibles, la première désignant la couleur de poignée et la seconde la couleur de gouttière.

Voici un exemple de code :

/* scrollbar styling standard version */
html {
  scrollbar-color: #000 rgba(0,0,0,.15);
  scrollbar-width: thin;
}

Notez que Firefox Mac ne se comporte pas comme son homologue Windows. Sur Mac, il faut activer les propriétés de scrollbar dans les Préférences système de l'OS : Général > Afficher les barres de défilement > cocher "toujours"

Et concrètement ça donne quoi ?

Au final, pour plaire à tous les navigateurs modernes, il s'agira bien entendu de réunir toutes ces techniques.

Je me suis abstenu de faire figurer les versions propriétaires à IE car elles sont abandonnées. L'ensemble ressemblera donc à ceci :

/* scrollbar styling non-standard version */
html::-webkit-scrollbar {
  width: 2rem;
  background-color: rgba(0,0,0,.15); 
}
html::-webkit-scrollbar-thumb {
    background: #000; 
}
/* scrollbar styling standard version */
html {
  scrollbar-color: #000 rgba(0,0,0,.15);
  scrollbar-width: thin;
}

Voir la démo en ligne

Je profite de votre totale attention pour placer judicieusement un mot d'accessibilité en ce qui concerne les contrastes de couleur. Je rappelle - mais vous le saviez déjà - que WCAG 2.1 demande à ce que les éléments d'interface respectent un contraste de 3:1 au moins.

Autoriser un défilement progressif

Lorsque l'on se déplace via des ancres au sein d'une page, l'atterrissage est souvent brusque et immédiat.

Pouvoir défiler de manière adoucie, en transition vers un point précis - ce que l'on appelle "smooth scroll" - a longtemps été réservé à des langages tels que JavaScript.

C'est à présent (aussi) le boulot de la propriété CSS scroll-behavior, ajoutée dans le document de spécification de brouillon "CSSOM View Module" en 2019.

Les deux valeurs attendues de la propriété scroll-behavior sont :

• auto : défilement laissé à discrétion de l'agent utilisateur (abrupt en général)
• smooth : défilement progressif

La durée de smooth est propre à chaque agent utilisateur mais doit se conformer aux paramètres habituels du device.

La propriété scroll-behavior peut s'appliquer à tous les éléments disposant d'une barre de défilement (par exemple munis de déclarations telles que overflow: scroll ou overflow-x: auto) mais également sur l'ensemble du document, comme en témoigne cet exemple :

/* scroll behavior on html */
html {
  scroll-behavior: smooth;
}

Malgré sa jeunesse (née en 2019 je le rappelle), scroll-behavior bénéficie d'un bon support puisque Chrome, Firefox, Opera, Android, Samsung Internet et bientôt Edge reconnaissent cette fonctionnalité. Elle est donc utilisable en production en tant que bonus, ou accompagnée d'une alternative en JavaScript par exemple.

Au sein de cet excellent article en anglais, vous trouverez toutes les pistes pour réaliser vos défilement progressifs sur l'ensemble des navigateurs.

Voir la démo en ligne

Les points d'accroche avec scroll-snap

Dernière fonctionnalité abordée au sein de cet article : la possibilité de déclarer des "points d'accroche" lors du défilement. Cette initiative permet de simuler le comportement que l'on trouve sur certaines applications natives par exemple et où les éléments semblent attirées par une grille lors du défilement.

La documentation de ces propriétés d'accroche est très récente mais s'est également stabilisée très vite au point d'atteindre le stade de Candidate Recommendation depuis le mois de mars 2019.

En théorie, l'ensemble de cette spécification tient en deux propriétés principales différenciées selon l'élément qu'elles ciblent :

• scroll-snap-type (sur le parent) : définit quel est le type d'accroche et si sa direction est horizontale ou verticale.
  • les valeurs x ou y correspondent à l'axe
  • les valeurs mandatory ou proximity indiquent si l'enfant doit ou peut s'accrocher au point défini
• scroll-snap-align (sur les enfants) : définit le comportement d'accroche des enfants, les valeurs possibles étant start, end ou center.

En pratique et en production, cela se complique légèrement du fait de la relative compatibilité de ces propriétés : - Jusqu'à sa version 67, Firefox reconnaît une ancienne version de la spécification. - Internet Explorer et Edge reconnaissent leur propre mécanisme propriétaire (eh oui).

Pour vous imprégner de l'ensemble des fonctionnalités et subtilités de ces propriétés d'accroche, voici une liste de lecture absolument indispensable : - scroll-snap les concepts de base par MDN - la propriété scroll-snap en détail par MDN - un polyfill (alternative JavaScript) pour les mauvais élèves navigateurs

Concrètement, l'exemple suivant permet en quelques lignes de mettre en œuvre ce mécanisme :

.gallery {
  height: 40rem;
  overflow-y: scroll;
  scroll-snap-type: y proximity;  
}

.gallery div {
  scroll-snap-align: center;
}

Voir la démo en ligne

Conclusion

Décorer les barres d'ascenseur, modifier le comportement lors des interactions avec les usagers, sont des fonctionnalités dorénavant prises en charge par CSS. Elles demeurent parfois encore complexes à mettre en action pour des raisons de compatibilité, mais le temps joue en notre faveur : les principaux obstacles disparaissent peu à peu et l'avenir de ce genre de propriétés est de plus en plus radieux.

Retrouvez l'intégralité de ce tutoriel en ligne sur Alsacreations.com

Ces dernières années, les deux avancées majeures de CSS dans le domaine du positionnement se nomment respectivement "Flexbox" et "Grid Layout". Incomparablement plus puissants que les anciennes méthodes, ces nouveaux positionnements sont une bénédiction tout autant qu'ils intriguent et questionnent.

Parmi les questions récurrentes que l'on se pose et auxquelles nous allons tenter de répondre ici figure en tête : "Oui mais que choisir entre Flexbox et Grid Layout ?"

Statut et philosophie

Les deux modèles de positionnement comptent parmi les spécifications officielles du W3C destinées à être pérennes et complémentaires.

Il ne s'agit pas, comme peuvent le laisser croire certaines sources, de "frameworks" ou d'outils tels que des préprocesseurs. Grid Layout et Flexbox ne sont autre que du CSS natif ne nécessitant aucun environnement particulier pour fonctionner, et de ce fait adaptables à n'importe quel workflow (React, Vue, Angular par exemple).

Ces deux spécifications CSS ont atteint le stade de "Candidate Recommandation", il s'agit donc de documents stables et fiables. Un second niveau de documentation est en cours de développement et prévoit d'ajouter de nouvelles fonctionnalités à ces deux modules (subgrid pour Grid Layout, gouttières pour Flexbox).

Si l'on devait résumer la philosophie principale qui différencie ces deux spécifications, nous dirions que Grid Layout est voué à construire le gabarit général de la page et que Flexbox est le compagnon idéal des composants qui la remplissent.

Figure 01 : État des lieux des spécifications Flexbox et Grid Layout à ce jour

Conteneur vs Contenu

Grid Layout crée un cadre robuste, les lignes de la grille sont établies une fois pour toutes, même si les zones formées peuvent être fluides et même s'il est possible de les fusionner. Les contenus s'adaptent à leurs emplacements respectifs.

Au sein de Flexbox, ce sont plutôt les enfants (les contenus donc) qui font leur loi. Ils s'organisent les uns avec autres, se poussent à l'aide de marges, s'agrandissent ou se rétrécissent au besoin, passent à la ligne si nécessaire, se réordonnent, etc.

La conception par Grid Layout donne la priorité au conteneur tandis que Flexbox laisse la part belle au contenu.

Figure 02 : Grid Layout est parfait pour la construction des emplacements principaux (zones jaunes)

Figure 03 : Flexbox est idéal pour les contenus et composants internes (zones vertes)

Rigueur vs Fluidité

Flexbox est né avec la génération Responsive Webdesign et se démarque par une volonté de "lâcher prise" : exit les tailles de boîtes figées inadaptables sur les nombreux périphériques actuels, bienvenue aux éléments de dimensions fluides qui s'ajustent automatiquement à leur emplacement. La flexibilité est au coeur du modèle Flexbox jusque dans son appellation.

L'esprit de Grid Layout est plus "architectural" et cartésien : on définit au préalable les fondements de notre projet à l'aide de colonnes et de lignes.

Bien entendu, la grille peut parfaitement être fluide dans tous les sens, mais une certaine rigueur persiste dans la mesure où la largeur d'une colonne sera identique d'une rangée à une autre par exemple.

Figure 04 : Une répartition des éléments "au fil du flux", via Flexbox

Figure 05 : Une répartition des éléments plus "tabulaire", via Grid Layout

Axe unique vs Axe double

Flexbox est autant à l'aise sur l'axe horizontal que sur l'axe vertical. C'est un véritable bonheur de centrer verticalement des éléments en CSS depuis cette petite révolution.

Toutefois, Flexbox est bien moins performant lorsqu'il s'agit de manier les deux à la fois (les rangées et les colonnes). La preuve en est que le comportement naturel est de ne pas autoriser les retours à la ligne dans Flexbox et qu'il est nécessaire d'activer cette fonctionnalité en modifiant la valeur par défaut de flex-wrap.

Grid Layout pour sa part est complètement bidirectionnel et gère en même temps et en toute simplicité les deux directions horizontales et verticales.

Figure 06 : Les éléments de Grid Layout peuvent s'épanouir sur les deux axes à la fois. Figure impossible à réaliser via Flexbox sans conteneurs supplémentaires.

Fonctionnalités ?

En terme de fonctionnalités, peu de différences apparaissent au final entre Flexbox et Grid Layout. Les mêmes objectifs sont souvent atteignables quel que soit le mode de positionnement choisi : placement, répartition, alignements, ré-ordonnement, etc.

Quelques particularités toutefois distinguent les deux modèles :

• Les gouttières sont pour le moment réservées à Grid Layout (propriété gap), l'équivalent dans Flexbox est à venir prochainement mais nécessite, en attendant, des bidouilles à base de marges négatives partielles en général;
• Les propriétés d'alignements et de centrage sont un tantinet plus nombreuses et plus intuitives dans Grid Layout (ainsi il y existe justify-self inexistant dans Flexbox);
• Flexbox et Grid Layout intègrent parfaitement les valeurs et orientation "logiques" de tous les éléments (valeurs start et end plutôt que left et right, etc.`). Bonus pour Flexbox, où il les axes d'affichage eux-mêmes sont inversables via row-reverse et column-reverse.

Facilité d'usage ?

Flexbox ou Grid Layout changent tous deux radicalement la donne et se placent bien au dessus de toutes les méthodes ancestrales d'intégration à base de float, inline-block, marges négatives ou de tableaux.

L'un et l'autre disposent d'une courbe d'apprentissage similaire : dès le début, il est enfantin de réaliser des performances jusqu'alors inespérées en CSS (centrer verticalement !), puis un seuil est atteint où l'on se rend compte que de nombreuses propriétés et valeurs interagissent et que chaque modèle de positionnement dispose de ses propres lois et qu'elles sont beaucoup plus vastes et complexes qu'on ne l'imagine.

Figure 07 : Un gabarit réalisé en quelques lignes seulement grâce à Grid Layout. Code source ci-après.

.container {
  display: grid;
  grid-template-columns: 20rem 1fr 1fr 1fr;
  grid-gap: .5rem;
}
.header {
  grid-column: span 4;
}
.title {
  grid-column: 2 / span 3;
}
.sidebar {
  grid-row: 2 / span 2;
}
.footer {
  grid-column: span 4;
}

Voir en ligne

Figure 08 : Flexbox rend les formulaires magiques grâce à un simple display: flex. Code source ci-après.

.form{
  display: flex; /* bah oui */
}

Voir en ligne

Compatibilité ?

Flexbox et Grid Layout sont reconnus par tous les navigateurs modernes depuis Internet Explorer 10.

Au delà de cette bonne nouvelle qui ne peut que nous réjouir, tout n'est pas aussi optimiste dans la pratique car certains navigateurs offrent un support pour le moins défaillant par rapport à d'autres. Pour Grid Layout suffit de se référer à la ressource Gridbugs pour s'en rendre compte; Pour Flexbox, il s'agit de Flexbugs.

Concernant Grid Layout plus particulièrement et pour ce qui est d'Internet Explorer, de nombreux aspects sont à prendre en compte pour assurer un affichage honorable. Au point où j'ai compilé toutes les étapes à suivre au sein d'un article nommé "Grid Layout en production ?". Je vous conseille vivement d'y faire un tour avant de tester votre grille sur IE.

Bref, dans tous les cas, Internet Explorer va encore continuer à nous jouer des tours durant quelques temps.

Figure 09 : GridBugs, maintenu par Rachel Andrew, liste les bugs couramment rencontré dans Grid Layout.

Concision et propreté

Flexbox et Grid Layout ont été conçus pour alléger le poids et les imbrications HTML pour au final le rendre le plus épuré possible. On est très loin des éléments <div> superflus ou imbriqués les uns dans les autres : seuls les éléments effectivement utiles et affichés à l'écran sont conservés dans le code HTML, pour schématiser.

Quelques exceptions toutefois necessitent encore la présence de "conteneurs" supplémentaires dans Flexbox (cf. Figure 06), ce qui n'est pas nécessaire dans Grid Layout.

Documentation

La communauté Flexbox est plus ancienne que celle de Grid Layout, elle est donc également plus vaste et plus active pour le moment. Vous trouverez assez aisément moults réponses à toutes vos questions Flex dans les forums de discussion des internets.

Si vous désirez vous informer ou vous perfectionner dans des deux modèles de positionnement (et je ne peux que vous y inciter), je vous invite à consulter l'un ou l'autre de ces supports :

• Les Spécifications du W3C, si vous êtes très motivé•e;
• MDN (Mozilla Neveloper Network) et plus particulièrement ses introductions à Flexbox et Grid Layout;
• Alsacreations, où divers articles et tutoriels traitent de ces positionnements;
• Des livres. Il existe dorénavant des ouvrages dédiés à Flexbox et Grid Layout;
• Des Formations. Rien ne vaut une formation de quelques jours avec une vraie personne en face pour répondre à toutes vos questions. Concernant Grid Layout, les formations sont encore peu nombreuses et Alsacréations propose un programme de deux journées dont vous nous direz des nouvelles !

Conclusion : les deux font la paire !

Mais alors… Flexbox ou Grid Layout ?

Vous allez m'en vouloir si je vous réponds "ça dépend" après tous ces arguments pour l'un et pour l'autre. À présent que vous connaissez les objectifs mais aussi les forces et faiblesses de Flexbox et de Grid Layout, le choix est entre vos mains. Méditez là dessus…

Publié par Alsacreations.com

Vous les attendiez peut-être, nous les avons concoctés avec amour : trois quiz Vue.js sont maintenant disponibles pour tester vos connaissances.

Dans la rubrique Quiz, vous trouverez trois niveaux de difficulté :

• Débutant
• Moyen
• Expert

Selon l’auteur, il n’y a pas de pièges — ou peu. Et si vous ne connaissez pas encore ce framework super pratique, rejoignez notre formation Vue.js.

N’hésitez pas à nous faire part de vos retours !

Publié par Alsacreations.com

Les Positive Design Days sont un événement organisé par Impact Positif, autour de l'expérience utilisateur.

Il aura lieu mardi 12 Novembre 2019 à l’Hôtel du Département de Strasbourg (place du Quartier Blanc).

Au programme : ateliers, conférences et table ronde animés par des designers expérimentés de France et de Suisse qui partageront leurs savoir-faire et leurs conseils sur le sujet.

Inscrivez-vous sur le site officiel, les places sont limitées.

Publié par Alsacreations.com

Les dotConferences sont de retour avec un nouveau cru dotCSS + dotJS 2019 et un programme toujours alléchant.

Cette année, toujours à Paris, le format passe sur 3 jours (au lieu de 2) dont :

• un jour CSS
• un jour JavaScript côté front-end (UI, frameworks, navigateurs...)
• un jour JavaScript côté back-end (Node.js, ES2019, compilateurs...)

Des conférencières et conférenciers sont déjà annoncés, avec entre autres en JS: Evan You (créateur de Vue.js), Brendan Eich (l'inventeur de JavaScript), Charlie Gerard, Chris Heilmann, Vladimir Agafonkin, Sara Vieira, Vlad Filippov, Phil Hawksworth, Valerie Young, Simona Cotin ; et côté CSS : Hakim El Hattab, Emily Plummer, David Khourshid, Jason Pamental, Ire Aderinokun...

Allons-y

Vous pouvez choisir l'ensemble ou la combinaison de jours qui vous sied au mieux.

En utilisant le code promo ALSACREATIONS ou les liens suivants vous économiserez 10% :

• https://2019.dotjs.io/tickets?promocode=ALSACREATIONS
• https://2019.dotcss.io/tickets?promocode=ALSACREATIONS

Souvenirs de 2018

Publié par Alsacreations.com

En avril dernier, nous avions lancé un sondage concernant votre outil de design préféré en 2019. À notre grande surprise, un quart d'entre vous utilisait encore Photoshop !

Pourquoi une telle réaction, nous direz-vous ?

Eh bien parce qu'à l'heure des designs responsive et multi-plateformes, de nombreux logiciels spécialisés dans le webdesign se sont développés et répondent de manière plus optimale aux nombreuses problématiques actuelles. Nous sommes ainsi surpris de voir encore tant d'adeptes de Photoshop, même si nous comprenons amplement les raisons de ce choix. Il s'agit en effet de l'un des plus vieux softs sur le marché et, pour la plupart d'entre nous, du premier sur lequel nous avons fait nos armes.

Ça vous rappelle quelque chose ?

Les habitudes ont la vie dure il paraît, et, lors de nos formations en HTML/CSS ou webdesign, nos apprenants se posent fréquemment la question du choix de l’outil : « J'utilise Photoshop pour designer mes maquettes et cela semble convenir. Mais qu'en est-il des autres logiciels ? Existe-t-il une solution plus efficace pour s'adapter aux contraintes modernes ? »

Photoshop, l'ancêtre du design

Lancé par Adobe Studio en 1990, Photoshop était l'un des logiciels précurseurs en terme de design. À l'époque, il n'existait pas vraiment d'autre alternative. Tout le monde travaillait sur Photoshop : photographes, illustrateurs et, peu à peu, les premiers webdesigners.

Illustrator s'est ensuite développé et s'est intégré dans notre workflow afin de travailler le vectoriel, utilisé presque uniquement pour les logos. La mode était en effet au skeuomorphisme, une technique de design visant à imiter à la perfection des éléments du monde réel. Pour être « dans la tendance », il fallait donc concevoir des interfaces qui imitaient la réalité et, donc, « dessiner » la plupart des éléments graphiques. Ombres, dégradés, textures, tout était bon pour amener de la vie dans nos designs.

L'arrivée de Flash en 1996 amplifie ce mouvement et cette envie de « vie », de « folie » sur les sites web qui représentent une nouvelle liberté, un espace d'expression que chacun s'approprie et réinvente à sa sauce.

Photoshop était donc tout indiqué pour atteindre nos objectifs de l'époque. Il possédait toutes les fonctions pour le dessin infographique et la communauté était immense, enrichie de forums et de tutoriels afin de créer n'importe quel projet.

Certains sont ensuite passés sur the Gimp (1995) ou Inkscape (2003), d'autres encore ont dévié sur Illustrator, et les plus téméraires ont migré sur Fireworks, une acquisition d'Adobe qui gérait à la fois les formats bitmap et vectoriels. Des logiciels de l'époque, il était sans doute le plus adapté au web et proposait une sorte de fusion entre Photoshop et Illustrator. Acquis par la firme en 2007, la dernière version est sortie en 2012.

Les nouvelles technologies web apparaissent au fil des ans

En 2007, Flash n'est plus compatible avec le nouvel iPhone et tombe en désuétude. Les grilles et frameworks apparaissent la même année, répondant ainsi aux besoin grandissants de design adaptables : les sites s'installent sur des colonnes qu'il est plus facile de redistribuer pour chaque taille d'écran.

En 2010, le responsive webdesign tel que nous le connaissons fait son apparition. Le but est désormais de créer des designs dont le contenu s'adapte quelle que soit la taille de notre écran, tout en conservant le sens et l'expérience utilisateur. Le responsive s'accompagne de la tendance design actuelle, le « flat design ». Véritable antagoniste du skeuomorphisme, le flat design simplifie grandement les interfaces : la nouvelle mode est au simple, au « less is more », aux grands aplats de couleurs. Les ombres, dégradés et textures anciennes disparaissent au profit de formes basiques et aux explosions de couleurs brutes.

La sortie de logiciels dédiés au webdesign

Jusque là, nous travaillions sur des logiciels déviés de leur but premier : Illustrator pour l'illustration, Photoshop pour la photographie... Près de 20 ans d'utilisation, pour les plus chevronnés, laissent évidemment des traces. Les amoureux de Photoshop pourraient s'en servir les yeux fermés et les habitudes permettent de réduire considérablement le temps de travail.

Il n'en reste pourtant que ces logiciels n'étaient pas et ne sont toujours pas adaptés au web. Adobe a certes inclus de nombreuses améliorations et autres plugins pour le web à Photoshop, mais il s'agit là de briques ajoutées à un édifice qui n'est pas prévu pour ça. C'est tout le cheminement, l'essence même du logiciel qui sont détournés.

Entendons-nous bien : Photoshop est un outil absolument génial pour le travail de la photographie, de l'image et de l'illustration, ce pour quoi il avait été initialement développé. Mais pour ce qui est du maquettage web, il accumule des années de retard comparé à d'autres applications spécialement réfléchies et conçues pour notre domaine d'expertise.

Il nous manquait un véritable logiciel pour le web, avec des réflexions tournées vers le futur – autrement dit, le Responsive et le multiplateformes.

Pannel de logiciels de webdesign modernes, non exhaustif

L'un des premiers à s'emparer de ce nouveau marché était Sketch, en 2010. Figma suivit en 2016, avec l'avantage d'être également disponible sur Windows et sur navigateur, et Adobe se relance dans la course avec Adobe XD. Invision Studio, lui, se lance à partir de 2016, distribué au compte-gouttes aux premiers inscrits.

Quels sont les 8 avantages des logiciels de webdesign modernes ?

Passons en revue les bonnes raisons d'adopter un logiciel moderne !

La première est, bien sûr, qu'ils ont été spécialement conçus pour le web et pour les besoins des professionnels. Ce sont donc de véritables outils de travail dédiés à notre workflow.

Les autres avantages peuvent varier selon le logiciel utilisé même si la plupart d'entre eux suivent un modèle semblable. Pour notre exemple, nous parlerons donc de sketch, mais sachez que les fonctionnalités citées sont toutes accessibles sur d'autres logiciels modernes tels que Figma, Adobe XD, Invision Studio... C'est à vous de tester ce qui vous convient le mieux.

Vectoriel vs Bitmap

Pas de perte de détails

Là où Photoshop travaille majoritairement avec le format bitmap, Sketch utilise le format vectoriel. Nous pouvons donc créer des formes redimensionnables à l'infini sans perte de détails. Pratique pour le responsive !

À gauche photoshop ; à droite sketch

https://www.sketch.com/docs/shapes/

Exports CSS

Simplicité et efficacité du code

Photoshop, tout comme Sketch, permet de copier le code CSS d'un calque afin de le réutiliser durant la phase d'intégration ; cependant, comme vous pouvez le voir dans l'exemple ci-dessous, Photoshop produit plus de code que nécessaire, et pas forcément le bon, d'ailleurs : Le code généré indique les largeurs et hauteurs (pas prioritaires à l'heure des designs responsives) mais pas l'arrondi des coins.

À gauche photoshop ; à droite sketch

Canvas et artboards

Une zone de travail infinie

Le canvas, zone de travail dans sketch, est scrollable à l'infini. À l'intérieur de ce canvas vous pouvez créer autant d'artboards que vous le souhaitez : c'est ici que vous créez les différentes pages de votre design. Plus besoin de naviguer dans différents fichiers photoshop, ou de masquer/démasquer du contenu pour visualiser votre design. Tout est à portée de vue !

À gauche photoshop ; à droite sketch

https://www.sketch.com/docs/the-interface/canvas/

Styles

Un registre des styles de texte ou de bouton

Sketch vous offre la possibilité d'enregistrer des styles et de les appliquer sur de nouveaux éléments. Vous pouvez ainsi « stocker » des styles de texte (H1, H2, paragraphe, lien...) et les réutiliser efficacement sans causer d'incohérence de style.

Capture d'écran du fonctionnement des styles dans Sketch

Symboles

Un modèle d'élément duplicable et toujours à jour

Les symboles sont des éléments réutilisables à travers votre document de travail. Il suffit de créer un « master », de le sauvegarder en tant que symbole et il sera stocké dans une page consacrée aux symboles. Ensuite, vous n'avez qu'à le dupliquer où vous le souhaiter.

Le grand avantage des symboles est qu'ils vous permettent de modifier rapidement le style d'un élément complexe. Par exemple, si vous faites un bouton et que vous souhaitez en changer la couleur, vous ne le faites qu'une fois en modifiant le master du symbole ; sans ça, vous auriez dû changer tous les boutons présents dans votre document !

Capture d'écran du fonctionnement des symboles dans Sketch

Librairies

Une banque de styles, symboles et ressources accessible à l'intérieur de TOUS les projets

Librairies : Il s'agit d'une « banque de données » qui contient des symboles et des styles réutilisables dans d'autres documents sketch. Cela peut être, par exemple, des collections d'icônes, des boutons préfaits, des styles de textes... C'est particulièrement utile pour les gros projets où une librairie peut faire office de guide de syle. C'est aussi très pratique pour les agences de moyenne ou grande taille où plusieurs designers peuvent ainsi partager, mettre à jour et utiliser les mêmes ressources.

Adaptation automatique des artboards avec pins (fluidité)

Resizing automatique et magnétisation des éléments

Dans Sketch, transformer un design à destination des grands écran en un design pour mobile est un jeu d'enfant ! Vous pouvez décider des contraintes de chaque élément : redimensionnable, largeur ou hauteur fixe, ancrage au bord droit, etc.

Vous pouvez aussi agrandir ou réduire un objet en changeant ses dimensions en pixel, ou en pourcentage et décider de garder ses proportions ou non.

Capture d'écran du fonctionnement du resizing dans Sketch

https://www.sketch.com/docs/layer-basics/resizing-layers/

Les plugins (anima, craft) et les interactions avec d'autres interfaces (inVision...)

Les logiciels modernes présentent aussi l'avantage d'avoir une communauté active, et de nombreux plugins sont régulièrement ajouté pour améliorer l'expérience et le confort d'utilisation. Si vous êtes curieux.ses, jetez un coup d'oeil aux liens suivants !

Anima ; le responsive au cœur de vos artboards : https://www.animaapp.com/
Craft ; prototypage et synchronisation avec Invision : https://www.invisionapp.com/craft
Git Sketch ; versionnage pour sketch : https://mathieudutour.github.io/git-sketch-plugin/
Measure ; plus d'informations sur les distances et mesures : https://utom.design/measure.html

Tous les plugins sketch : https://www.sketch.com/extensions/plugins/

Tous les plugins Figma : https://www.figma.com/c/plugin/all

Alors, prêts à sauter le pas ?

Nous savons que c'est toujours compliqué de changer nos habitudes, mais après quelques jours d'adaptation, vous ne voudrez plus revenir en arrière ! 

Pourquoi ne pas commencer par vous familiariser avec Figma, un logiciel gratuit à l'essai qui vous permettra de prendre de nouvelles marques ? ;) N'hésitez pas à nous faire part de vos retours et de votre expérience !

Publié par Alsacreations.com

Cette année encore (c'est ma troisième) j'ai eu l'honneur de participer au Devfest de Nantes : deux journées de conférences plutôt orientées pour les développeur•euse•s comme son nom l'indique et dont l'ambiance se rapproche de plus en plus du festival de métal Hellfest — très proche géographiquement — dont il s'inspire abondamment.

Pour sortir de ma zone de confort, j'y ai présenté un sujet sur la typographie, thématique que je ne maîtrise pas tant que ça mais qui me passionne : "L'épopée des polices CSS de Comic Sans aux fontes variables".

"Grandiose" est le premier mot qui me vient à l'esprit en entrant dans le Centre des Congrès de Nantes. Et encore, je suis arrivé tôt et l'entrée était loin d'être remplie.

Énormément de stands partout, sur deux étages, tous orientés très "rock". Des activités toutes plus originales les unes que les autres : des karaokés, des simulations de réalité virtuelle, du guitar smashing, des concours de headbanging, des tatouages éphémères, de la conception de t-shirts, etc. Et... même des places à gagner pour le Hellfest 2020 ! (Bon, j'avoue, j'ai peu d'espoir).

Voici un résumé de mes aventures dans le Grand Ouest de la France, et plus particulièrement les moments qui m'ont le plus marqué…

Dès le début de journée, il a fallu choisir entre des confs radicalement différentes : les frameworks de Hubert Sablonnière et les daltoniens de Laura Wacrenier… Au final tous les feux étaient au vert pour le daltonisme :)

Au delà des couleurs (les interfaces adaptées au daltonisme)

La présentation de Laura Wacrenier est indubitablement une sensibilisation à l'accessibilité et au daltonisme. On reste dans le domaine de l'introduction mais avec le parti pris de systématiquement illustrer avec des exemples du quotidien et surtout appliqués en production chez Sonarsource (la société où oeuvre Laura). Bref on est dans le concret et c'est bien plus parlant ainsi.

Le déroulement est classique mais efficace :

• Laura commence par un état des lieux de l'existant dans sa boîte et le constat que toutes les interfaces jouent avec les couleurs rouge-vert-bleu (les dashboards, le formulaires),
• Elle poursuit avec les types de daltonisme, le plus courant étant l'atteinte du cône vert (deuteranoponia). Atteinte du chromosome X, donc concerne plus souvent les hommes (8%) que les femmes (0.5%),
• Elle passe ensuite aux bonnes pratiques (contrastes des textes, des éléments non textuels, ne pas se reposer sur les couleurs, souligner les liens, proposer des thèmes de couleurs, etc.)
• Et elle finit par le plus costaud : convaincre les équipes, ce qui n'est pas évident puisque les chiffres ne jouent pas en notre faveur (4.5% de la population est daltonienne). Comprendre que cela bénéficie à tout le monde et proposer systématiquement des design review (niveau AAA, tester avec simulateurs de daltonisme, approuvé sur un channel Slack dédié, etc.).

En conclusion, j'ai bien aimé cette présentation. Pas forcément pour ce qu'elle m'a appris mais surtout parce que l'enthousiasme de Laura est communicatif et donne envie de faire bouger les choses !

Les slides sont disponibles ici : https://drive.google.com/file/d/1IUtL_4KIRtLPfuTKsYxjcWHAftXPXd6L/view

Pause de midi

Toasts, canapés, wraps, etc. sont au rendez-vous. Gargantuesque mais relativement peu végétarien dans l'ensemble (ou alors j'ai mal cherché) et bien entendu beaucoup de monde qui se rue sur le buffet. Mais il est toujours difficile de réguler plusieurs milliers d'affamés.

La thématique Rock'n Roll n'est pas en reste puisqu'une scène musicale est prête à accueillir des groupes de musique en pleine improvisation ou de reprise de Nirvana, Rage Against the Machine, etc.

Burp !

Interactive web animation with SVG

C'est Cassie Evans de Clearleft (à Brighton) qui a la lourde tâche de nous tenir éveillé durant la digestion.

L'objectif de sa présentation est clairement d'encourager l'audience à adopter les animations SVG. Il s'agit donc plutôt d'une sensibilisation à l'aide de démos visuelles "whaou" qu'une conférence purement technique avec du code.

Malheureusement, la toute première démo Codepen plante, ce qui n'a pas dû arranger le niveau de stress de Cassie. La "Wobbly Jellyfish" sera finalement animée après diverses manipulations ésotériques. Ouf !

Parcours sans surprise, la présentation débute par un explication de ce qu'est le format SVG, à savoir à la fois une image mathématique et un langage de "markup" avec un DOM. SVG fait le pont entre Dev et Design.

À travers une démonstration concrète d'animation d'un Neopet, Cassie évoque les étapes et les bonnes pratiques à suivre :

• Choisir l'un des nombreux outils graphiques tels que Illustrator, Figma, Inscape, ou encore des banques d'images SVG telles que freepik.com
• Toujours nettoyer le fichier avant de commencer par exemple avec svgomg
• Continuer sur Codepen. Il suffit de copier/coller le code SVG dans Codepen puis de s'amuser avec.

Note en passant : la notion de "SVG viewport" qui représente la partie visible du SVG. Ce qui en déborde sera croppé.

Assez rapidement, Cassie aborde les limitations rencontrées :

• Pas de notion de z-index dans SVG, il faut apparaître dans le bon ordre du DOM pour être correctement superposé
• On ne peut pas enchaîner les animations en CSS, il faut jouer avec des delay successifs
• Le point d'origine de la transformation n'est pas identique selon les navigateurs. La récente propriété transform-box définit le layout box (valeurs fill-box ou view-box) et harmonise les navigateurs. Proposition de tester via @supports (transform-box: fill-box) {...}

Pour pallier ces limitations, Cassie évoque les bibliothèques utiles : Anime, Greensock, velocity.js :

• Ces librairies (sous licence MIT en général) gèrent les origines de transformations et les timelines successives
• Greensock propose des plugins (drawsvg plugin, morphsvg par ex.)
• Greensock propose également diverses courbes d'accélération originales telles que bounce et rough
• Ces librairies permettent en outre de réagir à l'audio ou à la webcam (color detection, face detection avec face API)

Au final tout cela est bien enthousiasmant en effet et je n'ai carrément vu personne s'endormir après le repas.

Les slides sont disponibles ici : https://slides.com/cassiecodes/deck-4-5

Promouvoir son projet open-source comme une rock star !

Une présentation de Franck Abgrall et Thomas Betous proposée par un duo bien sympathique, motivé et dynamique.

Le combo fonctionne bien, le rythme est entraînant, les échanges sont pertinents et pas trop de lourdeurs qui pourraient être dûes à une sur-préparation.

Mine de rien, même si tout est construit comme un sketch, les contenus sont bien là et exposés point par point :

• Bien préparer le projet (attendre qu'il soit mature, choisir un nom approprié, peaufiner l'aspect graphique, proposer une démo et une documentation claire)
• Déployer le projet (commencer à en parler dans son entourage, puis les réseaux sociaux, écrire des articles, le présenter à des conférences, créer des vidéos, etc.)
• Conserver ses usagers (mettre à jour le projet régulièrement, maintenir et corriger les issues, inviter aux contributions, remercier les contributeurs)

J'ai bien aimé ce moment à la fois divertissant et fort instructif : il y a plein de points pertinents qu'on imagine mettre en place dès le retour au bureau !

Les slides sont disponibles ici : https://speakerdeck.com/franckabgrall/comment-promouvoir-son-projet-open-source , et l'ensemble des conseils réunis sous forme de "Cheat Sheet" : https://github.com/zenika-open-source/open-source-promotion-cheat-sheet

Conclusion

Qu'il est difficile de résumer en quelques paragraphes l'ampleur du contenu et de l'ambiance d'un événement tel que ce Devfest. Pour l'avoir connue presque à ses débuts, on ne peut nier que cette manifestation a pris une ampleur considérable et devient sans aucun doute un regroupement incontournable aujourd'hui pour les développeuses et développeurs de tout poil et de tous horizons.

L'ambiance bon enfant et de je-ne-me-prends-pas-trop-au-sérieux est un atout considérable et ajoute à toute cette masse de contenus et d'informations emmagasinés une touche de légèreté qui rend encore plus indispensable ce type d'événement.

Je tire mon chapeau à toute l'équipe du staff pour l'organisation sans faille de cette manifestation exceptionnelle !

Publié par Alsacreations.com

Dans le but d'étoffer nos propositions de contenus originaux et de ne pas être les seuls à donner notre avis via nos articles, Alsacréations a décidé de donner la parole à des professionnel·le·s du Web au travers de courtes interviews permettant de découvrir des profils aussi différents qu'intéressants. L'idée derrière cette initiative est de parler d'actualité, découvrir de nouveaux horizons, mais également de donner de la visibilité à certaines pratiques, parfois trop peu mises en avant.
Et c'est Sophie Drouvroy qui a accepté la lourde responsabilité d'être notre première invitée pour entamer cette nouvelle série de questions-réponses.

Sophie compte parmi les personnes qui font avancer le Web de qualité, le Web accessible à tous. Le sâchiez-vous ?

(Alsacréations) Peux-tu te présenter en quelques mots, ainsi que ton parcours ?

(Sophie Drouvroy) Je suis actuellement responsable front et qualité web chez numerik-ea, Intégratrice web et experte en accessibilité numérique. J’ai été formée à l’école des Gobelins en 1997. À ma sortie de l’école, j’ai fait des sites en flash mais aussi en HTML/CSS. J’ai appris par moi-même car les formations sont rarement accessibles.

(A) Quels outils mets-tu en œuvre au quotidien ?

(SD) Firefox, Chrome et Safari avec des extensions (liste non exhaustive : Stylus, Tota11y, Web Developer, headingsMap,…). Mes éditeurs favoris sont Sublime Text et parfois Visual Studio Code avec les snippets et extensions qui me facilitent la vie au quotidien.
Depuis quelques temps, j’utilise Git et Gulp en ligne de commande, j’ai mis beaucoup de temps à m’y faire car ce ne sont pas des interfaces graphiques.
Il m’arrive d’utiliser des logiciels comme Prepros pour compiler mes CSS sur mes projets personnels. Les éditeurs de texte et tableurs ainsi que VoiceOver font aussi partie de mes outils pour mes audits d’accessibilité.

Le site web sophie-drouvroy.com

(A) Peux-tu nous parler de ton rôle à Paris Web ? Comment l’accessibilité a-t-elle réussi à s’imposer dans ce genre d’événement de grande envergure ?

(SD) J’ai découvert Paris Web en 2008 parce que mon conjoint y allait et pas moi. La baseline de l’association est : « design, standards du web et accessibilité » et j’ai écrit au staff que j’étais au regret de ne pas pouvoir participer car ce n’était pas accessible pour moi. L’équipe a tout mis en œuvre pour que l’accessibilité totale soit mise en place (vélotypie et interprétation LSF, programme en braille).
Le jour où j’ai pu venir à Paris Web, c’était la deuxième édition accessible.
Je suis actuellement Secrétaire de Paris Web et j’ai en charge l’accessibilité de l’événement depuis 4 ans maintenant. C’est un poste qui demande du travail avant, pendant et après l’événement avec la mise en place d’une préparation du terrain pour les équipes qui rendent accessibles les contenus. Je suis heureuse de voir aujourd’hui que nous avons un public sourd et malentendant.

(A) Le web a beaucoup évolué depuis que le grand public y a accès : la surdité était-elle moins handicapante à ses débuts lorsque le web était plus “statique”, sans tous les contenus audio/vidéo qui nous entourent aujourd’hui ?

(SD) On ne peut pas comparer le web « statique » et le web « riche en médias ». Pour les sourds, la vraie révolution du web, c’était la mise en relation d’abord par les mails, ensuite les messageries instantanées et enfin les réseaux sociaux. Moi avant le web, je n’avais que le Minitel pour communiquer. Pouvoir apprendre seule, c’est le web qui me l’a permis. Le web « statique » n’était pas mieux c’est comme si on disait que lire un livre c’est mieux que d’aller voir un film au cinéma. Moi, je veux pouvoir faire les deux ????
L’explosion des contenus vidéos et audios est tellement importante que la quantité de contenus accessibles augmente elle aussi mais la proportion en pourcentage reste trop faible. Nous avons plus de contenus accessibles aujourd’hui mais nous en avons beaucoup moins que les autres.

(A) La spécification HTML ou CSS (ou autre) de tes rêves ce serait quoi ?

(SD) J’aimerais qu’on arrête de demander à l’intégrateur web (ou développeur front-end) d’avoir les compétences d’un développeur alors qu’on demande pas forcément l’inverse.

(A) Est-ce qu’il y a quelque chose de neuf dans ta vie professionnelle ou dans le web que tu aimerais nous partager/dont tu aimerais faire la promo parce que ça te tient à cœur ? Des initiatives ? Des projets ?

(SD) Depuis mon opération, un nouveau monde s’ouvre à moi : celui de la musique. C’est nouveau pour moi, je viens de découvrir qu’elle pouvait m’aider à me concentrer.
Sur Twitter, j’ai lancé le hashtag #musicOnEar pour pouvoir la découvrir. L’idée au départ était de provoquer des discussions avec les personnes qui me suivent. Mon répertoire musical était vierge, il s’enrichit de jour en jour grâce à ce hashtag. Et finalement, je vois que certains enrichissent leur playlist aussi. J’aime beaucoup cette notion de partage.

(A) Et enfin... Tu préfères un dîner en tête à tête avec Trump ou devoir utiliser IE6 pour le restant de ta vie ?

(SD) Ni l’un, ni l’autre. Je suis libre, moi !

Merci encore pour avoir pensé à moi,
Sophie

Merci à Sophie d'avoir été notre crash test et de nous avoir parlé d'accessibilité.
Vous le savez sans-doute, chez Alsacréations nous accordons beaucoup d'importance à la thématique de l'accessibilité, et c'est donc avec plaisir que nous voyons les choses évoluer dans le bon sens.
Vous avez des questions sur l'accessibilité ou sur notre interviewée ? C'est dans les commentaires que ça se passe.

Publié par Alsacreations.com

Dans le but d'étoffer nos propositions de contenus originaux et de ne pas être les seuls à donner notre avis via nos articles, Alsacréations a décidé de donner la parole à des professionnel·le·s du Web au travers de courtes interviews permettant de découvrir des profils aussi différents qu'intéressants. L'idée derrière cette initiative est de parler d'actualité, découvrir de nouveaux horizons, mais également de donner de la visibilité à certaines pratiques, parfois trop peu mises en avant. Sophie Drouvroy a eu la lourde responsabilité d'être notre première invitée et Florens Verschelde est donc notre deuxième interviewée.

Notre choix n'est évidemment pas anodin car Florens compte parmi les membres (et modérateurs) les plus anciens du forum d'Alsacréations, mais également parmi les plus prolixes et serviables : toujours prête à faire avancer les discussions et apporter les réponses les plus adaptées (et détaillées) aux divers problèmes HTML, CSS ou de typographie rencontrés. Florens demeure encore aujourd'hui une figure emblématique de notre forum.

(Alsacréations) Peux-tu te présenter en quelques mots ?

Je m’appelle Florens (prononcé comme Florence), j’ai 35 ans et je vis dans les alentours de Lyon. Professionnellement, je travaille dans le Web depuis 13 ans et je suis “lead front-end developer” pour Kaliop, une agence web et mobile située à Paris et Montpellier.

Depuis un an et demi je contribue aussi au design et au développement des Developer Tools de Firefox, surtout côté CSS et ergonomie. C’est une expérience intéressante de participer à un projet logiciel complexe et déployé à des millions d’utilisateurs.

(Alsacréations) Quel est ton parcours ?

Pendant ma licence de Lettres je ne savais pas trop vers quel métier me diriger, et je m’intéressais à la typographie, à la PAO et au design graphique. Mais aussi à des trucs un peu obscurs comme la littérature expérimentale hypertextuelle. À cette époque, ce qui m’a fasciné avec le Web c’est de pouvoir publier quelque chose soi-même, accessibles dans le monde entier, sans passer par des intermédiaires comme un éditeur ou un journal. Aujourd’hui ça parait complètement banal, mais à l’époque c’était un gros changement culturel.

Côté formation ça a été autoformation à 99%, en tout cas sur la technique. J’ai fait une licence pro en communication web pendant un an, et j’y ai découvert plusieurs concepts et métiers, mais pour la technique c’était plutôt les ressources en ligne : spécifications HTML et CSS, Pompage, Position Is Everything, Openweb et Alsacréations. L’autre chose très formatrice pour moi ça a été de répondre à quelques milliers de questions sur les forums d’Alsacréations, ce qui m’amenait à me pencher sur cas techniques que je n’avais pas encore rencontré.

J’ai été freelance et bossé en agence web, principalement sur de l’intégration mais aussi sur de la gestion de projet, de la formation, du design fonctionnel. Depuis cinq ans je me concentre sur l’intégration web et le développement JavaScript.

(Alsacréations) Quels sont tes outils de travail au quotidien ?

J’aime bien dessiner des wireframes au feutre sur des carnets. J’aime beaucoup Figma pour travailler sur des icones et SVGOMG pour optimiser les SVG. Quand j’ai besoin d’un éditeur bitmap pour des tâches simples, Acorn fait mon bonheur. Je fais aussi beaucoup de captures d’écran (sur mac ou depuis la console de Firefox) pour communiquer avec équipes et clients. Et j’ai un petit faible pour les dictionnaires en ligne (WordReference, CNRTL, Lexico…), sans doute un reste de mes années de fac !

Côté développement, j’utilise VS Code ou PhpStorm pour l’édition de code (mais je sais aussi comment quitter vim !), et j’aime bien les DevTools de Firefox, WebPageTest, RegExr, WebAIM Contrast Checker, Richard Ishida's Unicode code converter. Oh, et le plus important : DevDocs qui me sert d’interface pour lire rapidement les documentations CSS, HTML et JavaScript de MDN.

Je suis assez familière de la ligne de commande, c’est mon côté nerd qui a beaucoup utilisé Linux. J’ai fini par bien m’habituer à Git et Mercurial, et j’utilise pas mal d’outils qui viennent de l’écosystème Node.js (BrowserSync, npx serve, des extensions de langages comme Babel, TypeScript ou Sass, ou des outils de build comme gulp ou webpack. Mais même si ces outils ne me font pas peur, je trouve qu’on manque d’outils intégrés permettant de coder ou même de designer dans un environnement technique qui «juste marche».

(Alsacréations) Quel est le langage ou la technologie qui t’attire(nt) le plus aujourd’hui ?

Côté Web, j’aime beaucoup le framework Svelte, qui ressemble un peu à Vue.js mais en encore plus minimaliste et léger. Je l’ai utilisé pour un projet perso, une mini application de quiz pour étudiant·e·s, et c’était une bouffée d’air frais par rapport à React (que j’aime bien malgré tout).

Un exemple du framework Svelte en action

Je regarde aussi ce qu’il se passe pour le développement d’interfaces en dehors du Web, en partie parce que le Web ne se porte pas si bien, et travaille pas mal avec React Native. Flutter et SwiftUI ont l’air intéressants, mais le premier a l’air un peu léger sur l’accessibilité et le second sert à faire des applications pour la plage privée d’Apple — ça me freine un peu.

(Alsacréations) Le forum te compte parmi ses premiers membres. Comment as-tu vécu l’évolution du web ces dernières années, depuis l’époque où l’enjeu était surtout de ne plus concevoir les sites avec des tableaux ?

C’est sûr qu’au début de ma carrière la question majeure côté intégration c’était la compatibilité : qu’est-ce qu’on peut faire ou pas, que ça soit pour la mise en page ou pour les effets visuels. Je trouve que cette question est devenue moins importante ces cinq ou six dernières années, avec des versions d’IE plus potables, tous les navigateurs “evergreen”, et des navigateurs mobiles parfois frustrants (vive les bugs à répétition de Safari !) mais quand même très puissants.

Il y a eu une époque où les enjeux se sont déplacés du côté du Responsive, et où on a parfois eu du mal à faire simple ! Je me souviens de projets ubuesques où chaque maquette était fournie en 4 formats, avec des composants réordonnés et transformés d’un format à l’autre, et d’autres avec une maquette en 1920×1080 et débrouille-toi pour adapter. Le côté positif, c’est qu’on a pas mal gagné en maturité sur les techniques Responsive, sur les méthodes de développement avec Git et le concept de découpage des interfaces en composants, sur la méthodologie avec BEM par exemple.

Ces dernières années, j’ai moins travaillé sur des sites d’information et de plus en plus sur des applications web ou mobiles. Mais je ne sais pas si c’est une évolution du Web ou juste celle des projets de ma boite.

(Alsacréations) Comment envisages-tu le futur de CSS ou de l’intégration en général ? (on pense notamment à CSS-in-JS)

Pour les CSS dans le JavaScript, c’est plus un symptôme de ce qu’il se passe depuis quelques années. Je n’ai rien contre ces outils, moi ça ne me gêne pas d’utiliser styled-components ou CSS Blocks, pas plus que Sass ou d’autres. Mais ça fait partie d’une tendance générale à empiler des couches techniques les unes par dessus les autres, qui correspond mieux aux schémas mentaux des développeurs·euses «classiques» que des intégrateurs·trices.

On se retrouve avec des projets où pour participer sur les styles ou l’accessibilité il faut pouvoir utiliser Git mais aussi Docker, maitriser JavaScript et React, configurer webpack, et écrire les styles dans une syntaxe JavaScript ou en pseudo-CSS. C’est quand même beaucoup d’obstacles pour des gens qui connaissent peu ces outils mais ont une expertise sur le HTML et l’accessibilité, le CSS, les navigateurs web, etc. Je parle régulièrement avec des gens qui faisaient de l’intégration web principalement ou en plus d’autres missions, et qui se sont rabattus sur du design ou de la gestion de projet car l’environnement technique devenait trop «pour et par les devs».

Je ne sais pas comment ça va évoluer, mais en tout cas je m’intéresse à tout ce qui tire un peu dans le sens inverse : permettre à des designers et/ou intégrateurs·trices de produire des choses sans être bloqué par plein de couches techniques. Peut-être une simplification des frameworks JS pour que le JS s’efface autant que possible, comme dans Svelte ? Est-ce qu’il faut forcément coder, ou bien est-ce que la manipulation directe comme dans Webflow ne fonctionnerait pas mieux au final ? Est-ce qu’on peut mélanger code et manipulation directe, pour bosser ensemble avec plusieurs profils ?

Le compte Twitter de Florens

(Alsacréations) Si tu avais à former un·e débutant·e en HTML et CSS, sur quels thèmes insisterais-tu particulièrement ?

Pour moi le plus important serait de rattacher HTML et CSS à un objectif plus large. Quand j’ai fait de la formation il y a 10 ans, j’avais une approche très linéaire, HTML et sémantique d’abord puis CSS ensuite, etc. Avec le recul je trouve ça un peu formel et pas très motivant.

Avec des débutant·e·s en développement web voire en développement tout court, j’insisterais sur l’idée de créer quelque chose. Dans ce cadre, HTML et CSS ne sont que deux outils sur cinq ou 6. On peut bosser sur plein de sujets : de l’animation, des ébauches d’application multimédia (par exemple une application pour générer des sons ou de la musique), une galerie de photos, mettre en page un poème ou une tablature de guitare, etc. L’important serait de publier le résultat (par exemple sur GitHub Pages, Netlify, ou en codant directement sur Glitch) et le partager à quelques personnes : voilà ce que j’ai fait.

Avec un public de développeurs·euses qui a déjà une formation initiale en développement “backend” mais très peu d’expérience en UI, le risque principal c’est le découragement car CSS est un domaine à part. Les compétences déjà acquises en Java, PHP, Python ou SQL ne se transfèrent pas vraiment à l’apprentissage de CSS (Miriam Suzanne, Why Is CSS So Weird?). Et si on n’a pas anticipé ce problème, on peut se retrouver en pleine dissonance cognitive (Natalya Shelburne, CSS at the Intersection) et abandonner.

Du coup, s’il faut se familiariser avec un nouveau domaine et une culture de design et d’ergonomie, pourquoi ne pas enseigner directement ces concepts de design, en utilisant CSS comme un exercice d’application ? Et enseigner directement des bases d’accessibilité, en utilisant HTML pour la mise en application ? En somme, viser un résultat plutôt qu’enseigner un langage.

(Alsacréations) Viendras-tu à la KiwiParty 2020 ? :p

S’il fait beau et que les trains ne coutent pas un salaire de député européen, carrément ! (NDLR : il fait toujours beau à Strasbourg)

(Alsacréations) Question Bonus : Sais-tu pourquoi les gens qui s’aiment sont toujours un peu les mêmes ?

Alors là William je t’avoue que je sèche. J’ai donc demandé autour de moi et voici les réponses que j’ai eu :

1. Sharon m’a dit que c’est parce qu’à chaque fois que le soleil se lève elle a des ennuis. J’ai pas vu le rapport donc j’ai demandé à Bruce.
2. Bruce m’a dit que c’est parce que les gens qui s’aiment sont nés aux USA pour courir sur la route du tonnerre. On est d’accord que ça veut rien dire ?
3. Nick m’a dit que tout ça c’est de la bouse bébé, c’est bien connu que les gens valent pas tripette.

(La première personne qui trouve les 6 références gagne mon stock de kiwis.)

Publié par Alsacreations.com

Au sein d'Alsacréations, nous donnons aussi des formations d'Initiation HTML & CSS et, parfois, nos apprenants nous posent quelques questions à propos de notre processus en matière de design. Puisque le sujet est vaste et les possibilités de réponses bien trop nombreuses pour être abordées en cours, nous avons fait le choix de publier cet article afin de répondre aux interrogations les plus courantes.

Il s'agira donc d'une succession de questions-réponses avec quelques liens et illustrations afin de vous guider sur le chemin tortueux du webdesign ;)

Cet article illustre le processus de création graphique qui est le nôtre, au sein de l'agence Alsacréations. Nous n'avons pas pour prétention d'affirmer que notre méthodologie est idéale dans tous les contextes, celle-ci est adaptée à nos projets. Nous espérons toutefois que, quel que soit votre environnement, ces recettes vous permettront de prendre du recul sur les différentes façons de travailler et de découvrir d'autres techniques.

Nous on fait nos maquettes sur Photoshop mais du coup tout est en pixel. Comment faire du responsive ?

Eh bien, pour commencer, je vous invite à lire ou relire notre article sur « les 8 bonnes raisons d'abandonner Photoshop ». Un titre un peu racoleur je vous l'accorde, mais vous y trouverez déjà de nombreuses réponses sur la problématique de la production en pixel et de la gestion du responsive !

Pour résumer brièvement, on réserve Photoshop au traitement des images en pixel (donc tout ce qui est édition d'images et/ou de photos), et on migre sur un logiciel entièrement dédié à la création de maquettes web (en vrac, par exemple : Sketch, Figma, Adobe XD...). Ces logiciels proposent de nombreux outils afin de gérer le responsive plus facilement, notamment grâce aux fonctions de redimensionnement qui permettent de modifier un composant sans perdre les informations qu'il comporte (ex : marges intérieures identiques, objet ancré en haut à droite...).

En bref : go sur un logiciel de création web !

Quelle est la bonne taille d'une maquette ? Combien de maquettes de taille différente doit-on produire ?

Celle qui vous convient !

Plus sérieusement, il n'y a pas de « bonne taille ». Avec le responsive, cela n'a plus de sens de produire des maquettes d'une taille fixe.

Une approche plus judicieuse est de définir les « breakpoints » (point de rupture) de vos designs, c'est à dire la taille à partir de laquelle votre site change d'apparence. Ça peut être, par exemple, un full menu qui se transforme en menu hamburger, une ligne de 5 articles qui passe à 3, etc.

Il faut bien sur considérer les spécificités de votre design (Le contenu est-il plein écran ? Si oui, une maquette supérieure à 1400px peut s'avérer utile) ainsi que les contraintes techniques de votre cahier des charges. Quels devices sont supportés ? Certains téléphones sont très petits et peuvent nécessiter un breakpoint supplémentaire. Quelle doit être la résolution minimum assurée ? Et au contraire, la maximum autorisée ? Sur quel design s'arrêter lorsque le minimum et le maximum sont atteints ?

Par exemple, un menu placé à côté d'un logo devra avoir un breakpoint spécifique dès que les items de menu risquent de chevaucher le logo. Ce n'est pas forcément lié à un device particulier, mais plutôt à l'environnement disponible (que se passe-t-il si l'utilisateur augmente la taille de police, par exemple ? Ou s'il rajoute un item de menu ?). On réfléchit plutôt en terme de d'emplacement et d'environnement que de device à proprement parler, les tailles d'écrans changeant d'un support à un autre.

Il faut aussi savoir faire la part des choses : faire 6 maquettes de taille différente est superflu, mais n'en faire qu'une ne sera pas suffisant pour votre intégrateur (ou alors vous lui faites entièrement confiance).

En bref  : On définit les breakpoints et on choisit des tailles adaptées à l'environnement et aux contraintes qu'il apporte.

Comment transmettre les infos du designer à l'intégrateur ? (fonts, couleurs, tailles...)

Là encore, plusieurs solutions existent, et vous pouvez tout à fait les « mixer » entre elles pour créer votre propre popotte.

Le plus simple est de communiquer en direct avec votre intégrateur lors d'un petit entretien en tête-à-tête pour lui expliquer votre vision des choses (« et là, le fond explose comme un feux d'artifice pour laisser apparaître la phrase d'accroche ! » « euh... »).

Vous pouvez aussi annoter vos maquettes, en les imprimant et en notant à la main, directement sur vos maquettes afin de les exporter, ou bien encore en utilisant un service tel qu'Invision afin de partager vos exports en ligne et de les commenter. Le bonus, c'est que votre intégrateur pourra répondre directement à vos commentaires ou en créer de nouveaux s'il a d'autres questions. Vos maquettes pourront être mises à jour directement sur Invision afin de palier aux remarques de votre consoeur ou confrère !

Autres services similaires à Invision : MarvelApp, Affinity, Lunacy...

Enfin, il est aussi possible de créer un « Styleguide », ou guide de style. Il s'agit d'un document (sous forme d'image ou intégrée sous forme d'un mini site web) résumant les différents composants graphiques de votre maquette. Couleurs, fonts, boutons, formulaires, cards, mais aussi des règles plus générales comme le ton du texte, l'espacement et la gestion du blanc, ou encore la patte graphique des images. Ce document sera partagé avec vos intégrateurs mais servira aussi de référence pour de futures modifications du site web, pour une déclinaison print ou pour un agrandissement de la marque cible ; il permet de garder une cohérence entre tous les supports.

En bref : Communiquer en direct, annoter (sur papier, sur maquette, avec un service web adapté) ou créer un Styleguide.

Comment transmettre les scénarios d'un composant ? Par exemple, comment expliquer les différentes « versions » d'un menu sur ordinateur et sur mobile ?

Les différentes tailles de maquettes, avec les break-points, sont un bon point de départ. L'intégrateur pourra visualiser les différences entre chaque version, du mobile au desktop, par exemple.

Si votre transition est plus compliquée, avec une animation par exemple, vous pouvez soit la décrire oralement ou dans une annotation, soit la retranscrire avec un logiciel adapté (Sketch, Figma, Invision Studio, Adobe XD, Affinity, voir After Effect...). Vous pouvez également rechercher un bout de code existant ou un site utilisant le même type d'animation comme référence ! N'hésitez pas à communiquer en direct avec votre intégrateur pour être certain que vous partagez tous deux la même vision.

En bref : Maquettes, animation, communication !

À quoi ressemble le cheminement d'un design, de la première idée à l'intégration ?

L'histoire sera différente pour chaque designer, chaque agence et chaque client, mais pour simplifier, cela ressemble à quelque chose comme ça :

1. Créer un Moodboard (planche de tendances) avec des inspirations diverses : couleurs, images, fonts, mots-clefs, icônes, screens…
2. Griffonner sur papier ou sur écran
3. Créer un Mockup (maquette simplifiée) avec un logiciel de design web, ou un logiciel de mockup : Mockplus, Moqups, Balsamiq, Proto.io…
4. Ajouter la surcouche graphique ou, autrement dit, créer la Maquette !
5. La partager (avec Invision, par exemple), récolter des commentaires, faire des allers-retours de correction, jusqu'à ce que la version finale soit validée
6. Créer un Styleguide (guide de style) pour guider votre intégrateur dans son travail et lâcher votre bébé dans la nature !

(Psst… Si vous voulez apprendre à intégrer cette maquette, c'est possible avec notre formation Initiation HTML & CSS)

Un bon design workflow, c'est aussi le vôtre

Tout ce que nous avons évoqué ici ne sont bien sûr que des conseils.

C'est à vous qu'il revient de créer votre propre workflow, de trouver les outils avec lesquels vous vous sentez à l'aise, et de trouver la façon la plus efficace de travailler avec votre équipe.

Et vous, quelles sont vos méthodes ? :)

Retrouvez l'intégralité de ce tutoriel en ligne sur Alsacreations.com

Dans le but d'étoffer nos propositions de contenus originaux et de ne pas être les seuls à donner notre avis via nos articles, Alsacréations a décidé de donner la parole à des professionnel·le·s du Web au travers de courtes interviews permettant de découvrir des profils aussi différents qu'intéressants. L'idée derrière cette initiative est de parler d'actualité, découvrir de nouveaux horizons, mais également de donner de la visibilité à certaines pratiques, parfois trop peu mises en avant.

Qu'on le connaisse sous son nom de ville ou son pseudo, il a été difficile de passer à côté de la sortie de son dernier outil : Can I email tant il a fait grand bruit dans la communauté web mondiale. Nous vous proposons donc de discuter intégration de mail (mais pas que) avec son créateur aux multiples facettes : Rémi Parmentier, alias HTeuMeuLeu.

(Alsacréations) Peux-tu te présenter en quelques mots ?

Je m'appelle Rémi Parmentier, j'ai 34 ans et je suis intégrateur depuis 2006. En ligne, je suis surtout connu sous le pseudonyme de HTeuMeuLeu. Et aussi pour régulièrement partager mon amour pour l'intégration d'e-mails.

(Alsacréations) Peux-tu nous parler de Caniemail ? D’où est venue l’idée ? Quel est l’historique ? Quelle a été la réponse des utilisateurs face à cet outil ?

Caniemail est un site proposant des tableaux de compatibilité de propriétés HTML et CSS dans les clients mail. L'idée est clairement venue de caniuse.com qui, en l'espace de quelques années, est devenu une référence incontournable dans le développement Web.

Historiquement, c'est le développeur Mark Robbins qui a révélé en 2015 lors d'une conférence que sa boîte travaillait sur le projet sous le nom de caniemail.com. Deux ans après, je me suis rendu compte que le nom de domaine avait été abandonné. Mon premier réflexe a été de le racheter pour éviter qu'il ne tombe entre de mauvaises mains. J'ai proposé à Mark de reprendre le domaine pour qu'il puisse continuer le projet, mais ça n'a jamais abouti. J'ai conservé le domaine, sans trop savoir quoi en faire. Et c'est en 2019 où je me suis posé un ultimatum : si caniemail ne sort pas dans l'année, alors c'est que le projet n'était pas voué à exister. En mars, j'ai ouvert un dépôt sur GitHub où j'y ai noté quelques idées et envies pour le site. En septembre, j'ai annoncé officiellement l'ouverture du site.

La réponse a été globalement très positive et le site a été partagé un peu partout à sa sortie. En fait, le site a tellement dépassé les frontières habituelles du développement Web que les premiers jours, de nombreuses personnes se plaignaient de l'inutilité du site. En lisant des commentaires, j'ai compris que plein de gens cherchaient des noms de célébrités (comme Barack Obama ou le Pape), pensant que le site leur donnerait une adresse e-mail de contact. En rajoutant un placeholder précisant "HTML, CSS" et un message de recherche infructueuse plus explicite, ces recherches sont rapidement tombées à zéro.

La page d'accueil de Can I email

(Alsacréations) Pourquoi t’es-tu spécialisé dans l’intégration de mail ?

J'ai fait toute ma carrière en agence, et l'intégration d'e-mails fait partie du boulot récurrent. Quand j'ai commencé à travailler dans le Web, on faisait encore des sites en tableaux (et donc les e-mails aussi). C'est à partir de 2007 où les choses ont changé. D'un côté, on a Apple qui a sorti l'iPhone et bouleversé le Web et les emails en les rendant mobiles. Et de l'autre, on a Microsoft qui a adopté Word comme moteur de rendu pour Outlook sur Windows, figeant pour toujours l'intégration d'e-mails à des tableaux. Et je crois qu'en fait c'est ce grand écart que j'aime bien. Comment arriver à faire des choses propres et modernes en profitant de toutes les possibilités offertes par un client mail comme Apple Mail tout en supportant à côté un dinosaure comme Outlook 2019 ?

J'aime aussi vraiment le côté « explorateur » du métier. Pour comprendre le fonctionnement de certains clients mails et arriver à trouver des solutions, j'ai parfois l'impression d'être le premier être vivant à explorer ces contrées.

(Alsacréations) Dans une autre vie, quel métier tu aurais aimé exercer ?

Moine copiste ou scribe, pour le côté « intégrateur du moyen-âge ». Mais je ne sais pas si c'est une bonne situation, ça.

(Alsacréations) Quelles sont les spécificités des clients mails qui t’ont le plus étonné ou désespéré ?

L'an dernier, je me suis rendu compte d'un comportement particulier de l'application Mail d'Orange sur Android. J'ai toujours pensé que cette application ne supportait pas les balises <style>. Mais en testant certains e-mails, je voyais bien que parfois oui, parfois non. En fait, l'application ne supporte pas les règles CSS précédées par une tabulation. Donc si on indente son code avec des tabulations, c'est ignoré. Mais si on utilise des espaces, tout va bien.

Plus généralement, je désespère de voir des clients mails sortir des nouvelles fonctionnalités semblant n'avoir jamais été testées sur des vraies newsletters. Par exemple, depuis quelques mois, Gmail teste un mode sombre qui altère le rendu des e-mails sur mobile. Sauf que leur algorithme est complètement foireux et donne des textes en gris sur gris la plupart du temps. Alors qu'à côté, il y a une vraie communauté d'intégrateurs et d'intégratrices spécialisé(e)s dans les e-mails (sous le mot-dièse #emailgeeks sur Twitter ou sur Slack) qui ne demande qu'à aider et à améliorer les choses. Mais les clients mails continuent d'opérer comme des boîtes noires, sans jamais chercher à contacter le monde extérieur.

(Alsacréations) Que penses-tu de l’intégration de microdonnées schema.org dans les mails ?

C'est cool. Gmail fait ça depuis 2013 et Microsoft a suivi le pas un peu plus récemment avec les Adaptive Cards. Mais encore une fois, ils n'ont pas été capables de s'entendre et de s'accorder sur un format standard, et on se retrouve avec différentes syntaxes pour faire la même chose. Ah tiens, je crois qu'on peut rajouter ça aussi à la liste des choses qui me désespèrent.

(Alsacréations) Qu’attends-tu/qu’espères-tu de l’avenir dans le monde des clients mail ?

J'espère plus d'ouverture de la part des clients mails pour enfin s'intéresser à l'élaboration d'un standard commun. Mais en bon pessimiste, je ne m'attends à pas grand chose.

(Alsacréations) Penses-tu que les webmails vont totalement remplacer les clients mail “lourds” tels que Thunderbird ou Outlook ?

Je pense surtout qu'il y a une vraie différence entre mobile et desktop. Sur desktop, les webmails prennent clairement le dessus. Même Microsoft est en train de pousser Outlook.com en tant que Progressive Web App. Mais à l'inverse, sur mobile, les webmails sont quasiment tous délaissés par leurs constructeurs au profit d'applications natives. (Le webmail mobile de Gmail par exemple est une véritable antiquité.)

Le compte Twitter de HTeuMeuLeu

(Alsacréations) Quelle serait ta destination de rêve pour des vacances ? Bonus : sais-tu où partent les geeks en vacances ?

J'ai une préférence pour les destinations citadines. (J'habite à la campagne, donc si je pars en vacances à la campagne, je ne suis pas trop dépaysé.) Et les geeks partent aux Maldives ou dans les îles Java, bien entendu. (NDLR : La réponse attendue était "aux C-shell", mais, dans notre grande bonté, nous acceptons également celles-ci.)

Publié par Alsacreations.com

N'avez-vous jamais rêvé de réaliser une superbe page d'intro animée pour votre site web ? Mettre en exergue votre produit phare grâce à une animation très élaborée ? Faire suivre à vos liens de navigation une trajectoire alambiquée ?

Pour répondre à ces besoins modernes, le module CSS "Motion Path Module Level 1" introduit la possibilité à des éléments HTML de suivre un parcours défini et ouvre la voie à de nouveaux types d'animations CSS totalement inédits.

Compatibilité

Commençons d'emblée par les sujets qui fâchent et ôtons tout optimisme aux fans de Safari (OS X et iOS) et d'Internet Explorer (s'il en reste) : les propriétés du module "Motion Path" ne sont pas encore supportées par tous les navigateurs.

Ceci dit, à l'heure où ce tutoriel est rédigé, près de 75% de vos visiteurs sont en mesure de bénéficier de cette technologie récente.

Prenez bien garde à ce que ce type d'animation n'apporte que du bonus et ne soit pas indispensable à la compréhension et l'utilisation de vos pages web.

Les propriétés de Motion Path

Pour rendre opérationelles ces animations, trois mécanismes entrent en jeu :

• Un chemin que l'élément doit suivre (propriété offset-path)
• La position de l'élément sur le chemin (propriété offset-distance)
• la rotation de l'élément lors de son parcours (propriété offset-rotate)

offset-path

La propriété principale de tout ce dispositif est offset-path et autorise de multiples valeurs : path();, ray();, url();, circle();, polygon();, inset();, none;.

À ce jour la seule valeur reconnue par la majorité des navigateurs est path(), nous allons donc nous concentrer sur cette valeur uniquement dans ce tutoriel.

Les valeurs contenues dans offset-path sont directement héritées du langage SVG. Des notions basiques en SVG, ou des logiciels de dessins vectoriels sont donc un pré-requis nécessaire pour maîtriser les animations décrites dans cet article.

Vous le savez sans doute, SVG est un format de dessin vectoriel permettant de dessiner les formes basiques telles que les lignes, courbes, cercles, arcs et autres. Les chemins sont créés en combinant plusieurs de ces formes.

Voici par exemple comment tracer un trajet carré que pourrait suivre un élément div :

div {
  offset-path: path('M10 10 H 180 V 180 H 10 Z'); /* ceci est un chemin carré, si si */
}

L'objectif de ce tutoriel n'est pas d'explorer le langage SVG. Pour plus d'infos sur les syntaxes employées ici, je vous réfère à cette excellente traduction de la Cascade ou encore aux explications détaillées de MDN.

offset-distance

La propriété offset-distance, quant à elle, définit la position de l'élément sur le chemin.
Elle peut être exprimée dans toutes les unités classiques (pixel, rem, %, etc.) et devient particulièrement intéressante dès lors qu'on souhaite animer l'objet le long du trajet :

div {
  animation: move 1s; /* je vais suivre l'animation "move" durant 1s */
}

@keyframes move {
  0% { 
    offset-distance: 0%; /* je commence au début du trajet */
  }
  100% { 
    offset-distance: 100%; /* je finis à la fin du trajet */
  }
}

Voir la démo

offset-rotate

Enfin, la troisième propriété du dispositif, offset-rotate, permet de définir l'orientation de l'objet lorsqu'il suit les courbes du parcours :

• auto (valeur par défaut) : indique que l'objet va suivre l'orientation du chemin. C'est généralement la valeur souhaitée.
• reverse : l'object va également respecter l'orientation du parcours mais en étant tourné de 180 degré, il sera donc toujours dos au parcours.
• Xdeg (ex. 30deg) : l'élément ne suivra plus la rotation de la courbe mais conservera un angle figé durant tout son trajet.
• auto Xdeg (ou reverse Xdeg) : l'élément suivra l'orientation de la courbe avec un décalage de X degrés.

Voir la démo

Rendre le parcours visible

Vous avez sans doute remarqué que la trajectoire parcourue par votre objet n'est pas tracée à l'écran. C'est bien dommage, et surtout, cela se semble pas prévu dans les spécifications CSS.

Pour pallier ce manque, il va être nécessaire de nous trouver un autre allié. Ce sera au tour de SVG de "dessiner" le chemin (puis de le superposer avec celui suivi par l'objet).

Des path(), des <path>, oui mais des Panzani !

Rappelez-vous de la forme carrée parcourue par notre objet <div> :

div {
  offset-path: path('M10 10 H 180 V 180 H 10 Z'); /* ceci est un chemin carré */
}

Notre mission est de reproduire exactement le même tracé en langage SVG. Car lui seul pourra être visible.

Dans le langage SVG, un tracé est dessiné via l'élément <svg>, parent de <path> lui-même assisté de son attribut d.

Ainsi, notre carré s'écrit tout simplement de la sorte en SVG :

<svg ...>
  <path d="M10 10 H 180 V 180 H 10 Z" fill="none" stroke="gray" />
</svg>

Notez que la plupart des attributs graphiques SVG peuvent être modifiés via CSS, nous pourrions donc écrire dans la partie HTML :

<svg class="svg-path" width="200" height="200" xmlns="http://www.w3.org/2000/svg">
  <path d="M10 10 H 180 V 180 H 10 Z">
</svg>

Et dans la feuille de styles :

.svg-path {
  stroke: gray;
  stroke-width: 4;
  fill: none;
}

Superposer (et voir) les chemins

La seconde étape est à présent de superposer les différents éléments en jeu et concrètement il nous faudra :

• Un bout de code SVG contenant le chemin dessiné avec l'élement <path> (ça c'est fait)
• Un objet qui suivra ce chemin via la propriété CSS offset-path (ça c'est fait aussi)
• Un conteneur qui contiendra ces deux éléments superposés grâce à des position: absolute

Voici plus concrètement ce dont nous aurons besoin :

<div class="motion-container">

  <svg class="svg-path">
    <path>
  </svg>

  <div class="motion-object"></div>

</div>

Et le CSS adapté :

/* overlay object on svg path */
.motion-container {
  position: relative;
}
.svg-path {
  position: absolute;
  left: 0;
  top: 0;
}

Voir la démo

Aller plus loin

Il est bien entendu possible d'étendre les possibilités de cette petite introduction aux animations avancées en CSS.

Vos seules limites risquent d'être votre imagination… et votre aptitude à dessiner en SVG. Pour vous aider, de nombreux outils tels que Sketch ou Inscape vous faciliteront grandement la tâche.

Cet outil en ligne est également très performant : https://editor.method.ac/

Voici une vidéo mettant en pratique l'ensemble des notions abordées dans ce tutoriel :

Voir la démo finale

Un point sur l'accessibilité

Vous vous en doutez : des contenus qui se déplacent sans qu'on leur demande ou alors même qu'on leur a demandé de ne pas bouger, c'est potentiellement une source de problèmes d'accessibilité pour vos visiteurs.

Pour répondre à ces deux cas de figures, envisagez les pistes suivantes :

1. L'un des critères du RGAA 4 demande à ce que le mouvement dure moins de 5s ou puisse être lancé et mis en pause ou que le contenu puisse être masqué et réaffiché ou que l'information puisse être affichée sans le mouvement.
2. La Media Query prefers-reduce-motion permet de prendre en compte le choix de l'utilisateur•trice pour ce qui concerne les animations sur son système d'exploitation.

Démos variées et conclusion

Pour vous donner envie de tester ces technologies, voici quelques-unes des meilleures trouvailles que j'ai pu faire sur Codepen :

• Le menu animé ayant servi d'introduction : https://codepen.io/alsacreations/pen/LYVMwYy
• Le chemin Hotdog : https://codepen.io/kloo012/pen/LpdJzz
• Les Frites : https://codepen.io/cobra_winfrey/pen/dZvNxg
• Un Preloader : https://codepen.io/rachelmcgrane/pen/aJPbae
• Un Bouton amoureux : https://codepen.io/kdzwinel/pen/vgjPZx
• Un Avion en papier : https://codepen.io/AliKlein/pen/qbJyGE
• Un Parcours automobile : https://codepen.io/Kseso/pen/jbaxJG

J'espère que cette approche des animations modernes en CSS vous a donné envie de tester chez vous, voire en production et d'en apprendre plus.

N'hésitez pas à commenter en nous partageant vos propres oeuvres ou celles que vous avez dénichées sur le Web !

Retrouvez l'intégralité de ce tutoriel en ligne sur Alsacreations.com

Que fais-tu "dans la vie" IRL actuellement, sur quoi travailles-tu ?

Dans ma vie professionnelle, je suis intégratrice web et consultante en accessibilité web. Et dans ma vie personnelle aussi puisque je continue sur mes projets personnels, quand je ne suis pas en train de cuisiner, de m’occuper de mon jardin, de faire des claquettes ou de rester à ne rien faire de spécialement intéressant sur mon canapé après une semaine de travail éprouvante.

J’essaye de travailler à rendre le web meilleur et notamment accessible aux personnes handicapées. C’est possible avec mon métier mais on est bien peu de chose face à l’immensité du web.

Quel est ton parcours, qu'est-ce qui t'a amenée au web ?

C’est une amie du collège qui m’a amenée au web en me montrant comment créer une page web avec du HTML et du CSS. Ça remonte à loin, quand on faisait encore des sites avec des <frame> et des <table>. Après, j’ai découvert quelques notions de PHP en cherchant à éviter d’utiliser les <frame> parce que c’était pratique au premier abord mais pas tellement satisfaisant ; une simple fonction include en PHP a été une révélation. Je faisais des petits sites tout pourris et sans grand intérêt mais j’adorais ça.

À la fin du lycée, je voulais faire de la photographie mais j’ai finalement choisi de faire une licence arts plastiques où il y avait des cours de photographie. En troisième année, il y avait une option « Création numérique » que j’ai choisie et on a aussi eu des cours de vidéo et de… HTML, CSS et SVG. C’était en 2010-2011 et SVG ne fonctionnait que sur Internet Explorer à l’époque. Pour un projet d’un autre cours, j’ai fait un site web et là, j’ai compris que c’était ça que je voulais faire professionnellement.

J’ai cherché une formation en alternance dans le domaine de la création de sites web. J’en ai trouvé une et j’ai galéré à trouver une entreprise. Une petite agence m’a finalement fait confiance puis m’a embauchée jusqu’à ce que je déménage à Nantes.

Tu te définis comme “intégratrice”. Que signifie ce terme en 2020 pour toi, sachant que le métier s’est considérablement diversifié, spécialisé, complexifié ?

J’avais écrit sur le sujet en 2017 et je suis toujours d’accord avec mon moi du passé. Oui, je suis intégratrice, je ne suis toujours pas développeuse front-end. J’ai vu passer des tentatives de renommage du métier pour que ce ne soit plus « intégrateur » ou « intégratrice » ni « développeur front-end » ou « développeuse front-end ». Pourquoi pas, si on trouve qu’un autre nom de métier serait plus parlant mais je n’ai pas vraiment vu de consensus, si ?

Mais effectivement, j’ai une spécialisation en accessibilité et, d’après ce que j’ai pu lire via des échanges sur Twitter, il semble difficile d’être seulement intégrateur ou intégratrice sans spécialisation ou bagage complémentaire : accessibilité, développement JavaScript ou autre. On le voit d’ailleurs dans les offres d’emploi même s’il y a quand même quelques entreprises qui recherchent vraiment des spécialistes de l’intégration. C’est quelque chose que je ne comprends pas vraiment car il y a de forts besoins de compétences en HTML et CSS qui manquent depuis toujours. On estime toujours que c’est tellement simple que n’importe qui peut le faire donc on laisse ce travail aux équipes de développement (front ou même back !). Et puis après, quand on fait les audits d’accessibilité, on pleure parce qu’il faut tout refaire. C’est désespérant.

Quel est le critère le plus simple à considérer en accessibilité numérique ? Le plus complexe à mettre en œuvre ?

Le plus simple, c’est sans doute de ne pas retirer l’outline des éléments interactifs (liens, boutons, éléments de formulaire…). Et pourtant, c’est ô combien compliqué à faire comprendre. Heureusement, il existe un script pour que l’outline n’apparaisse qu’au clic clavier et non pas au clic souris ; ça permet de négocier sans trop de difficultés. Il y a une sorte de traumatisme assez incroyable autour de la visibilité de la prise de focus.

Le site web a11y Paris où j'ai choisi de gérer un outline bien visible et contrasté par rapport au fond de page

Le plus complexe pourrait être le critère qui demande que les scripts soient accessibles aux technologies d’assistance. Il y a plein de documentation sur le sujet mais ça implique souvent d’utiliser les attributs ARIA, qui répondent à une spécification précise, et là, c’est la catastrophe car la plupart des gens les utilise en pensant bien faire mais sans être formée et en faisant donc n’importe quoi ; parfois, pire que mieux. On doit souvent rappeler la première règle d’ARIA : « Pas d’ARIA est mieux que du mauvais ARIA ».

Je pense qu’il ne faut pas hésiter à demander de l’aide à des personnes qui connaissent bien ces sujets. D’ailleurs, il arrive même que les personnes sachantes soient démunies face à certains besoins d’implémentation et doivent échanger entre elles pour trouver des solutions. Ça montre que tout n’est pas si simple même s’il y a, heureusement, des règles simples.

Quelle est ton astuce pour "tester" l'accessibilité des pages/applications web ? (sur un critère précis ou en général)

Mon astuce pour évaluer le niveau de catastrophe d’un site rapidement, c’est juste de regarder le code HTML mais je suis formée au sujet donc je trouve ce qu’il faut en un rien de temps. Quand il faut pousser plus loin, il y a de nombreux tests complémentaires et surtout, je m’appuie sur les règles du RGAA (Référentiel Général d’Amélioration de l’Accessibilité) et des WCAG (Web Content Accessibility Guidelines).

En revanche, pour les personnes qui ne maîtrisent pas trop le sujet, il y a des tests assez simples à faire pour vérifier le niveau d’accessibilité « de base ». Ça peut servir à vérifier ce qu’on a produit soi-même ou à vérifier ce qu’on nous livre quand on est de l’autre côté de la barrière.

Voici donc quelques tests basiques :

• Vérifier qu’on peut naviguer au clavier dans le site en utilisant uniquement la touche Tab (et Maj + Tab pour revenir en arrière) du clavier pour aller d’élément interactif en élément interactif : on devrait réussir à prendre le focus sur tous les liens, tous les boutons, tous les éléments de formulaires. Et, on devrait voir qu’on prend le focus sur ces éléments (généralement, il y a une bordure pointillée ou un halo qui se met autour de ces éléments). Ensuite, on devrait pouvoir activer les liens avec la touche Entrée, les boutons et les éléments de formulaire avec la touche Espace. Parfois, on navigue dans les éléments avec les flèches de navigation comme par exemple, après avoir coché un champ radio avec Espace, on navigue entre les autres champs radio avec les flèches.
• Cliquer sur les libellés des champs de formulaire : ça doit déplacer le focus dans le champ concerné ou cocher les checkbox et radio.
• Vérifier que le code HTML est valide avec le validateur sur le site du W3C. Même si, pour l’accessibilité, certaines erreurs n’auront pas d’impact, beaucoup en auront donc, dans le doute, je pense qu’il vaut mieux corriger toutes les erreurs ; ça donnera un code plus propre et ça évite de se poser trop de questions. Les problèmes les plus fréquents sont l’utilisation d’identifiants dupliqués ou encore la mauvaise utilisation d’ARIA. Ces problèmes créent des difficultés ou des impossibilités de navigation pour les personnes aveugles, notamment, qui utilisent un lecteur d’écran (logiciel qui restitue le contenu d’une page web, d’un logiciel, etc.).
• Vérifier que la hiérarchie de titres est cohérente avec l’extension de navigateur HeadingsMap (pour Firefox, ou pour Chrome) : pas de sauts de titre (on ne passe pas d’un h2 à un h4), pas de texte marqué comme un titre alors que c’est juste un texte qu’on a voulu écrire plus gros ou pas de texte qui devrait être un titre mais n’en est pas un…
• Vérifier que quand on zoome le site à 200 %, il n’y a pas de perte de contenu ou de fonctionnalité et qu’il n’y a pas d’éléments qui se chevauchent, sont masqués à moitié, etc. Il y a une tendance à masquer des contenus en mobile avec le responsive. Pour l’accessibilité, les contenus peuvent être présentés différemment mais ne doivent pas disparaître car, quand on zoome à 200 %, on arrive sur la version mobile.
• Vérifier que les espacements des caractères, des lignes, des mots et des paragraphes peuvent être redéfinis par les utilisateurs et utilisatrices sans que cela provoque des pertes de contenus ou de fonctionnalités. Avec l’extension Stylus, il faut créer un style avec ce code pour le vérifier :

* {
    line-height: 1.5 !important;
    letter-spacing: 0.12em !important;
    word-spacing: 0.16em !important;
}
p {
    margin-bottom: 2em !important;
}

• Enfin, on peut aussi lancer des extensions ou des sites qui vont tester certaines règles automatiquement. C’est loin de tout couvrir mais ça peut bien aider aussi. Pour citer quelques outils, il y a, par exemple : a11y.css, Accessibility Insights, AccessLint (pour vérifier les « Pull requests » dans Github), axe, Tanaguru Engine et la « webextension » en cours de travail, ou encore Wave.

La web extension Tanaguru qui est en cours de travail

Y a-t-il des “mauvaises pratiques” du web qui t’exaspèrent particulièrement ?

...Tu mentionnes sur ton compte Twitter des mauvais élèves en terme d’accessibilité ou de mauvaise expérience utilisateur : comment faire changer les choses et se remettre sur la bonne voie ? Le RGAA n’est pas tout récent, et pourtant beaucoup de sites publics, du gouvernement, sont encore conçus avec les pieds et ne respectent pas les bonnes pratiques minimales (ex : un lien c’est une balise a en HTML et pas un span “cliquable” avec du JS). Comment penses-tu que l’on puisse leur faire entendre raison ?

Les mauvaises pratiques du web qui m’exaspèrent particulièrement sont celles où les organismes ne respectent pas les lois établies pour protéger ou servir les intérêts des utilisateurs et utilisatrices.

On peut citer le non-respect du RGPD (Règlement Général sur la Protection des Données) qui peut donner lieu à des sanctions assez sévères et qui, grâce à ça, commence à faire bien réfléchir les organismes. Dès qu’on envoie un courrier type disant que, sans réponse satisfaisante, on s’adressera à la CNIL, en général, ça bouge. Le cas échéant, la CNIL se charge assez bien de les faire bouger.

Et puis, on peut citer le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) qui s’accompagne de l’article 47 de la loi n°2005-102 du 11 février 2005 pour l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées. Depuis la publication du décret d’application en juillet 2019, des sanctions financières sont enfin prévues (jusqu’à 20 000€ par site et par an) si les documents légaux (déclaration d’accessibilité, schéma pluriannuel de mise en accessibilité, plan d’action de l’année en cours, affichage du niveau d’accessibilité sur la page d’accueil) ne sont pas publiés sur les sites entrants dans le champ d’application de la loi. Un certain nombre d’organismes privés sont également concernés. Ça commence à faire réfléchir aussi mais tout doucement. Pour l’instant, aucune sanction n’a été prononcée ; c’est sans doute quand ça arrivera que ça commencera vraiment à s’activer. C’est comme ça que ça bouge aux États-Unis, en tout cas.

Ça me déçoit beaucoup qu’il faille des sanctions financières pour que les gens comprennent que c’est important… Il faut dire aussi que, en France au moins, il n’y a pas encore de réelle inclusion des personnes handicapées dans la société donc on les voit peu (notamment à l’école mais aussi au travail), on parle peu des difficultés que la société leur pose et de la façon dont cette dernière devrait s’adapter, on manque d’enseignements sur le sujet, etc. Beaucoup de gens pensent que ce n’est pas important.

Mais ce qui m’exaspère le plus, c’est quand les organismes mentent en disant respecter les lois en vigueur alors que c’est faux. Avec le RGAA, c’est assez simple : pour prouver que le site est conforme, il faut conduire un audit et en publier le résultat. Donc, si dans la page « Accessibilité », on proclame que le site est conforme au RGAA sans donner le résultat d’un audit, c’est un mensonge. Il y a des modèles à respecter ; ça ne s’invente pas.

Une capture du site de la poste https://www.laposte.fr/ lorsqu'on redéfinit les espacements avec le style personnalisé de Stylus. Tout est cassé car on a des éléments dont la hauteur ou les marges, etc. sont fixes et en pixels. Je pense que c'est un très bon exemple d'illustration de ce test car on ne peut même plus accéder aux éléments dans l'en-tête qui sont cachés par le bandeau d'alerte rouge. De plus, certains éléments dans le menu à gauche sont tronqués.

Dans la conduite des projets, ce sont les responsables projet (côté client et prestataire) qui sont responsables de la mise en accessibilité (ou non). Celle-ci doit être prise en compte dès le début du projet pour que ça fonctionne et doit être vérifiée à la fin. Pour ne pas se casser les dents, il faudrait former toutes les personnes intervenant dans la réalisation du projet et se faire accompagner par une personne experte qui servirait de « guide » à la réalisation accessible. Ce ne sont pas les équipes de design ou de développement qui sont responsables si le site est inaccessible car, si elles ne savent pas faire, c’est qu’on ne les a pas formées. Si le projet qui sort n’est pas accessible, c’est parce qu’on n’a pas mis en place une bonne gestion de projet accessible. Sur un projet, si une personne rechigne à prendre en compte l’accessibilité et freine les actions (oui, ça arrive, malheureusement), il suffit de la sortir du projet ; ce qui est encore le rôle des responsables. Et si le budget n’est pas suffisant, ce sera un choix des responsables de prendre en compte l’accessibilité a posteriori ou de ne pas la prendre en compte du tout. De plus, les responsables côté client ont le devoir de s’assurer qu’on leur livre un projet répondant au cahier des charges (cahier des charges qui doit indiquer l’obligation d’accessibilité s’il y a).

Il y a des responsables pour qui l’accessibilité est essentielle et avec qui on peut parvenir à réaliser des projets accessibles (merci !). Il arrive que ce soit la hiérarchie encore au-dessus qui bloque. Dans ces cas-là, il y aura, j’espère, les sanctions qui pousseront les réfractaires à agir. On peut, parfois, ne pas connaître le sujet mais pas quand on est un organisme public ou un organisme qui s’adresse aux personnes handicapées. Et puis, ça devient un « sujet à la mode » donc il est de plus en plus difficile de l’ignorer.

Alors, bien sûr, j’encourage toutes les personnes réalisant des sites web ou applications à se former au sujet en demandant une formation à leur entreprise ou, à défaut, en autodidactes si elles le peuvent même si ce sera souvent insuffisant. C’est essentiel ! Réaliser des projets en intégrant les bases de l’accessibilité même quand ce n’est pas demandé devrait aller de soi.

La formation de toutes les personnes qui sont déjà en poste, en particulier celles qui travaillent pour les organismes concernés par la loi est un axe sur lequel il faut jouer. Il faut que les responsables projet prennent le sujet en main et se forment aussi.

Et, pour éviter de continuer toujours sur la même voie qui ne fonctionne pas, un autre axe sur lequel agir est l’intégration des connaissances d’accessibilité dans les formations sur les métiers du web et de la communication, notamment. Il ne faut pas que ce soit juste un cours sur l’accessibilité qui contredise tous les autres cours qui ne parlent pas du sujet ; il faut que ce soit des connaissances intégrées dans chaque matière enseignée pour que ça devienne naturel. Ça implique d’avoir des enseignants et enseignantes qui connaissent le sujet et donc de se donner les moyens de les former en amont. Dans l’entreprise où je travaille actuellement, Tanaguru, on a un projet qui est en train de se monter : une formation au métier d’intégrateur ou intégratrice web (avec un peu de développement dedans) où l’objectif est d’apprendre à faire accessible directement. Le but est aussi que cette formation soit accessible aux personnes handicapées, tant qu’à faire ! On devrait en parler plus en détails bientôt.

Par quels moyens fais-tu de la veille ? (quels sites / personnes / événements par exemple)

Ma veille, ces derniers temps, c’est beaucoup (trop) Twitter. J’utilise aussi les flux RSS depuis que je les ai découvert, il y a fort fort longtemps. Je mets tout ça dans un agrégateur de flux RSS et je les classe. Il y a du web mais pas seulement. Du côté de l’accessibilité, il y a, par exemple : 24a11y, Access42, Adrian Roselli, Atalan, Axess Lab, Deque Systems, Tanaguru, The Paciello Group, WebAIM, etc. Du côté du web de manière générale, il y a 24 jours de web, Alsacréations, CSS Tricks, HTeuMeuLeu, Smashing Magazine, etc.

Je n’ai pas le temps de tout suivre, de tout lire. La plupart du temps, c’est la réalisation de projets qui me permet de me documenter et de me renseigner le plus efficacement.

Sinon, depuis quelques semaines, j’essaye de faire régulièrement du télévélotaf : du vélo d’appartement après le télétravail… Ça me permet de faire l’exercice dont je manque en ne me déplaçant plus depuis ma maison jusqu’à mon travail tout en regardant les vidéos des conférences que j’ai manquées : Paris Web, BlendWebMix, Kiwi Party, entre autres. L’avantage, c’est que ça permet de rester concentrée devant une longue vidéo ; ce qui est difficile d’habitude.

Bon, dernièrement, j’ai plutôt regardé des documentaires sur Arte parce que, par les temps qui courent, j’ai aussi besoin de voir autre chose.

As-tu des livres à nous recommander ? (dans le domaine pro ou non)

Dans le domaine professionnel, je n’ai pas grand-chose à recommander car les livres que j’ai lu sont maintenant un peu vieux. Et puis, j’ai besoin de m’évader quand je lis un livre ; ce qui n’est pas très compatible avec les livres pro. Par contre, je peux vous recommander quand même « Inclusive Components » de Heydon Pickering. Je ne l’ai pas lu en entier mais il me semble bien, pour ce que j’en ai lu, que c’est une mine d’or pour apprendre à réaliser des composants accessibles. Il existe sous forme de livre et de site web donc c’est assez pratique.

Autrement, pour m’évader, j’aime beaucoup la littérature fantastique. Je peux recommander « La Longue Terre » de Terry Pratchett et Stephen Baxter : il n’y a pas plus grande évasion que la possibilité de changer de Terre à l’infini. Il y a aussi les annales du Disque-Monde de Terry Pratchett ; c’est très décalé et ça fait du bien. Enfin, le dernier livre que j’ai terminé et bien aimé était « L’âme des horloges » de David Mitchell ; un très gros livre avec une histoire vraiment bien pensée et bien écrite, et qui détaille pas mal la vie de ses personnages auxquels on s’attache fatalement.

Quel est le langage ou la technologie qui t’attire le plus aujourd’hui ?

Le langage qui m’a toujours le plus attirée, c’est le HTML ; encore plus depuis qu’on est passé à la version 5 avec encore plus de sémantique. Chaque élément a sa sémantique (ou absence de sémantique à l’image des span et des div) et ses usages. C’est carré. Certains éléments ont un passé qui rend ce sens assez complexe à appréhender (comme b et i, par exemple). On peut en passer du temps sur MDN pour lire les descriptions. Malheureusement, cette sémantique n’est pas toujours (pas encore) exploitée totalement, notamment par les lecteurs d’écran ; ça donne parfois des cas intéressants auxquels réfléchir pour une vraie mise en accessibilité.

À qui aimerais tu passer le relais de cette interview ?

Sans hésiter, j’aimerais passer le relais à Loriane Buffet qui m’a impressionnée lors de son défi #100DaysOfA11y qui s’est terminé en février dernier.

Publié par Alsacreations.com

Avant de rentrer dans le vif du sujet, un peu de contexte.

En 2013, un collectif crée l’extensible web manifesto, en faveur d’un web extensible. L’objectif affiché est clair : réfléchir à une nouvelle forme de standards, qui laissent la liberté aux concepteurs de définir leurs propres fonctionnalités. Le but est donc de fournir des APIs plus bas niveau, un accès au cœur du navigateur, et ainsi inclure les concepteurs dans le processus d’innovation sans les restreindre aux seuls consensus définis par les standards historiques.

Dans l’univers HTML, on peut évoquer les composants web (web components) qui résultent de cette philosophie. Plusieurs standards ont été mis au point pour nous aider à créer nos propres composants HTML, et ainsi étendre le langage HTML. Cette solution étant bien entendu basée sur HTML, CSS et JavaScript.

Coté CSS, c’est justement l’ambition d’Houdini : de nouveaux standards pour concevoir nos propres effets graphiques, nos propres modes de positionnement, et pourquoi pas nos propres extensions (de nouveaux sélecteurs, de nouvelles propriétés, de nouvelles fonctions ,etc.), et bien plus encore. En un mot, étendre CSS à notre envie.

Concrètement, c’est nous donner accès à toutes les phases qui sont effectuées par un navigateur pour passer d’un fichier texte à un rendu écran. On peut décomposer sommairement les actions réalisées par les navigateurs de la sorte :

• la première étape est le Parsing, le navigateur lit et « déchiffre » les documents HTML et CSS
• le navigateur crée le DOM et le CSSOM, des représentations objets de ces fichiers textes
• en découle le Render Tree, ou Layer Tree, une sorte de liste des styles à appliquer pour dessiner chaque élément de la page
• enfin, le navigateur dessine les éléments en passant par 3 phases :
  • Layout, le navigateur applique les règles de positionnement (display, tailles, marges, etc.) et construit donc l’architecture. On parle aussi de reflow.
  • Paint, le navigateur applique les règles de dessin (arrières-plans, bordures, images de fond). On parle aussi de repaint.
  • Composite, une phase de compositing, c’est à dire de l’empilement des différents calques créés par certaines propriétés CSS (transformations, opacité, etc.). Souvent effectuée par la carte graphique et dans un thread séparé.

Actuellement, si l’on souhaite créer un effet visuel innovant pour une interface, il nous faut alors modifier le DOM. C’est la seule porte d’entrée au mécanisme interne des navigateurs.

L’ambition de CSS Houdini, c’est de nous permettre d’accéder à toutes les étapes internes d’un navigateur, comme le montre l’image ci-dessous.

Pour cela, c’est donc bien tout un ensemble d’API (notamment JavaScript) qui sont en cours de standardisation.

Remarquez au passage que CSSOM (plutôt complexe et mal implémenté par les navigateurs) est plus ou moins remplacé par Typed OM. Ce standard plus robuste définit un ensemble de classes d’objets permettant de manipuler CSS (les différents fichiers, les at-rules, les sélecteurs, les déclarations, les propriétés, les valeurs, etc.).

Typed OM est par conséquent utile à tous les autres standards, son principal intérêt étant la structuration du code JS qui manipule CSS, comme par exemple pour en finir avec les concaténations hasardeuses :

// CSSOM
el.style.setProperty('transform', 'translate(' + x + 'px, ' + y + 'px)')
// Typed OM
el.attributeStyleMap.set('transform', new CSSTranslate(CSS.px(x), CSS.px(y)))

Ou bien tout simplement, pour récupérer les valeurs sous forme d’objet au lieu de chaine de caractères :

// CSSOM
getComputedStyle(el).getPropertyValue('width')      // '50px'
// Typed OM
el.computedStyleMap().get('width')                  // CSSUnitValue {value: 50, unit: 'px'}

Note : vous pouvez retrouver le support de CSS Houdini sur https://ishoudinireadyyet.com. Vous remarquez que Chrome est en tête sur l’implémentation, mais c’est légèrement enjolivé (et oui, le site est maintenu par les équipes de Google). Je préciserais plus en détails dans la suite de l’article. Par exemple, pour Typed OM, le support n’est effectif que pour une partie uniquement, mais il existe une liste.

Créer ses propres propriétés

À présent, listons quelques cas d’usages d’Houdini.

Depuis quelques années, il est déjà possible de créer ses propres propriétés CSS. C’est le standard des propriétés personnalisées (custom properties), que l’on connaît également sous le nom des variables CSS.

Prenons la propriété box-shadow. Si l’on souhaite changer l’une de ses valeurs, il est nécessaire de réécrire la règle entièrement, comme dans cet exemple où l’on modifie la valeur de flou au survol

.el {
  box-shadow: 0 3px 3px black;
}
.el:hover {
  box-shadow: 0 3px 10px black;
}

Grâce aux propriétés custom de CSS, on peut définir une propriété --box-shadow-blur pour cela et seule cette propriété pourra être modifiée. Elle est appliquée depuis l’état initial à l’aide la fonction var()

.el {
  --box-shadow-blur: 3px;
  box-shadow: 0 3px var(--box-shadow-blur) black;
}
.el:hover {
  --box-shadow-blur: 10px;
}

Cela s’avère pratique, mais dans ce cas précis, il est impossible d’animer cette nouvelle propriété. En effet, le navigateur n’a aucune connaissance du type de valeur attendue et ne sait donc pas comment faire.

C’est là où l’API Properties & Values de Houdini entre en jeu. Cette spécification définit la nouvelle at-rule @property (en CSS) ainsi que la méthode CSS.registerProperty() (en JS) qui permettent d’enregistrer une propriété personnalisée, et notamment en précisant le type CSS attendu. L’un des avantages est que le navigateur saura maintenant comment l’animer (si c’est possible). Reprenons le cas précédent, en ajoutant l’animation, et en déclarant notre nouvelle propriété

.el {
  --box-shadow-blur: 3px;
  box-shadow: 0 3px var(--box-shadow-blur) black;
  transition: --box-shadow-blur .45s;
}
.el:hover {
  --box-shadow-blur: 10px;
}

@property --box-shadow-blur {
  syntax: "<length>";
  inherits: false;
  initial-value: 0;
}

Et voilà, une belle animation au survol, qui ne modifie que la propriété souhaitée.

See the Pen CSS Houdini: Register a new property by Vincent De Oliveira (@iamvdo) on CodePen.

C’est une première étape pour étendre CSS: on demande au navigateur d’apprendre une nouvelle propriété, inconnue auparavant. Et les animations ne sont pas le seul intérêt à l’utilisation des propriétés customs. Cela peut également apporter un gain de performance, en précisant par exemple qu’une propriété custom ne s’hérite pas (ce qui évite notamment au navigateur d’appliquer des changements aux éléments enfants).

En passant, évitez d’appliquer trop de propriétés custom via le sélecteur :root, comme vous forcent certains plugins de l’univers de PostCSS par exemple. Des problèmes de performance sont à noter.

Le support est actuellement uniquement dans les navigateurs basés sur le moteur Blink (Chrome, Opera, Edge), et seulement la méthode JS. La nouvelle at-rule @property sera supportée très bientôt. Cependant, dans les 2 cas, tous les types ne sont pas encore implémentés (lié aussi à Typed OM), sans avoir de liste exhaustive.

Créer ses propres effets graphiques

Actuellement, les seuls effets graphiques réalisables sont ceux définis par le langage CSS. Des couleurs de fond, des bordures, des dégradés, des coins arrondis, des ombres, bref, vous connaissez tout ça.

Le futur standard CSS Paint API, comme son nom l’indique, nous donne accès à l’étape Paint des navigateurs. Ce standard définit un environnement d’exécution isolé (un worklet), dans lequel on peut dessiner programmatiquement une image, à l’instar de la balise <canvas> de HTML. Cette image peut ensuite être appliquée depuis les propriétés CSS qui les acceptent, principalement background-image, border-image et mask-image.

Ce nouveau standard définit donc :

• CSS.paintWorklet.addModule('paint.js') pour charger un worklet
• registerPaint() pour réaliser le dessin au sein du worklet (dans un fichier séparé)
• la fonction CSS paint() pour utiliser le worklet

Le code d’un worklet est donc isolé du reste de la page, et n’est appelé que lors de la phase de Paint, ce qui rends le dessin plus performant, car le navigateur n’effectue plus toutes les étapes habituelles de mise à jour. De plus, les navigateurs peuvent facilement améliorer la performance de ce code spécifique (exécution dans un thread séparé notamment).

Prenons un effet graphique basique, mais pourtant pas si simple à réaliser en CSS : un élément dont le bord droit est incliné, comme sur cette image :

On devrait pouvoir s’en sortir avec un dégradé linéaire, ou encore des transformations CSS, mais difficile de gérer correctement le responsive (avec des tailles de polices différentes). Des éléments supplémentaires seront surement nécessaires.

Avec Houdini, cela devient un jeu d’enfant. Première étape, enregistrer le worklet, avec nos instructions de dessins, nommé slanted :

registerPaint('slanted', class {
  paint (ctx, geom) {
    ctx.fillStyle = 'hsl(296, 100%, 50%)';
    ctx.beginPath();
    ctx.moveTo(0, 0);
    ctx.lineTo(geom.width, 0);
    ctx.lineTo(geom.width - 20, geom.height);
    ctx.lineTo(0, geom.height);
    ctx.fill();
  }
})

Sa méthode paint() est composée d’instructions de dessin qui crée la forme inclinée, et a accès à 2 variables :

• ctx est le contexte de dessin
• geom est un objet contenant la taille de l’élément où le dessin sera appliqué

Le dessin s’effectue donc à l’aide des instructions classiques du contexte de dessin lié à la balise <canvas> HTML : moveTo() pour se déplacer, lineTo() pour créer ligne droite, etc.

Ensuite, il nous faut charger ce worklet puis l’utiliser depuis notre CSS :

.el {
  background-image: paint(slanted);
}

Et voilà ! Le rendu est responsive par défaut, et redessiné automatiquement à chaque changement de taille de l’élément (essayez d’éditer le texte).

See the Pen CSS Paint API by Vincent De Oliveira (@iamvdo) on CodePen.

Là où ça devient vraiment intéressant, c’est lorsque l’on va récupérer les valeurs de propriétés custom dans le worklet, et que l’on utilise le tout avec des animations. Pour commencer, créeons un nouveau worklet, et dessinons un cercle qui s’adapte automatiquement à la plus petite largeur de notre élément :

// New worklet
registerPaint('circle', class {
  paint(ctx, geom, props) {
    // Get the center point and radius
    const x = geom.width / 2;
    const y = geom.height / 2;
    const radius = Math.min(x, y);

    // Draw the circle
    ctx.fillStyle = 'deeppink';
    ctx.beginPath();
    ctx.arc(x, y, radius, 0, 2 * Math.PI);
    ctx.fill();
  }
}

See the Pen CSS Paint API: Draw circle by Vincent De Oliveira (@iamvdo) on CodePen.

Continuons avec l’utilisation d’une propriété custom --circle-color définie en CSS et utilisée depuis le worklet, à l’aide du troisième argument de la méthode paint(), nommé props :

.el {
  --circle-color: deepskyblue;
  background-image: paint(circle);
}

@property --circle-color {
  syntax: "<color>";
  inherits: false;
  initial-value: currentcolor;
}

registerPaint('circle', class {
  static get inputProperties() { return ['--circle-color'] }
  paint(ctx, geom, props) {
    ...
    ctx.fillStyle = props.get('--circle-color').value;
    ...
  }
}

See the Pen CSS Paint API: Draw circle with custom props by Vincent De Oliveira (@iamvdo) on CodePen.

Dernière étape, créons trois nouvelles propriétés custom, --circle-x et --circle-y pour préciser le centre de notre cercle et --circle-radius pour sa taille. Ces trois propriétés sont utilisées dans le worklet

registerPaint('circle', class {
  static get inputProperties() { 
    return [ 
      '--circle-color', '--circle-radius', '--circle-x', '--circle-y'
    ]
  }
  paint(ctx, geom, props) {
    const x = props.get('--circle-x').value;
    const y = props.get('--circle-y').value;
    const radius = props.get('--circle-radius').value;
  }
}

À l’état initial, le cercle a une taille à 0, et cette propriété sera animable en CSS.

.el {
  --circle-radius: 0;
  --circle-color: deepskyblue;
  background-image: paint(circle-ripple);
}
.el.animating {
  transition: --circle-radius 1s,
              --circle-color 1s;
  --circle-radius: 300;
  --circle-color: transparent;
}

Et enfin, le centre est défini en JS à l’endroit où l’utilisateur clique sur l’élément. L’ajout de classe permet d’animer la taille du cercle.

el.addEventListener('click', e => {
  el.classList.add('animating');
  el.attributeStyleMap.set('--circle-x', e.offsetX);
  el.attributeStyleMap.set('--circle-y', e.offsetY);
});

See the Pen CSS Paint API: Animations by Vincent De Oliveira (@iamvdo) on CodePen.

Boom ! Le fameux effet ripple de Google Material en quelques lignes de code. Et le tout, de manière performante.

Grâce à ce type de worklet, on peut envisager pas mal d’effets nouveaux, ou tout du moins se simplifier la création de certains effets courants. Parmi mes expérimentations, vous pourrez notamment retrouver la création de flèche d’infobulles, d’une superellipse (des coins arrondis à la mode iOS), des bordures qui simulent un trait de crayon ou des surlignages type Stabilo, des dégradés des coins, ou pourquoi pas une grille irrégulière aléatoire si l’on mixe cette technique avec les masques CSS.

Le support de CSS Paint API est uniquement dans les navigateurs basés sur le moteur Blink. Et pas à 100% : les attributs de la fonction CSS paint() ne sont pas pris en charge notamment. Le fait de passer des attributs permet par exemple d'appeler le même worklet plusieurs fois sur le même élément, et ainsi obtenir des résultats différents, comme c’est le cas dans cet exemple de bordures « internes ».

De plus, les APIs de Houdini sont étroitement liées les unes aux autres. Par exemple, pour récupérer une propriété custom dans un worklet et l’utiliser sour forme d’objet, il faut que les navigateurs implémentent l’API Properties & Values (pour enregistrer le type de la propriété), mais également Typed OM. Même Chrome a une implémentation imprévisible. Beaucoup de tests sont nécessaires pour savoir ce qui est supporté ou non.

Créer ses propres modes de positionnement

Dans la même veine, il existe un worklet spécifique à la création de son propre mode de positionnement. C’est ce que définit le standard CSS Layout API.

À la manière de Flexbox et Grid, vous pouvez donc écrire votre propre moteur de placement d’éléments au sein d’un élément parent. Comment ? Et bien, comme pour CSS Paint API :

• CSS.layoutWorklet.addModule('layout.js') pour charger un worklet
• registerLayout() pour construire les règles du positionnement dans le worklet
• la fonction CSS layout() pour utiliser le worklet avec la propriété display

Bien que Flexbox et Grid ouvrent beaucoup de possibilités, il y a encore certains layout non réalisable en CSS. L’un des plus populaires est le layout Masonry. Avec cette nouvelle API, cela devient possible, avec environ 40 lignes de JS :

// Code from https://github.com/GoogleChromeLabs/houdini-samples/blob/master/layout-worklet/masonry/masonry.js 
registerLayout('masonry', class {
  async layout(children, edges, constraints, styleMap) {
    const inlineSize = constraints.fixedInlineSize;

    let columns = Math.ceil(inlineSize / 350);
    let padding = 10;

    // Layout all children with simply their column size.
    const childInlineSize = (inlineSize - ((columns + 1) * padding)) / columns;
    const childFragments = await Promise.all(children.map((child) => {
      return child.layoutNextFragment({fixedInlineSize: childInlineSize});
    }));

    let autoBlockSize = 0;
    const columnOffsets = Array(columns).fill(0);
    for (let childFragment of childFragments) {
      // Select the column with the least amount of stuff in it.
      const min = columnOffsets.reduce((acc, val, idx) => {
        if (!acc || val < acc.val) {
          return {idx, val};
        }

        return acc;
      }, {val: +Infinity, idx: -1});

      childFragment.inlineOffset = padding + (childInlineSize + padding) * min.idx;
      childFragment.blockOffset = padding + min.val;

      columnOffsets[min.idx] = childFragment.blockOffset + childFragment.blockSize;
      autoBlockSize = Math.max(autoBlockSize, columnOffsets[min.idx] + padding);
    }

    return {autoBlockSize, childFragments};
  }
});

Puis, coté CSS

.el {
  display: layout(masonry);
}

Pour voir le résultat, chargez le CodePen suivant, dans un navigateur basé sur Blink, avec le flag Web Platform actif

See the Pen pojPXKx by Vincent De Oliveira (@iamvdo) on CodePen.

Certes, le code JS parait complexe, mais pas tant que ça au final. Et surtout, ce code est isolé du reste de la page, et n’est appelé que lors de la phase de Layout, ce qui le rends plus performant, comme expliqué précédemment.

Bien entendu, on peut donc envisager d’autres modes de positionnement, comme ceux utilisés pour le développement d’applications natives (iOS, Android). Les développeurs de Google ont par exemple écrit un worklet pour porter le RelativeLayout d’Android. On peut également être plus créatifs, et créer un mode où les éléments sont positionnés le long d’un chemin SVG, défini par une propriété custom :

.el {
  display: layout(svg-path);
  --path: path("M100,300c100,-100,150,-120,300,0c150,50,300,0,400,-200");
}

Dans ce cas précis, cela nous évite des positionnements absolus à la louche et difficilement responsive. Certes, il est possible d’obtenir un résultat équivalent avec le module CSS Motion (pas Houdini) et la propriété offset, mais le tracé SVG n’est pas adaptatif par défaut (donc du JS est nécessaire) et le CSS doit prévoir à l’avance le nombre d’éléments à positionner.

Le support actuel de CSS Layout API est assez limité, car uniquement dans les navigateurs basés sur le moteur Blink avec le flag Web Platform. Ce ne sont que les premières implémentations.

Encore plus ?

Il existe un dernier type de worklet au sein d’Houdini, dédié à la performance des animations, c’est l’Animation Worklet API, basée sur WAAPI (Web Animations API). Comme pour les autres worklets, le code de l’animation est donc isolé, mais surtout, il autorise une baseline basée sur d’autres paramètres que le temps. C’est notamment utile pour obtenir des animations performantes basées sur les interactions utilisateurs, comme le scroll (manuel, mais aussi animé) :

Prenons un exemple, un worklet qui enregistre une simple animation linéaire 1 pour 1

registerAnimator('simple', class {
  animate(currentTime, effect) {
    effect.localTime = currentTime;
  }
});

Ce worklet est chargé, puis une animation est créée en JS :

• elle met à jour une propriété custom CSS --angle pour une durée de 1 (avec une valeur de 0 à 1 tour complet)
• elle est basée sur le scroll (new ScrollTimeline avec scrollSource: scrollElement) et le « temps » équivalent est défini à 1

CSS.animationWorklet.addModule('...').then(r => {
  new WorkletAnimation('simple',
    new KeyframeEffect(el, [
        { '--angle': 0 },
        { '--angle': '1turn' }
      ],
      { duration: 1 }
    ),
    new ScrollTimeline({
      scrollSource: scrollElement,
      timeRange: 1
    }),
  ).play();
});

Finalement, la propriété --angle est utilisée en CSS pour pivoter l’intégralité d’un cube en 3D

.cube {
  --angle: 0;
  transform: rotateX(var(--angle)) rotateZ(45deg) rotateY(-45deg);
}

Pour voir le résultat, chargez le CodePen suivant, dans un navigateur basé sur Blink, avec le flag Web Platform actif

See the Pen CSS Houdini Animation API: Scroll by Vincent De Oliveira (@iamvdo) on CodePen.

Le support est actuellement limité aux navigateurs basés sur le moteur Blink avec le flag Web Platform.

L’ambition de CSS Houdini, c’est d’aller encore plus loin. Rien n’existe encore vraiment à ce stade, mais on peut citer :

• l’API CSS Parser pour avoir accès à la première étape des navigateurs : la lecture du fichier. J’imagine donc qu’il serait possible de créer ses propres fonctions, ses propres sélecteurs, etc. puisque l’on pourrait les parser nous-mêmes. Reste à savoir ce que l’on pourrait en faire.
• l’API Font Metrics pour accéder aux métriques des fontes en CSS. Et ça serait super pour éviter les petits désagréments actuels.

Mais alors, véritable magie ou simple poudre aux yeux ?

On peut être enthousiaste à l’idée de toutes ces nouveautés offertes par Houdini. Mais il faut quand même prendre en considérations quelques points.

Nouvelles possibilités offertes

Toutes ces nouvelles API augmentent la créativité et aide à mettre en place des effets qui étaient jusque là impossibles ou alors très compliqués à réaliser.

Comme vu plus haut, on peut spécifier ses propres propriétés, mais malheureusement on ne peut pas vraiment étendre des fonctionnalités existantes. Dans le cas de création d’une propriété pour le flou d’une ombre, il est par exemple impossible de créer un flou directionnel en divisant --box-shadow-blur en deux sous-propriétés, --box-shadow-blur-x et --box-shadow-blur-y. Il n’existe pas de solution pour «hacker» le dessin des ombres du navigateur.

Même si l’API Paint paraît révolutionnaire en soit, ce n’est finalement qu’une version performante de -webkit-canvas() qui existe depuis 2008, mais qui est maintenant retirée de Chrome.

Le dessin est effectué dans un canvas, via son contexte de type CanvasRendering2D (et encore, une version plus limitée). Il existe des centaines d’effets impossibles aujourd’hui, qui ne pourront pas être réalisés avec CSS Houdini. Ce contexte de dessin n’est pas initialement prévu pour CSS et il a donc de nombreuses contraintes :

• pas de gestion simple des bordures (border-clip, bordures multiples, etc.), ni des ombres, ni des images d’arrière-plan (répétition, position, taille, etc.)
• pas pratique de dessiner en dehors d’un élément (mais possible en combinant border-image + border-outset), comme pour les ombres
• pas de gestion des textes
• rien de nouveau pour styler les formulaires
• etc.

Dans beaucoup de cas, SVG est un choix bien plus simple et pratique.

Concernant l’API Layout, ce sont uniquement des modes de positionnement complets qui sont réalisables (comme Flexbox ou Grid). C’est déjà très bien me direz-vous, mais cela ne permet pas de modifier la façon dont CSS fonctionne.

Impossible donc d’agir sur la taille, ou les marges, d’un seul élément, de changer son containing block (dans le cas d’un élément en position absolue) ou son contexte d’empilement (notamment en cas de conflit avec certaines propriétés), ni même d’ajouter de nouveaux pseudo-éléments ou d’autres entités (mais c’est peut être du ressort des web components ?).

Polyfill

Un des critères avancé est la possibilité de créer ses propres polyfills (combler le manque de support d’un navigateur par son propre code). C’est vrai, Houdini peut aider, mais il ne faut pas oublier que les navigateurs supportant Houdini mais ne supportant pas telle ou telle fonctionnalité, sont plutôt rares. Il existe pourtant quelques contre-exemples :

• la propriété corner-shape présente dans les specs et supportée par aucun navigateur, réalisable avec l’API Paint
• le mode subgrid du Grid Layout supporté dans Firefox, réalisable avec l’API Layout
• la fonction filter() supportée dans Safari et réalisable avec l’API Paint
• et surement d’autres

Cependant, pas de miracle, la grande majorité de CSS est non polyfillable¹.

Performance

C’est le cheval de bataille de CSS Houdini : la performance de rendu. Et c’est tout à fait légitime. Aujourd’hui, en 2020, on est encore restreints dans la création d’effets visuels, et surtout lorsqu’ils sont animés. Les propriétés CSS de layout (width, height, margin, left etc.) ou mêmes des propriétés de dessin (background-color, background-size, etc.) sont très coûteuses en temps de rendu. C’est pour cela que les propriétés transform et opacity sont préférées, car sont traitées pendant la phase de compositing des navigateurs, et souvent effectuées par un thread séparé.

Regardez par exemple comment on peut animer une ombre portée (box-shadow) sans réellement animer l’ombre portée (spoiler: on anime l’opacité d’un pseudo-élément qui a l’ombre portée).

L’utilisation des worklets, isolés du reste de la page et du fameux thread principal², permet donc d’obtenir des résultats performants, sans recourir exclusivement aux propriétés transform/opacity.

Concernant le worklet Animation API, je ne suis personnellement pas un grand fan de cette solution. Le standard WAAPI est à mon sens bien suffisant pour réaliser des animations performantes, et pour gérer facilement les transitions/animations CSS. Pour la partie animation au scroll, je préfère nettement la spécification Scroll-linked Animations et notamment la propriété animation-timeline et l’at-rule @scroll-timeline, mais qui ne font pas partie de Houdini.

Innovation des moteurs de rendu

On ne peut pas parler de performance de rendu, sans évoquer les moteurs de rendu. Actuellement il existe 3 moteurs principaux de navigateur : Blink qui alimente Chrome, Opera, Edge, etc., WebKit pour Safari, et Gecko pour Firefox.

Les APIs de CSS Houdini sont basées sur un consensus de rendu, qui est plus ou moins celui de chaque navigateur, mais on se doit d’évoquer le nouveau moteur de rendu de Firefox : WebRender. Ce nouveau composant a l’ambition de modifier fondamentalement les techniques de rendu : dorénavant les phases Paint et Compositing sont fusionnées et c’est le GPU qui se charge de l’intégralité du rendu, à la manière des jeux vidéos. C’est encore récent, mais quand ce sera en place, les techniques à base de transform/opacity seront obsolètes pour ce navigateur. Selon @gsnedders, c’est même pire, car les APIs Houdini qui sont une réponse aux problèmes de performance de rendu dans le contexte actuel, seraient complexes à exécuter dans un contexte différent.

Et ça, c’est problématique, soit pour l’innovation, soit pour Houdini.

Tout en JavaScript

On peut également regretter que seules des APIs JavaScript soient en cours de standardisation. CSS Houdini, ce n’est finalement que du JS-in-CSS. Pas de JS, pas de styles.

Personnellement, j’aurais bien aimé pouvoir utiliser SVG dans un worklet. Le déclaratif, ça a du bon quelque fois. Mais pour être performant, il faudrait déjà que Blink/WebKit l’accélèrent matériellement. C’est pour bientôt dans WebKit.

Quoi qu’il en soit, ce qu’il en ressort est un code assez complexe à écrire et à mettre en oeuvre. Mais surtout, c’est souvent bien plus difficile que du JS « classique », via le DOM.

Sans rentrer dans des détails trop techniques, les worklets sont des environnements autonomes, qui ne doivent pas gérer d’état. Pour être sûr de cela, le navigateur doit créer deux instances pour chaque worklets, et utiliser indifféremment l’un ou l’autre pour le rendu. Cela complique énormément des effets qui semblent pourtant simple, comme dans cet exemple de bordures où chaque repaint crée des bordures différentes. Je me suis déjà cassé les dents plusieurs fois sur des effets à cause de cela. Il existe des solutions pour contourner ce problème, mais encore une fois, ça complexifie le code et crée souvent des effets de bords.

Plus basiquement, il ne faut pas sous-estimer le temps de chargement des scripts JS, voire tout simplement de leur non présence. Mais également du support de Houdini. Actuellement, les styles appliqués via paint() et layout() provoquent des FOUC (Flash of Unstyled Content).

La notion d’enrichissement progressif est plus que jamais d’actualité. Mais sera plus complexe à mettre en œuvre.

Sécurité

Enfin, dès que l’on ouvre un peu plus le coeur des navigateurs, s’en suivent des considérations de sécurité. Le principal frein est que l’utilisation des worklets ne peut se faire que sur un site en HTTPS. Pas de site sécurisé, pas de CSS. Et c’est un peu regrettable³.

Malgré cela, des chercheurs sont tout de même parvenus à exploiter une faille, qui permet de récupérer assez facilement un historique de navigation. La solution de contournement prise par les équipes de Chrome a été d’interdire l’utilisation de la fonction paint() sur les liens HTML. Là encore, c’est à mon avis une très grosse contrainte qui va en limiter l’adoption si cela en reste là.

Et surtout, combien de temps encore pour que d’autres failles soient découvertes ? Est-ce que l’avenir de CSS Houdini est lié à celui des CSS Shaders (des filtres CSS customs qui permettaient d’appliquer des shaders WebGL à la volée) qui ont disparus du jour au lendemain des navigateurs qui les avaient implémentés ?

Conclusion

Cette nouvelle façon de concevoir des standards est intéressante. Elle ouvre la porte aux concepteurs, et permet de les inclure dans le processus d’innovation. Avec CSS Houdini, de nouveaux effets sont possibles, et ces effets sont rendus de manière plus performante dans les navigateurs actuels. Mais cela implique quand même quelques contraintes : du JavaScript supplémentaire, plus complexe à mettre en oeuvre, etc.

Dans tous les cas, CSS Houdini est surtout pensé pour la performance, pas vraiment pour la créativité.

On peut aussi voir ces APIs comme une opportunité pour l’évolution des standards classiques. Si un effet visuel, ou un mode de positionnement, devient populaire, il pourrait alors être standardisé, pour être inclus directement en CSS. Mais qu’en sera t’il de la gestion des performances si l’on conserve les méthodes de rendus actuelles ?

Alors, vous, que pensez-vous de tout ça ?

Publié par Alsacreations.com

Cette année encore (c'est ma troisième) j'ai eu l'honneur de participer au Devfest de Nantes : deux journées de conférences plutôt orientées pour les développeur•euse•s comme son nom l'indique et dont l'ambiance se rapproche de plus en plus du festival de métal Hellfest — très proche géographiquement — dont il s'inspire abondamment.

Pour sortir de ma zone de confort, j'y ai présenté un sujet sur la typographie, thématique que je ne maîtrise pas tant que ça mais qui me passionne : "L'épopée des polices CSS de Comic Sans aux fontes variables".

"Grandiose" est le premier mot qui me vient à l'esprit en entrant dans le Centre des Congrès de Nantes. Et encore, je suis arrivé tôt et l'entrée était loin d'être remplie.

Énormément de stands partout, sur deux étages, tous orientés très "rock". Des activités toutes plus originales les unes que les autres : des karaokés, des simulations de réalité virtuelle, du guitar smashing, des concours de headbanging, des tatouages éphémères, de la conception de t-shirts, etc. Et... même des places à gagner pour le Hellfest 2020 ! (Bon, j'avoue, j'ai peu d'espoir).

Voici un résumé de mes aventures dans le Grand Ouest de la France, et plus particulièrement les moments qui m'ont le plus marqué…

Dès le début de journée, il a fallu choisir entre des confs radicalement différentes : les frameworks de Hubert Sablonnière et les daltoniens de Laura Wacrenier… Au final tous les feux étaient au vert pour le daltonisme :)

Au delà des couleurs (les interfaces adaptées au daltonisme)

La présentation de Laura Wacrenier est indubitablement une sensibilisation à l'accessibilité et au daltonisme. On reste dans le domaine de l'introduction mais avec le parti pris de systématiquement illustrer avec des exemples du quotidien et surtout appliqués en production chez Sonarsource (la société où oeuvre Laura). Bref on est dans le concret et c'est bien plus parlant ainsi.

Le déroulement est classique mais efficace :

• Laura commence par un état des lieux de l'existant dans sa boîte et le constat que toutes les interfaces jouent avec les couleurs rouge-vert-bleu (les dashboards, le formulaires),
• Elle poursuit avec les types de daltonisme, le plus courant étant l'atteinte du cône vert (deuteranoponia). Atteinte du chromosome X, donc concerne plus souvent les hommes (8%) que les femmes (0.5%),
• Elle passe ensuite aux bonnes pratiques (contrastes des textes, des éléments non textuels, ne pas se reposer sur les couleurs, souligner les liens, proposer des thèmes de couleurs, etc.)
• Et elle finit par le plus costaud : convaincre les équipes, ce qui n'est pas évident puisque les chiffres ne jouent pas en notre faveur (4.5% de la population est daltonienne). Comprendre que cela bénéficie à tout le monde et proposer systématiquement des design review (niveau AAA, tester avec simulateurs de daltonisme, approuvé sur un channel Slack dédié, etc.).

En conclusion, j'ai bien aimé cette présentation. Pas forcément pour ce qu'elle m'a appris mais surtout parce que l'enthousiasme de Laura est communicatif et donne envie de faire bouger les choses !

Les slides sont disponibles ici : https://drive.google.com/file/d/1IUtL_4KIRtLPfuTKsYxjcWHAftXPXd6L/view

Pause de midi

Toasts, canapés, wraps, etc. sont au rendez-vous. Gargantuesque mais relativement peu végétarien dans l'ensemble (ou alors j'ai mal cherché) et bien entendu beaucoup de monde qui se rue sur le buffet. Mais il est toujours difficile de réguler plusieurs milliers d'affamés.

La thématique Rock'n Roll n'est pas en reste puisqu'une scène musicale est prête à accueillir des groupes de musique en pleine improvisation ou de reprise de Nirvana, Rage Against the Machine, etc.

Burp !

Interactive web animation with SVG

C'est Cassie Evans de Clearleft (à Brighton) qui a la lourde tâche de nous tenir éveillé durant la digestion.

L'objectif de sa présentation est clairement d'encourager l'audience à adopter les animations SVG. Il s'agit donc plutôt d'une sensibilisation à l'aide de démos visuelles "whaou" qu'une conférence purement technique avec du code.

Malheureusement, la toute première démo Codepen plante, ce qui n'a pas dû arranger le niveau de stress de Cassie. La "Wobbly Jellyfish" sera finalement animée après diverses manipulations ésotériques. Ouf !

Parcours sans surprise, la présentation débute par un explication de ce qu'est le format SVG, à savoir à la fois une image mathématique et un langage de "markup" avec un DOM. SVG fait le pont entre Dev et Design.

À travers une démonstration concrète d'animation d'un Neopet, Cassie évoque les étapes et les bonnes pratiques à suivre :

• Choisir l'un des nombreux outils graphiques tels que Illustrator, Figma, Inscape, ou encore des banques d'images SVG telles que freepik.com
• Toujours nettoyer le fichier avant de commencer par exemple avec svgomg
• Continuer sur Codepen. Il suffit de copier/coller le code SVG dans Codepen puis de s'amuser avec.

Note en passant : la notion de "SVG viewport" qui représente la partie visible du SVG. Ce qui en déborde sera croppé.

Assez rapidement, Cassie aborde les limitations rencontrées :

• Pas de notion de z-index dans SVG, il faut apparaître dans le bon ordre du DOM pour être correctement superposé
• On ne peut pas enchaîner les animations en CSS, il faut jouer avec des delay successifs
• Le point d'origine de la transformation n'est pas identique selon les navigateurs. La récente propriété transform-box définit le layout box (valeurs fill-box ou view-box) et harmonise les navigateurs. Proposition de tester via @supports (transform-box: fill-box) {...}

Pour pallier ces limitations, Cassie évoque les bibliothèques utiles : Anime, Greensock, velocity.js :

• Ces librairies (sous licence MIT en général) gèrent les origines de transformations et les timelines successives
• Greensock propose des plugins (drawsvg plugin, morphsvg par ex.)
• Greensock propose également diverses courbes d'accélération originales telles que bounce et rough
• Ces librairies permettent en outre de réagir à l'audio ou à la webcam (color detection, face detection avec face API)

Au final tout cela est bien enthousiasmant en effet et je n'ai carrément vu personne s'endormir après le repas.

Les slides sont disponibles ici : https://slides.com/cassiecodes/deck-4-5

Promouvoir son projet open-source comme une rock star !

Une présentation de Franck Abgrall et Thomas Betous proposée par un duo bien sympathique, motivé et dynamique.

Le combo fonctionne bien, le rythme est entraînant, les échanges sont pertinents et pas trop de lourdeurs qui pourraient être dûes à une sur-préparation.

Mine de rien, même si tout est construit comme un sketch, les contenus sont bien là et exposés point par point :

• Bien préparer le projet (attendre qu'il soit mature, choisir un nom approprié, peaufiner l'aspect graphique, proposer une démo et une documentation claire)
• Déployer le projet (commencer à en parler dans son entourage, puis les réseaux sociaux, écrire des articles, le présenter à des conférences, créer des vidéos, etc.)
• Conserver ses usagers (mettre à jour le projet régulièrement, maintenir et corriger les issues, inviter aux contributions, remercier les contributeurs)

J'ai bien aimé ce moment à la fois divertissant et fort instructif : il y a plein de points pertinents qu'on imagine mettre en place dès le retour au bureau !

Les slides sont disponibles ici : https://speakerdeck.com/franckabgrall/comment-promouvoir-son-projet-open-source , et l'ensemble des conseils réunis sous forme de "Cheat Sheet" : https://github.com/zenika-open-source/open-source-promotion-cheat-sheet

Conclusion

Qu'il est difficile de résumer en quelques paragraphes l'ampleur du contenu et de l'ambiance d'un événement tel que ce Devfest. Pour l'avoir connue presque à ses débuts, on ne peut nier que cette manifestation a pris une ampleur considérable et devient sans aucun doute un regroupement incontournable aujourd'hui pour les développeuses et développeurs de tout poil et de tous horizons.

L'ambiance bon enfant et de je-ne-me-prends-pas-trop-au-sérieux est un atout considérable et ajoute à toute cette masse de contenus et d'informations emmagasinés une touche de légèreté qui rend encore plus indispensable ce type d'événement.

Je tire mon chapeau à toute l'équipe du staff pour l'organisation sans faille de cette manifestation exceptionnelle !

Publié par Alsacreations.com

Flexbox décortiqué à travers 18 vidéos

CSS3 Flexbox est l'une des dernières révolutions des spécifications CSS et nous facilite la vie tous les jours. Pourtant, il est parfois taquin et peu intuitif, notamment lorsque l'on s'attaque au trio de propriétés flex-grow, flex-shrink et flex-basis.

L'un de nos membres actifs du forum, lionel_css3, va devenir votre meilleur ami puisqu'il vient de publier une Série de vidéos d'apprentissage de Flexbox sur sa chaîne Youtube.

Durant 4h30 et près d'une vingtaine de vidéos, Lionel consolide petit à petit les bases de cette spécification plus complexe qu'il n'y paraît.

Au programme des réjouissances

• quelques vidéos d'introduction et partie pratique
• une vidéo sur inline-flex
• 3 vidéos sur Flexbox et Bootstrap
• 1 vidéo sur Flexbox et la gestion des images
• plusieurs vidéos d'exercices pratiques et un projet de mise en page complexe

À toutes fins utiles, l'auteur précise que cette chaine Youtube est gratuite, non monétisée, sans publicités et que son contenu est destiné au partage, sans aucune démarche commerciale.

Voir la série de vidéos

Publié par Alsacreations.com

La Performance Web est constamment à la recherche d'optimisations pour le confort de navigation. Diminuer le temps d'attente de l'internaute est un facteur clé incontournable du succès des sites web modernes. Et ce n'est pas Google qui vous dira le contraire : Evaluating page experience for a better web.

La ligne de flottaison

De nombreuses techniques sont employées pour favoriser la performance perçue. L'une d'entres elles consiste à afficher en priorité tous les éléments situés au dessus de la Ligne de Flottaison.

La Ligne de Flottaison représente la partie visible d'une page web, directement atteignable sans nécessiter de scroller verticalement.

L'un des conseils emblématiques des outils de diagnostic des performances web est d'Éliminer les contenus (JavaScript, CSS, Polices) qui bloquent l'affichage du contenu au-dessus de la ligne de flottaison.

Un certain nombre de techniques couvrent déjà les domaines suivants :

• JavaScript : Les attributs async et defer
• CSS : Des outils pour éliminer les styles CSS bloquants
• Polices de caractères : Les attributs rel=preload et font-display

Pour les images, soyez paresseux !

Concernant les images la technique du Lazy Loading, ou "Chargement Paresseux" (oui, ça passe mieux en anglais) permet de ne charger que les images situées au dessus de la ligne de flottaison. Les autres images ne sont alors chargées que lorsque cela devient nécessaire, au fur et à mesure que l'utilisateur scrolle (défile). On améliore ainsi le temps de chargement initial de la page.

Google Page Speed, nous conseille vivement de respecter cette consigne :

loading="lazy" à la rescousse

Pendant longtemps réalisée via JavaScript, la méthode de lazy loading est dorénavant décrite au sein d'une spécification du WhatWG sous la forme d'un attribut HTML loading dont les valeurs sont les suivantes :

• eager : l'image est chargée immédiatement, qu'elle soit située dans ou hors de la fenêtre visible (valeur par défaut),
• lazy : le chargement est retardé jusqu'à ce que l'usager scrolle et s'approche du bas de la fenêtre du navigateur.

<img src="image.jpg" alt="..." loading="lazy">
<iframe src="video-player.html" title="..." loading="lazy"></iframe>

Déjà compatible sur de nombreux navigateurs caniuse : Lazy loading via attribute for images & iframes, l'attribut loading est parfaitement envisageable en production. Pour un support plus large, sachez qu'il existe un polyfill (une émulation) de cet attribut HTML.

Pensez dès à présent à l'intégrer pour favoriser la performance perçue de vos visiteurs.

Publié par Alsacreations.com

Tailwind Css est un framework CSS complètement personnalisable, basé sur le principe de classes utilitaires, dont la version 2.0 a été annoncée hier avec encore plus de nouveautés sympathiques.

Le site officiel nous annonce la couleur immédiatement : construisez rapidement des sites sans quitter votre code HTML. Une sacrée promesse à tenir ?

Des classes utilitaires ?

Une classe utilitaire est une classe CSS qui a un seul et unique but. Prenons par exemple .bg-white. Cette classe a pour but de donner un background-color: white; à l’élément. Vous connaissez peut-être Bootstrap, un autre framework CSS: on peut voir que Tailwind et Bootstrap ne fonctionnent pas sur le même principe.

<div class="card grid grid-cols-1 shadow-md w-full mx-auto bg-white">
  ...
</div>

Au secours, où est passée la Sémantique ?!

Votre première réaction a sans doute été la même que la notre : On peut alors se dire que notre code HTML n’est plus vraiment "sémantique" comme il est souvent recommandé.

Adam Wathan, le créateur de TailwindCSS a décrit il y a quelques années dans un article devenu une référence en quoi la notion de "classe CSS sémantique" est l'un des freins majeurs à la maintenabilité d'un projet.

En prenant du recul, nous constatons que notre code HTML est devenu totalement indépendant d’une quelconque feuille de styles. Nous avons parfaitement opéré la séparation entre le fond (HTML) et la forme (CSS), le Saint Graal du développeur.

Autre problème conséquent résolu : il n’y a plus besoin de se “casser la tête” à imaginer des noms de classes qui correspondent au contexte, et on gagne du temps de manière significative. Car nommer les éléments en CSS est une plaie !

Toutefois, il est toujours possible de créer ses propres classes sémantiques pour pouvoir identifier un élément plus rapidement par exemple.
En partant de ce principe, une card aurait toujours la classe .card pour me permettre de l'identifier dans mon code.

Finalement ces classes sont là pour aider et accélérer le développement mais pas pour remplacer intégralement nos pratiques.

Un exemple de site populaire construit avec Tailwind est https://laracasts.com/, connu pour ses tutoriels sur Laravel mais aussi Vue.js et CSS entre autres. Pour une liste plus complète des sites utilisant Tailwind, vous pouvez visiter le site https://builtwithtailwind.com/.

Différence avec les autres Frameworks ?

Avec Bootstrap, pour faire un bouton bleu, nous appliquerions les classes, .btn et .btn-primary. Avec Tailwind, il y a un peu plus de classes à appliquer. En effet, vu que chaque classe n’a qu’un seul but, il en faut un plus grand nombre pour obtenir un composant tel un bouton.

Nous appliquerions donc .bg-blue-700, .text-white, .px-5, .py-3, .font-bold, .rounded.

Nous obtenons le même résultat visuel que notre bouton Bootstrap. Cependant ce bouton Tailwind est bien plus personnalisable et adaptable au contexte puisque chaque propriété peut être changée directement dans notre HTML à la volée.

Tailwind n’a pas d’opinion contrairement à Bootstrap et autres Frameworks basés sur un système de composants préfabriqués. C'est-à-dire que Tailwind nous propose une palette d’outils permettant de construire nous-même nos éléments HTML.

<a href="#" class="btn btn-primary">
  Bouton
</a>

<a href="#" class="bg-blue-700 text-white px-5 py-3 font-bold rounded">
  Bouton
</a>

Là où la Grille de Bootstrap impose une structure HTML très figée, à l'aide d'éléments imbriqués (des .col dans des .row) et un nommage imposé, Tailwind offre une indépendance complète et vous laisse décider de votre structure, pour tous vos composants ou gabarits.

Il faut également noter que, ne pas interférer dans la sémantique HTML permet aussi de régler un problème devenu courant et qui occupe une grande partie de notre boulot aujourd'hui: trouver un nom correct pour un élément. C’est en fait Tailwind qui s’occupe de ceci pour nous, ce qui rend la création d'éléments encore plus rapide et surtout moins bloquante lors d'une phase d’intégration.

Basé sur la personnalisation

Nous avons à notre disposition des classes pour tout faire, allant des propriétés typographiques comme font-size jusqu’à animation ou transition. Tout ceci peut donc être fait directement dans notre source HTML, ce qui permet de ne pas quitter son code pour aller changer une simple taille de police par exemple.

Ce framework est très complet par défaut et c’est ce qui en fait sa force. En jetant un coup d'œil à la documentation de Tailwind, nous pouvons voir les nombreux outils proposés.

Qu’est-ce que ça change du inline ?

En effet, on pourrait penser que rajouter des classes dans notre HTML revient à écrire des styles inline. Cependant, comme toute technologie, Tailwind n’est pas forcément adapté à tout projet.

Dans un contexte tel qu’une application Vue.js ou React.js, il est souvent conseillé d’écrire ses styles dans le composant directement. Dans ce cas-là pourquoi ne pas utiliser des classes au lieu d’une balise <style> à rallonge ?

Nos composants CSS correspondent dans ce cas à nos composants HTML et notre code serait réutilisable. Nos styles seraient donc modifiables à un seul et unique endroit sans avoir besoin de parcourir de nombreux fichiers et de changer des valeurs les unes après les autres.

De plus, l’importance d’un sélecteur de classe n'est pas du tout comparable à un style inline. Notre classe rend plus simple le remplacement de style en fonction du contexte.

Tailwind propose cependant une alternative : il n’est pas obligatoire d’écrire une dizaine de classes pour obtenir un bouton qui gère le focus, le hover etc. car nous avons accès à une règle CSS @apply.

Nous pouvons ainsi créer une classe personnelle telle que .btn-blue et utiliser la règle @apply pour appliquer nos styles.

.btn-blue {
  @apply bg-blue-700 text-white px-5 py-3 font-bold rounded;
}

Nous obtenons ici une classe qui permet de créer un bouton bleu, en utilisant la syntaxe de Tailwind, sans écrire de vrai CSS.

Comment le mettre en place ?

Tailwind peut être utilisé en téléchargeant le fichier CSS comme un framework habituel. Cependant cette méthode n’est pas recommandée car elle ne permet pas de configurer Tailwind comme nous le souhaitons en fonction du projet, et le fichier par défaut est bien lourd, il doit être optimisé par purgeCSS pour correspondre exactement aux styles utilisés, et faire tomber le résultat à quelques Ko.

Nous pouvons donc l’installer avec une commande NPM, qui est le gestionnaire de paquets de Node, bien connu désormais par la majorité des développeurs web.

npm install tailwindcss à la racine du projet.

Ensuite, il suffit de créer un fichier CSS, il n’y a pas besoin de le lier au HTML avec un <link rel="stylesheet">.

Dans ce fichier CSS, il nous faut importer Tailwind. Ce qui se fait simplement de cette manière.

@tailwind base;
@tailwind components;
@tailwind utilities;

Enfin, nous pouvons générer un fichier tailwind.config.js qui permet de personnaliser le css qui sera généré par Tailwind. Cette étape est optionnelle.

Dernière étape, construire le fichier CSS de Tailwind.

Il y a deux méthodes:

Nous pouvons lancer une commande manuelle en donnant le fichier CSS que nous avons créé et en donnant le fichier CSS que nous voulons obtenir comme ci-dessous.

npx tailwindcss build styles.css -o output.css toujours à la racine du projet. Ici styles.css est le fichier css où nous avons importé Tailwind et output.css et le fichier dans lequel Tailwind sera construit.

Nous pouvons maintenant utiliser output.css dans notre document HTML en le liant par une balise <link rel=”stylesheet”>.

La deuxième solution est d’utiliser un bundler, comme Webpack ou Gulp. Il est fortement conseillé de regarder la documentation détaillée pour chaque bundler. https://tailwindcss.com/docs/installation

Par exemple, dans une application Vue.js, PostCss est inclus par défaut et il nous suffirait de rajouter une ligne au fichier de config postcss.config.js

module.exports = {
  plugins: [
    require('tailwindcss'),
    require('autoprefixer')
  ]
}

La procédure dépendra de l’outil utilisé mais la simplicité reste cependant la même.

Conclusion

Tailwind permet de n’écrire que très peu de CSS puisqu’il propose une vaste palette d’outils. De plus, une personnalisation de la configuration et l’installation ne devraient pas prendre plus de 30min et sans personnalisation, pas plus de 2min.

Il n’y a pas besoin de se compliquer la vie avec de la spécificité CSS comme dans d’autres frameworks notamment avec les !important.

Le HTML peut s’écrire beaucoup plus rapidement, puisqu’il n’y a pas besoin de changer entre HTML / CSS. Tout est fait dans le HTML, le focus, le hover, etc.

Le responsive se fait lui aussi rapidement car la quasi-totalité des classes possèdent des variantes responsives. Par exemple .w-1/2 (width: 50%;) peut s’utiliser comme ceci .lg:w-1/2, ce qui veut dire que l’élément n’aura que width: 50% à partir du breakpoint lg, 1024px par défaut.

À première approche, Tailwind peut faire peur par sa complexité ; cependant il suffit de le tester pour se rendre compte de tout son potentiel. C’est pourquoi tailwind propose Tailwind Play pour permettre à n’importe qui d’essayer en quelques secondes ce nouveau framework.

De plus, pour avoir une vue d’ensemble de tous les outils liés à Tailwind, nous vous conseillons ce repo Github https://github.com/aniftyco/awesome-tailwindcss. Il liste tout ce dont vous avez besoin pour utiliser Tailwind et son énorme potentiel.

Pour finir, ce tableau ci-dessous récapitule les “pour” et “contre” de ce framework nouvelle génération.

Et vous, l’avez-vous déjà testé ? Qu’en pensez-vous ?

Retrouvez l'intégralité de ce tutoriel en ligne sur Alsacreations.com

Partons à la découverte de Timber pour WordPress : un plugin ou une dépendance Composer (au choix) pour mettre en place une architecture MVC.

Timber réalisé par Upstatement sépare le template HTML du code logique PHP en utilisant Twig pour remplacer le templating PHP classique de WordPress.

Quel est l'intérêt ?

En séparant la logique et le template, nous nous retrouvons avec un code non seulement plus propre mais également plus maintenable et facile à comprendre.

En prenant l'exemple ci-dessous, nous constatons aisément qu'il est plus facile de lire et comprendre Twig que PHP lorsqu'il s'agit de templating.

<?php get_header(); ?>
<?php if( have_posts() ) : while( have_posts() ) : the_post(); ?>
<article>
  <h1><?php the_title(); ?></h1>
  <div>
    <?php the_content(); ?>
  </div>
</article>
<?php endwhile; endif; ?>
<?php get_footer(); ?>

Avec Twig :

{% extends "base.twig" %}
{% block content %}
<article>
  <h1>{{ post.title }}</h1>
  <div>
      {{ post.content }}
  </div>
</article>
{% endblock %}

De plus Timber met à disposition des filtres très pratiques.

Utilisation de shortcodes simplifiée :

  <section">
    {{ post.custom_shortcode_field|shortcodes }}
  </section>

Limiter le contenu à 30 mots :

  <p>
    {{ post.post_content|excerpt(30) }}
  </p>

Il facilite également l'utilisation des images et de leurs différentes tailles

  <img src="{{ post.thumbnail.src }}" />

  <img src="{{ post.thumbnail.src('medium') }}" />

Mettre en place Timber

L'installation de Timber est en réalité très simple et n'a pas besoin d'être effectuée sur un WordPress vierge. Il est donc possible de l'ajouter dans un projet déjà existant sans risquer de tout casser. Il cohabite parfaitement avec le templating PHP classique de Wordpress.

Il existe deux solutions pour l'installer : avec Composer ou via WordPress. Le résultat est le même mais il faut noter que la version WordPress n'est pas toujours la plus récente.

Avec Composer

Il suffit de rentrer la commande suivante, à la racine de votre projet WordPress ou bien à la racine de votre thème.

composer require timber/timber

Ensuite, si ce n'est pas déjà le cas, il faudra charger les dépendances Composer dans le projet. Il suffit d'inclure le code ci-dessous dans votre fichier functions.php.

<?php
// Dépendances composer.
require_once __DIR__ . '/vendor/autoload.php';

// Initialisation de Timber.
new Timber\Timber();

Et c'est terminé, Timber est maintenant installé dans le projet et prêt à être utilisé. ✔️

Avec le plugin officiel WordPress

Il suffit de se rendre sur la page du plugin Timber et de l'installer comme d'habitude dans l'admin de WordPress. Une fois téléchargé et activé, Timber est prêt à être utilisé. ✔️

Utilisation concrète

Comme dit précédemment, Timber met en place une architecture MVC (Modèle, Vue, Contrôleur).

Dans WordPress, le modèle est géré par la Template Hierachy et la WP Query. Nous n'avons donc qu'à nous occuper de la Vue et du Contrôleur.

La vue sera gérée par Timber et Twig, et le contrôleur par le code PHP.

Affichage d'un Post

De base, WordPress va chercher le fichier single-post.php, avec Timber, cela ne change pas !

Cependant single-post.php ne contiendra que le code PHP et pas le template HTML.

<?php
$context = Timber::context();
$context['post'] = Timber::get_post();

Timber::render('templates/single-post.twig', $context);

Danc cet exemple, le $context est un tableau PHP que Timber nous génère et qui contient un tas d'informations utiles dans la plupart des templates. Nous aurons par exemple accès au nom du site, la description du site etc...

Ensuite, nous ajoutons la clé post dans ce tableau qui contiendra les données du post en question. Timber nous propose sa propre méthode pour le récupérer.

Enfin, nous disons à Timber de rendre le template single-post.twig en lui passant les informations dont il a besoin.

Dans single-post.twig nous accédons au post avec la clé post, comme défini dans le fichier PHP. Il nous suffit ensuite d'accéder aux différentes propriétés comme le titre, la description, etc.

{% extends "base.twig" %}
{% block content %}

<h1>{{ post.title }}</h1>

{% endblock %}

Cet exemple reprend tout ce dont vous aurez besoin dans la plupart des cas.

Pas si compliqué que ça non ?

Utilisation de fonctions PHP

Dans un fichier Twig il nous est tout de même possible d'utiliser des fonctions PHP native et WordPress. Par exemple get_header() et get_footer().

{{ function('get_header') }}

Découpage en block

Dans les exemples précédents, vous aurez peut-être remarqué les mots extends et block. En effet Timber et Twig ne permettent pas seulement de gérer le templating dans un seul et même fichier.

Partons du principe que nous avons un fichier base.twig regroupant des éléments HTML qui seront présent partout sur le site comme le header et le footer.

{{ function('get_header') }}
  {% block content %}
  {% endblock %}
{{ function('get_footer') }}

En reprenant l'exemple de tout à l'heure, nous spécifions à Timber que nous voulons "compléter" le fichier base.twig. Ensuite il suffit de définir le bloc dans lequel nous voulons injecter le contenu. Ici c'est le bloc content.

{% extends "base.twig" %}
{% block content %}

<h1>{{ post.title }}</h1>

{% endblock %}

Notre résultat sera donc:

{{ function('get_header') }}
  <h1>{{ post.title }}</h1>
{{ function('get_footer') }}

La boucle for

La plus grosse simplification apportée par Timber est la boucle for.

En effet, plus besoin d'ouvrir et fermer des tags <?php et ?> partout, jusqu'à s'y perdre.

Nous nous retrouvons avec une boucle similaire avec ce que nous avons dans Vue.js par exemple.

{% for post in posts %}
<article>
  <h1>{{ post.title }}</h1>
  <div>
      {{ post.content }}
  </div>
</article>
{% enfor %}

Le starter theme

En installant Timber dans un projet vierge, il est vivement conseillé d'utiliser le starter theme officiel.

Il vous donnera directement l'architecture de dossiers correcte pour la maintenabilité du thème. Il vous facilitera grandement tout le travail à faire pour procéder au rendu d'un fichier Twig avec les informations correspondantes etc.

Une fois téléchargé, il suffit de le placer dans le dossier themes de WordPress. Nous nous retrouvons donc avec:

Pour le reste du développement il suffira donc juste de modifier les fichiers Twig selon nos besoins. Les fichiers PHP peuvent eux aussi être modifiés, pour rajouter les champs ACF par exemple.

Conclusion

Bravo ! Vous savez maintenant à quoi sert Twig, et surtout pourquoi c'est super pratique !

• Timber propose une approche à WordPress plus propre et "future-proof" que la méthode traditionnelle. D'ailleurs, il fonctionne parfaitement dans un workflow Wordplate et rend le développement WordPress beaucoup plus moderne et agréable.

• Enfin, si vous êtes un développeur JavaScript, et surtout Vue, la syntaxe Twig sera comme une seconde nature pour vous.

Il est difficile de ne pas recommander Timber étant donné qu'il ne fait que rajouter des fonctionnalités sans nous forcer la main.

Et vous, avez-vous déjà pu tester Timber ?

Retrouvez l'intégralité de ce tutoriel en ligne sur Alsacreations.com

Vous êtes sur le point d'intégrer votre première newsletter à destination de tous les principaux clients e-mail que vous connaissez et vous ne savez pas si Flexbox est reconnu par Outlook, ou bien si votre bouton de formulaire sera pris en compte par Gmail ?

Vous connaissez déjà CanIuse et vous vous dites qu'une ressource équivalente dédiée aux e-mails serait vraiment pratique ?

Par une heureuse coïncidence cet outil existe et s'appelle Can I email, vous êtes sauvés.

Connais ton ennemi

Can I email est un site web conçu et maintenu par Rémi Parmentier (connu sous son pseudo Hteumeuleu et que nous avions interviewé sur Alsacréations).

Grâce à cette ressource, vous n'aurez plus aucun secret sur le support HTML et CSS de tous clients e-mails les plus courants, webmails ou applications, desktop ou mobile : Apple Mail, Gmail, Outlook, Yahoo!, AOL, Samsung, Thunderbird, Protonmail, Orange, SFR, et même Mail.ru.

Une base de donnée impressionnante

La liste des fonctionnalités testées est vaste, très vaste : une grande partie des spécifications HTML, CSS et des formats d'images y est disponible et les résultats sont pertinents.

Tableau d'honneur

Can I email propose divers services complémentaires, notamment un Comparatif des clients e-mail ou les Scores cumulés de l'ensemble des clients, où l'on remarque que les meilleurs élèves ne sont pas forcément ceux qu'on attendait.

Enfin, sachez que Can I email est un projet libre, hébergé sur Github, et que vous pouvez faire évoluer cette ressource en y contribuant ou en signalant des erreurs ou des corrections à apporter.

Courage, votre newletter est déjà presque terminée !

Publié par Alsacreations.com