Si vous voulez construire pour le Web, construisez sur le Web et construisez avec le Web.

Si je ne devais donner qu’un seul conseil aux entreprises, ce serait d’itérer rapidement sur une plateforme qui évolue lentement.

Au cours de la seule année dernière, j’ai vu deux clients complètement différents, dans deux secteurs complètement différents, consacrer des mois et des mois à des mises à niveau de leurs environnement de travail. Collectivement, ils ont dépensé des dizaines, voire des centaines de milliers de dollars pour réécrire des projets entiers dans le seul but de maintenir les mêmes fonctionnalités qu’avec l’itération précédente. Il ne s’agit pas d’un travail utile ou productif, mais de temps perdu à se contenter de rester à la même place.

C’est d’une certaine façon un emprisonnent dans un écosystème, où ajouter la moindre amélioration de performance même la plus triviale devient impossible vu que les framework offusquent, et parfois même empêchent de regarder sous le capot. Le pire ? Vous devrez tout recommencer dans 18 mois ! Vous êtes contraint par les choix technologiques, et vous héritez de toute une équipe de développement qui doit être payée un ou deux trimestres tous les deux ou trois ans, juste pour faire du sur-place.

Elles font des itérations lentes sur une plateforme qui évolue rapidement.

Le plus triste dans tout cela, c’est qu’il s’agit d’anciens clients qui ont dû me réembaucher parce que les « mises à jour » s’accompagnaient de graves régressions de la vitesse du site. Même si c’est bon pour les affaires, je déteste faire le même travail avec le même client plus d’une fois. Après tout, on ne devrait jamais avoir à appeler deux fois le dératiseur.

Le Web en tant que plateforme est une valeur sûre. Par conception il n’a pas de version. C’est l’engagement que le Web prend à votre égard : profitez-en.

1. Adopter progressivement les fonctionnalités de la plate-forme Web. Pour paraphraser mon ami Ryan Townsend : les clients ne veulent pas des transitions de page fluides – ils veulent un site Web qui fonctionne. Ne faites pas de votre site une Single Page Application unique juste pour ne pas avoir à renvoyer une en-tête et un pied de page.

2. Adoptez l’amélioration progressive pour créer des applications rapides et fiables qui s’adaptent au contexte de vos clients. L’intérêt d’opter pour les fonctionnalités de la plateforme Web au fur et à mesure qu’elles sont disponibles est que votre site devient adaptatif. La même base de code s’adapte à son environnement, en jouant sur ses points forts, plutôt que d’essayer de construire et d’expédier votre propre environnement à partir de zéro. Rencontrez vos utilisateurs là où ils se trouvent.

3. Écrivez un code qui s’appuie sur le navigateur, et non qui s’en éloigne. En utilisant l’amélioration progressive, vous pouvez opter pour des fonctionnalités natives du navigateur qui sont généralement plus rapides, plus accessibles, plus sûres et, ce qui est peut-être le plus important pour l’entreprise, maintenues par quelqu’un d’autre.

Tout cela me rappelle douloureusement quelque chose. En 2007 déjà, Dan Cederholm nous présentait do­WebSites­Need­To­Look­Exactly­The­Same­In­Every­Browser.com (je vous épargne le click : la réponse est non). Il y a près de 20 ans, la discussion portait sur des aspects visuels beaucoup plus triviaux, tels que les coins arrondis et les ombres portées, mais le sentiment reste vrai aujourd’hui : il est totalement absurde d’envoyer des centaines de kilo-octets de JavaScript pour donner à un site par ailleurs statique une navigation souple et douce. De nos jours, il suffit d’une ligne de CSS¹ et, dans le pire des cas, les navigateurs qui ne le prennent pas en charge parcourent votre site comme ils ont toujours été conçus pour le faire. Votre escalator est devenu un escalier.

La plateforme Web évolue lentement, et je comprends que cela puisse être frustrant pour les développeurs qui veulent innover, mais plus d’une décennie d’expérience en matière de conseil m’a appris à maintes reprises que l’alternative est beaucoup plus restrictive à long terme. Ce qui est tout nouveau aujourd’hui commence à montrer des signes de vieillissement beaucoup plus rapidement que quelque chose qui a déjà résisté à l’épreuve du temps.

Chaque couche d’abstraction réalisée dans le navigateur vous éloigne de la plateforme, vous enferme davantage dans un cadre et vous éloigne de la performance.

Je reste convaincu que le développeur moyen n’en sait pas assez sur l’analyse commerciale et que l’analyste commercial type n’en sait pas assez sur le développement pour réconcilier pleinement les deux côtés de la médaille. Des discussions plus approfondies et plus équilibrées, à long terme, doivent être menées par les deux parties, car le verrouillage (et son coût permanent) est bel et bien réel, et les paillettes d’aujourd’hui seront rapidement le boulet de demain.

Je ne suis pas contre les frameworks front et, croyez-moi, je ne suis pas assez naïf pour croire que la seule chose qu’un frameworks front apporte, ce sont des transitions entre pages agréables, mais si vous vous apprêtez à en utiliser un, il faudrait que je ne sois pas en mesure de pouvoir le détecter.

Si vous optez pour un frameworks ou, à défaut, pour une Single Page Application, pensez sérieusement au long terme et assurez-vous de faire du très bon travail.

C’est Nolan Lawson qui a le mieux résumé la situation lorsqu’il a déclaré que « la meilleure Single Page Application est meilleure que la meilleur site Web multi-page ; la Single Page Application moyenne est pire que le site Web multi-page moyen ».

Quand on tronque un contenu avec un overflow: hidden, on peut définir la manière dont les textes se comporteront avec text-overflow. Généralement ce sont des points de suspension qui sont choisis. Notez que le résultat est uniquement visuel : cela n’affecte pas les lecteurs d’écrans par exemple.

.ellipsis {
    overflow: hidden;
    text-overflow: ellipsis;
    white-space: nowrap;
}

Safari propose de pouvoir accéder à l’intégralité du contenu via une infobulle, qu’il génère automatiquement en fonction de si le contenu déborde ou non. Plutôt malin, même si ça ne fonctionne que sur ce navigateur à ma connaissance et qu’en version desktop.

Si on ne souhaite pas de cet ajout (car on implémente son propre système d’infobulles par exemple) il va falloir ruser. Ajouter un attribut title vide ne fonctionne pas.

Seules solutions trouvées relativement indolores :

• ajouter une div vide à côté du texte potentiellement tronqué ;
• ou générer un pseudo élément vide avec un display: block (si on souhaite contrôler ça via CSS).

Le CodePen dédié au sujet est ici.

J’ai trouvé cette façon de faire très intéressante (bien qu’un peu obscure au premier abord – ce qui semble être son défaut principal) et je l’ai éprouvée plusieurs fois dans des cas réels.

C’est pour ces raisons que je me permets de proposer ici mon analyse de la technique, en français.

Objectifs

Rendre une interaction accessible nécessite certains basiques.

Il vous faut un élément :

• qui se signale comme actionnable ;
• qui soit atteignable avec le périphérique de saisie comme avec le périphérique de pointage ;
• qui remonte un état sémantique et visuel reflétant la position de l’interaction ;
• qui déclenche un comportement quand l’interaction sera lancée.

Imaginons maintenant que cette interaction n’a de sens que quand le composant qui l’abrite possède une largeur étroite (comme sur mobile par exemple) mais qu’elle se désactive sur une largeur plus importante.

Il va falloir alors désactiver (en desktop) tout ce qui a été fait plus haut :

• l’élément actionnable ne doit plus se signaler comme tel ;
• il ne doit plus être atteignable ni au clavier ni à la souris ;
• l’état sémantique et visuel de l’interaction ne doit plus apparaître ;
• et aucun comportement ne doit pouvoir se déclencher.

Problème : tout cela demande de modifier fortement le DOM, et d’ajouter un écouteur sur la largeur du viewport (ou du composant).

Un cas concret

Imaginons un motif de conception tel qu’un panneau dépliant (disclosure).

En mobile, on imagine un code de ce type :

<h3>
    <button class="toggle" type="button" aria-expanded="false" aria-controls="panel">
        Titre
        <span class="toggle-arrow" aria-hidden="true">
            <span class="toggle-arrow-up">↑</span>
            <span class="toggle-arrow-down">↓</span>
        </span>
    </button>
</h3>
<div id="panel">
    <p>Panneau affiché ou masqué.</p>
</div>

Et en desktop, on s’attend plutôt à ceci :

<h3>Titre</h3>
<p>Panneau toujours affiché.</p>

Ce que Scott propose, c’est une technique basée sur la propriété CSS visibility pour basculer de l’un à l’autre, uniquement via une modification CSS.

Comment ça marche ?

La propriété visibility: hidden à la réputation ne pas être accessible, à raison, car si elle masque visuellement comme on pourrait s’y attendre l’élément ciblé, elle lui supprime également tout accès :

• sémantique ;
• avec un périphérique de saisie ;
• avec un périphérique de pointage.

Or, il se trouve que c’est ce qui nous intéresse ici (du moins en desktop) !

Et il se trouve de surcroît que visibility: hidden peut être annulée sur ses descendants avec un visibility: visible.

Quelque chose qui serait impossible avec aria-hidden ou opacity: 0 par exemple.

Bref, on a tout ce qu’il nous faut pour basculer d’une version à l’autre, en appliquant (ou non) la propriété au bon endroit.

Le résultat

Voici ce que ça peut donner avec un code complet. Charge à vous de redimensionner votre navigateur pour basculer de la vue mobile à la vue desktop.

À travers une technologie d’assistance, voici un exemple de la vocalisation qui sera alors faite sur le titre.

• En desktop : Niveau d’en-tête 3, Lorem ipsum.
• En mobile : Niveau d’en-tête 3, Lorem ipsum, Étendu, button, groupe.

Un exemple avec un clip-path sur un élément qui se voit rogné sur ces quatre côtés de 10 pixels :

clip-path: inset(10px round 20px);

Exemples de clip path avec ou sans le second paramètre.

Il est bien sûr possible de passer des valeurs multiples si on ne souhaite pas un rognage ou un arrondi identique aux quatre coins :

 clip-path: inset(10px 0 0 20px round 20px 60px 0);

Exemples de clip path avec les paramètres possédant des valeurs multiples.

Combiné à d’autres propriétés (ou non), ce paramètre permet des effets intéressants :

Exemple interactif.

Fonctionnement

Pour l’utiliser, il va falloir obligatoirement préciser à la fonction votre espace de couleur, ce qui peut faire un peu peur.

Si vous n’en avez aucune idée, il y a de grandes chances que cet espace soit sRGB.

Je connais assez mal le sujet des espaces de couleurs, mais je crois pouvoir dire :

• qu’il s’agit de diverses abstractions pour représenter les couleurs dans l’espace (bidimensionnel ou tridimensionnel) ;
• que chaque représentation a ses défauts et ses inconvénients (facilité de lecture, prédiction de couleur lorsqu’elles sont mélangées, naturel dans la création de dégradés…) ;
• que sRGB a été pendant longtemps la référence, mais qu’il sera bientôt remplacé par OKLCH.

Une fois votre espace de couleur défini, il restera à passer en paramètre deux couleurs, éventuellement accompagnées de leurs proportions respectives (exprimées en pourcentages).

Par exemple : color-mix(in srgb, red 25%, blue).

Après quelques tests, quelques enseignements :

• on ne peut passer que deux couleurs (pas plus, pas moins) ;
• l’ordre des couleurs n’importe pas ;
• si les deux proportions ne sont pas définies, elles seront automatiquement à 50 % respectivement ;
• si une des proportions n’est pas définie, elle sera automatiquement calculée pour que le total soit à 100 % ;
• si le total des proportions dépasse les 100 %, elles seront rééquilibrées proportionnellement pour que le total soit à 100 % ;
• si le total des proportions n’atteint pas les 100 %, la couleur résultante deviendra semi-transparente à la hauteur de la proportion manquante.

Avantages

La fonction étant native à CSS, cela lui offre des possibilités qu’on ne pouvait atteindre avec des alternatives comme Sass.

La semi-transparence avec transparent

On peut passer comme couleur de mélange le mot-clef transparent, ce qui permet de facilement rendre une couleur semi-transparente.

C’est l’équivalent de natif la fonction transparentize() de Sass.

Les variables avec CSS vars

Chaque paramètre de la fonction peut être géré avec une variable CSS si nécessaire. Je pense que ça peut être pratique, notamment pour définir l’espace de couleur.

.colorMix {
  background-color: color-mix(
    in var(--colorSpace, srgb),
    var(--color1),
    var(--color2)
  );
}

<div class="colorMix" style="--color1: blue 25%; --color2: red 75%"></div>

Quelque soit la manière dont sera définie une couleur (en hexadécimal par exemple), elle pourra être mixée avec de la transparence.

Ce point est particulièrement intéressant si vous regroupez toutes vos couleurs dans des palettes au sein de votre design system et que vous souhaitez introduire des variations d’opacité sur cette base.

Bonne nouvelle supplémentaire : il semblerait que l’espace de couleur importe peu dans ce cas de figure. Impossible donc de se tromper ici.

La couleur courante avec currentColor

Si on souhaite produire par exemple des palettes qui s’appliquent à des composants (imaginons un message de succès en vert, d’erreur en rouge, et d’avertissement en jaune) il sera très facile de ne passer qu’une couleur (celle du texte), et de créer des variations (d’opacité, de luminosité…) aux propriétés qui définissent l’apparence du composant en jouant à la fois avec color-mix() et currentColor.

Côté Sass, les fonctions de luminosité sont lighten() et darken(), mais là encore, il est impossible de leur passer des variables CSS.

Pour conclure, voici le CodePen qui vous permettra de tester tout cela pour vous même.

L’exemple classique pour décrire la mise en place d’un piège pour le focus, c’est l’ouverture d’une boîte de dialogue modale.

« Modale » signifie que l’accès à son contenu est exclusif ; le reste (en dehors du dialog) est interdit et cela est signifié de plusieurs manières :

• graphiquement, avec un arrière-plan (souvent semi-transparent) qui vient recouvrir les parties désactivées ;
• mécaniquement, avec ce même arrière-plan qui empêche de cliquer sur les éléments qui se situent en dessous ;
• sémantiquement, avec une désactivation de toute la partie de l’arbre DOM associée (très souvent via un aria-hidden).

Et je n’oublie pas la navigation au clavier (puisque c’est notre sujet) ; celle-ci doit être réduite exclusivement au contenu de la boîte de dialogue :

1. On détecte le dernier élément focusable (ainsi que le premier) de notre boîte de dialogue.
2. On écoute les tabulations clavier.
3. Si une tabulation est déclenchée lorsque le focus est sur le dernier élément, on déplace le focus sur le premier (et inversement en cas de navigation arrière).

Nous voilà avec un beau focus trap !

Sauf que…

On souhaitait désactiver la navigation clavier sur une partie du DOM ; et on l’a finalement piégée dans l’autre partie.

C’est presque pareil mais… Si on souhaite atteindre la barre d’adresse du navigateur, il n’est plus possible d’appuyer uniquement sur la tabulation pour ça. Heureusement, il existe d’autres raccourcis claviers dans les technologies d’assistance pour cela, mais on a quand même cassé quelque chose.

Une autre piste ?

L’autre approche connue, c’est de lister tous les éléments focusables en dehors de la boîte de dialogue et de les désactiver avec un tabindex négatif.

Ça fonctionne mieux et c’est plus logique, mais ça demande de ne rien oublier (ni à la désactivation, ni à la réactivation).
Et ça peut amener à modifier énormément de nœuds DOM (ce qui n’est jamais très bon signe).

La solution moderne

On cherche donc sur plusieurs éléments :

• à désactiver les clics ;
• à désactiver les focus ;
• à supprimer leurs sémantiques ;
• tout en conservant leurs apparences.

Il existe un nouvel attribut universel appelé inert qui fait tout ça d’un coup, et qui permet de le faire en ciblant directement le parent commun de tout les éléments que nous souhaitons désactiver.

Avec très peu de modifications du DOM et sans modifier le comportement natif de focus, nous avons le résultat souhaité !

Un autre cas pratique

Devinez ce qu’il serait possible de faire pour les éléments d’un carrousel qui ne sont pas visibles ?

Je pense que nous avons là une solution tout à fait adaptée, facilement combinée avec Intersection Observer par exemple.

Aussi, on peut vouloir y placer un indicateur graphique ou textuel qui remplira la cellule.

La restitution des cellules vides peut différer en fonction du lecteur d’écran que vos utilisateurs utilisent, mais elle devrait rester identique quel que soit le tableau parcouru.

Avec VoiceOver sous Mac, on peut entendre par exemple « vierge, colonne trois sur quatre » ; et je ne souhaite pas que l’ajout d’un caractère typographique décoratif vienne perturber cette restitution.

La pseudo-classe :empty semble idéale ici :

• elle va permettre de détecter les cellules vides ;
• l’injection d’un contenu via un pseudo-élément n’aura pas d’impact sur celle-ci.

Mais comme nous l’avons vu par le passé, les contenus générés dans des pseudo-éléments sont vocalisés, nous allons donc essayer d’empêcher ça.

CSS prévoit la possibilité de passer une alternative aux contenus générés via cette syntaxe :

::before {
    content: '★★★' / 'Trois étoiles';
}

On pourrait donc envisager d’écrire quelque chose du style :

td:empty::before {
    content: '–' / '';
}

Malheureusement, le support de cette syntaxe reste trop aléatoire à ce jour.

Je retiens donc une solution qui ne se base pas que sur CSS, et je préfère injecter dans mes cellules vides ce petit bout de HTML :

<td><span aria-hidden="true" data-before-content="–"></span></td>

Le aria-hidden permet de conserver une sémantique de cellule vide, et le tout combiné à cette règle CSS, cela fonctionne parfaitement :

[data-before-content]::before {
    content: attr(data-before-content);
}

Avantages à passer ainsi par un attribut de donnée (data-*) :

• le contenu textuel reste décoratif et lié à la présence de CSS ;
• il serait plus facile de le traduire (si besoin) sans devoir générer des fichiers CSS dédiés aux langues.

Le CodePen qui permet de tester les différentes approches est ici.

Je ne vais pas refaire l’atelier ici, mais je constate souvent que cette méthode de positionnement est difficile à appréhender.

Personnellement j’aime imaginer une boîte dont le positionnement lui donne la capacité de glisser au sein de son conteneur (direct). Et ceci dans le but de rester le plus longtemps possible visible dans la zone scrollable la plus proche.
Par extension, il faut donc que le conteneur de la boîte positionnée ait une taille plus grande que celui-ci.

Après avoir parcouru avec mes collègues différents cas pratiques pour illustrer ce concept, j’ai regretté de ne pas avoir d’exemple montrant qu’on pouvait appliquer l’effet dans les quatre directions à la fois (top/bottom/left/right). Je savais que le concept fonctionnerait mais je n’arrivais pas à l’implémenter.

C’est ma collègue Nina qui m’a permis de débloquer l’idée et cela a abouti à ce CodePen. Je l’aime beaucoup car il réalise un comportement qui apparaît relativement magique au regard du nombre de lignes associé.

Sans rentrer dans les détails, voici un condensé des technologies mises en jeu :

• la position sticky pour que le point rouge soit toujours visible ;
• une variable CSS pour que les éléments puisse avoir les tailles relatives nécessaires ;
• une grille pour réaliser son conteneur avec une astuce sur ses couleurs de fond pour faire apparaître ses gouttières ;
• des scrollbars masquées visuellement (mais toujours présentes) quand cela est possible ;
• une gestion des dépassements sur la zone de défilement ;
• de l’adhérence sur le scroll pour que la vue se fige toujours sur certains alignements ;
• et une petite fonction JS pour initialiser la vue.

• Est-ce que je vais continuer ? Sans doute pas à ce rythme mais j’aimerais bien.
• Qu’est-ce que j’en retire ? Des apprentissages ! Une envie de m’amuser ici avec la technique.
• Est-ce que ça vous intéresse ? J’espère mais n’hésitez pas à le dire. Ici ou ailleurs, ça fait toujours plaisir.
• Le niveau technique est-il celui que vous attendez ? J’essaye de ne pas trop forcer pour pouvoir publier plus facilement mais autant que ça vous serve quand même un peu.

Et pourquoi je me donne ce mal au fait ?

Le constat est simple : je trouve que le Web ne va pas fort en ce moment, et je voulais à ma petite échelle montrer un peu l’exemple.

• L’exemple du Web qu’on peut apprendre à son rythme, bricoler chez soi, et s’en faire un outil personnel d’expression.
• L’exemple du Web qu’on peut mettre en place avec un simple bloc-notes et un espace personnel, et qui n’a pas besoin que ce soit beaucoup plus technique.
• L’exemple du Web indépendant qui n’a pas besoin d’une plateforme tierce modératrice ou éphémère.
• L’exemple du Web hors des réseaux sociaux, qui ont fini par montrer leurs limites.
• L’exemple du Web où l’on publie pour être lu par des humains. Et pas par des robots, qu’ils soient là pour amener du traffic ou en générer ailleurs.
• L’exemple du Web où l’on dicte ses règles et où l’on choisit quels usages pourraient être faits de nos contenus.

Faire son site personnel quoi. Et un Web comme on l’entend.

Avec un sélecteur d’attribut sur la valeur ?

<input type="text" value="foo" />

[type="text"][value] {

}

Ça fonctionne mais ça n’a rien de dynamique. Si l’utilisateur modifie la valeur dans le champs, cela n’aura aucun impact.

Avec une pseudo-classe :empty ?

[type="text"]:empty {

}

Ça ne fonctionne pas. La pseudo-classe ne s’applique que si l’élément n’a aucun enfant, mais notre input ne peut même pas en contenir.

Avec une pseudo de classe sur la validité du champ ?

<input type="text" required="required" />

[type="text"]:valid {

}

Ça fonctionne mais l’attribut requis est imposé sur le champ pour que la mécanique puisse se mettre en place, ce qu’on ne souhaite pas toujours.

Avec une pseudo-classe inversée sur l’affichage du placeholder ?

<input type="text" placeholder="foo" />

[type="text"]:not(:placeholder-shown) {

}

C’est la bonne approche, elle fonctionne parfaitement. La logique du sélecteur doit cependant être inversée avec un :not pour que ce soit l’absence du texte de substitution qui soit détectée, et non sa présence.

Et si je n’utilise souhaite pas afficher de placeholder ?

<input type="text" placeholder=" " />

Avec une espace insécable, par nature invisible, on retrouve le même comportement sans que l’UX en soit altérée d’aucune manière.

Fabien me pointe la solution officielle prévue par CSS, malheureusement supportée nulle part.

Et comme toujours un petit CodePen de test dédié au sujet.