La vie en #ffoodd

Masquage accessible de pointe

Gaël Poupard — Tue, 11 Mar 2025 01:00:00 GMT

La classe de masquage accessible .visually-hidden — anciennement .sr-only dans Bootstrap — a beaucoup évolué au fil du temps. C’est pour ça que j’ai publié cache-cache CSS il y a quelques années, qui récapitulait l’état de l’art à ce moment.

Mais il n’y a pas que les techniques CSS qui évoluent… Les navigateurs, aussi. Et parfois, ça requièrs de l’adaptation !

Un cas légendaire

Louis-Maxime Piton — un des mainteneurs de Boosted (en anglais) et inévitablement contributeur à Bootstrap (en anglais) — a proposé un correctif (sur GitHub, en anglais) il y a plus de deux ans pour contourner un problème provoqué par le masquage accessible appliqué à une légende de tableau (sur StackOverflow, en anglais).

Les caption, lorsqu’ils sont en position absolue, sont considérés comme des cellules de tableaux anonymes — et ça met la grouille dans la fusion des bordures, l’indispensable border-collapse: collapse.

Le correctif proposé est simplissime, bien qu’il puisse théoriquement poser des problèmes : n’appliquer la position absolue que si l’élément n’est pas un caption. C’est l’état actuel du mixin dans Bootstrap (sur GitHub, en anglais).

En résumé, voici la modification :

.visually-hidden:not(caption) {
	position: absolute !important;
}

En cas de débordement

La semaine dernière, l’ami Django Janny a relancé le sujet sur Gist (en anglais) avec un cas marginal : un élément qui déborde, à l’intérieur d’un élément masqué visuellement.

En général, on ne masque qu’une portion de texte de cette façon : aucun élément bloc ne devrait s’y trouver — ni, en réalité, aucun enfant. La majorité du temps, le masquage accessible respecte implicitement les mêmes règles qu’un attribut aria-label par exemple : un texte simple et concis.

Mais c’est une règle implicite, et à ma connaissance aucune contre-indication n’a jamais été mentionnée quant à l’utilisation du masquage accessible sur une portion de DOM plus riche. Je l’ai par exemple fait lorsque j’ai amélioré les liens d’évitements sur la documentation de Bootstrap (en anglais), dont le conteneur est masqué visuellement — mais il apparaît à la prise de focus, nous faisant passer à côté du problème…

Depuis (au moins) 2019, les éléments en débordement deviennent focusables dans la plupart des navigateurs, pour palier un défaut d’accessibilité : ne pas pouvoir interagir avec un élément masqué par un débordement. Cassey Lottman a retracé ce changement dans son article Elements with overflow: scroll become focusable (en anglais).

Ce qui, dans un élément masqué visuellement, devient un piège : on ne voit (évidemment) pas le focus.

La solution proposée par Django — et après quelques tests, la seule qui paraisse fonctionner — est d’empêcher le débordement sur les enfants d’un élément masqué visuellement (sur CodePen, en anglais) :

.visually-hidden * {
	overflow: hidden !important;
}

La totale

Voici donc la version mise à jour de la technique de masquage accessible :

.visually-hidden,
.visually-hidden-focusable:not(:focus, :focus-within) {
	border: 0 !important;
	clip-path: inset(50%) !important;
	height: 1px !important;
	margin: -1px !important;
	overflow: hidden !important;
	padding: 0 !important;
	width: 1px !important;
	white-space: nowrap !important;
}

.visually-hidden:not(caption),
.visually-hidden-focusable:not(caption):not(:focus, :focus-within){
	position: absolute !important;
}

.visually-hidden *,
.visually-hidden-focusable:not(:focus, :focus-within) * {
	overflow: hidden !important;
}

J’en ai profité pour proposer ce changement dans Bootstrap (sur GitHub, en anglais) — en citant Django bien entendu — et pour mettre à jour le Gist servant souvent de référence (en anglais).

Notez par ailleurs quelques autres changements succincts :

J’ai renommé .sr-only en .visually-hidden pour me conformer aux usages des frameworks populaires,
Et nettoyé un peu le support de navigateurs anciens : plus de clip désormais, car clip-path est très largement supporté.
La variante pour démasquer le contenu lors de la prise de focus n’est plus une remise à zéro, mais une autre classe conditionnée à l’état : .visually-hidden-focusable:not(:focus, :focus-within), à l’instar de ce qui est fait dans Bootstrap depuis cinq ans déjà (sur GitHub, en anglais) mais avec la syntaxe moderne de :not().

25^e jour de web

Gaël Poupard — Wed, 08 Jan 2025 01:00:00 GMT

C’est un exercice très intéressant, car nous avons deux contraintes très spécifiques pour le thème visuel annuel :

le format calendrier : 24 cases à ouvrir, une par jour…
l’illustration, réalisée bénévolement après un appel sur nos différents réseaux sociaux — et généralement reçue moins de quinze jours avant l’ouverture du calendrier !

Et plus les contraintes sont exotiques, plus les solutions sont astucieuses !

C’était une très chouette expérience en 2023, avec l’illustration de Sophie Rocher qui m’a inspiré un calendrier tout en fenêtres et en lumières. Je me suis beaucoup amusé et vous invite à jeter un œil aux CSS.

Pour 2024, Laure Février nous a gratifiés d’une illustration riche en décorations : boules de Noël, couleurs, chats et lutins ! Maintenant, à moi de jouer pour en extraire la substantifique moelle et réaliser une intégration cohérente qui tire parti et mette en valeur l’illustration de Laure.

Note : certains exemples de code ne sont pas présents dans l’article, je vous encourage à inspecter le code directement sur site.

Le calendrier

Les Blobs

Le premier élément qui nous a plu dans cette nouvelle illustration, c’est le « cadre » offert par la forme en arrière-plan. Appelons-le Blob.

Je savais en voyant cette forme que je pourrais mobiliser une astuce CSS rarement utile : le fait que border-radius est en réalité une propriété raccourcie. On trouve parfois une utilisation avec quatre valeurs, une pour chaque angle — par exemple border-top-left-radius… Mais saviez-vous que chacune de ces valeurs est également une propriété raccourcie, qui peut prendre deux valeurs ?

La logique est simple : avec une seule valeur, vous définissez le rayon du cercle ; avec deux valeurs, vous définissez les axes horizontaux et verticaux d’une ellipse.

Et si vous comptez bien, ça signifie que vous pouvez utiliser huit valeurs distinctes dans la propriété border-radius, et c’est drôlement pratique pour dessiner des formes irrégulières sans passer par un path.

Et puisque je suis un flemmard notoire, j’ai farfouillé les internets pour trouver un générateur de formes irrégulières basées sur border-radius. Évidemment, j’en ai trouvé plusieurs, et j’ai utilisé celui de Milos Lekovic que j’ai fourché pour définir une couleur d’arrière-plan au lieu d’appeler une image qui retourne une 404.

Ça donne quelque chose comme ça, répété pour chacune des 24 cases du calendrier :

.calendar > :first-child {
	border-radius: 65% 35% 34% 66% / 58% 30% 70% 42%;
}

Les boules de Noël

C’est le second élément le plus marquant dans l’illustration. Leur forme circulaire et leurs couleurs sont très présentes, et clairement un élément visuel sur lequel capitaliser. Il y en a quatre, et cette fréquence m’a immédiatement fait comprendre comment réutiliser cet élément visuel : les numéros de chaque case, symbole fort du calendrier de l’avent.

Il existe des solutions simples pour les quelques éléments de langages visuels présents dans les boules de l’illustration :

C’est un cercle : on utilise la même valeur pour la hauteur et la largeur afin d’avoir un carré parfait, puis border-radius: 50% pour un cercle.
C’est une sphère : un radial-gradient() pour l’arrière-plan et box-shadow pour renforcer l’effet visuel de relief font très bien le boulot.
C’est brillant : un conic-gradient() couplé à un radial-gradient en mask-image sur un pseudo-élément donne un reflet suffisamment convaincant.
C’est coloré : la fonction color-mix() permet de décliner la couleur de la boule et de ses effets en fonction d’une seule couleur en entrée.

.day-number {
	background: var(--color-number-bg) radial-gradient(circle at 66% 66%, #fff9, transparent 50%);
	border-color: color-mix(in srgb, var(--color-number-bg), #fff 50%);
	box-shadow: 0 0 1rem #fff;
	color: color-mix(in srgb, var(--color-number-bg), #000 50%);
}

.day:nth-child(3n + 1) { --color-number-bg: #eb8181; }
.day:nth-child(3n + 2) { --color-number-bg: #439d7d; }
.day:nth-child(3n + 3) { --color-number-bg: #ffed9f; }

.day-number::before {
	background: conic-gradient(transparent 10%, #fff 33% 66%, transparent 90%);
	border-radius: 50%;
	mask-image: radial-gradient(transparent 60%, #0003 60%);
}

L’accroche de la boule est une version simplifiée de celle dans l’illustration, simplement appliquée en image d’arrière-plan sur un pseudo-élément.

Et voilà, de jolies boules de Noël pour décorer notre calendrier !

C’est déjà très joli, mais ces boules suspendues ont clairement envie de bouger, non ?

Les animations

Je savais qu’une animation légère était possible — et clairement, il fallait que ça reste très léger pour ne pas donner envie de vomir à tout le monde…

Commençons par un cas simple.

Les boules de Noël en CSS

Le mouvement de pendule, ou de balancier, est une animation que je n’ai pas eu l’occasion de travailler auparavant. Elle me paraissait relativement complexe, et une bonne candidate pour une technologie d’animation que je n’avais pu utiliser jusqu’à présent : motion path en CSS.

Motion path

C’est une spécification déjà datée, plutôt simple car inspirée de SVG, mais dont le support est disparate. En l’occurrence, l’utilisation de offset-path (pour le tracé de l’animation) et offset-distance (pour la position sur le tracé) suffit à atteindre la cible, avec un support satisfaisant.

@keyframes balance {
	50% { offset-distance: 26%; }
}

.day-number {
	animation: balance 4s ease-in-out infinite;
	offset-distance: 24%;
	offset-path: ellipse(6.75rem 5rem at 50% -6%);
	offset-rotate: reverse;
	will-change: offset-distance;
}

Et voilà une animation de la position (de 24 à 26%) sur un tracé elliptique, qui se répète à l’infini.

Cependant, malgré l’utilisation de will-change, cette méthode d’animation est vraiment peu performante et Lighthouse indiquait clairement ce problème, perceptible à l’œil nu.

Retour aux transformations

Revenons-en aux basiques des animations CSS performantes : transform !

Après quelques nœuds au cerveau, j’ai pu appréhender le mouvement de pendule : c’est effectivement une simple rotation, mais avec un point d’origine éloigné à l’aide d’un transform-origin: 50% -300%.

Une rotation légère (de 3deg à -3deg) et un délai différent toutes les trois boules (sur une ligne de 4) rend l’animation très organique, et relativement naturelle.

Une étape supplémentaire aurait pu permettre d’améliorer encore les performances : utiliser les propriétés individuelles de transformation à la place des fonctions (en l’occurrence rotate au lieu de transform: rotate()). Bien que mise en place, cette modification n’a eu qu’un effet négligeable sur les performances.

L’entête

L’illustration elle-même, dans l’entête, était livrée au format SVG. C’est chouette car ça permet une grande souplesse dans l’implémentation.

Pour éviter de trop s’éloigner de l’intégration habituelle des thèmes annuels, j’ai conservé l’intégration de l’illustration en CSS via background-image et la fonction url(). Fort heureusement, des animations déclarées dans le SVG source sont exécutées même dans ce contexte, ce qui permet de travailler dans le fichier source directement.

Les animations SVG

Ma première initiative était d’utiliser les animations SVG SMIL, et notamment l’élément <animateTransform> pour animer l’attribut rotate.

Je ne l’avais jamais employé et ai eu du mal à comprendre son fonctionnement, notamment que l’effet s’applique sur le parent et par conséquent que les coordonnées (par exemple, le x des rotations dans values) devaient correspondre au transform-origin.

<g transform-origin="200 0" transform="translate(-172)">
	<animateTransform values="-0.5 200 0;0.5 200 0;-0.5 200 0" 
										attributeName="transform" type="rotate" 
										dur="4s" repeatCount="indefinite" 
										additive="sum"/>
</g>

À noter que pour que les autres transformations (notamment la translation) soient cumulées avec la rotation animée, l’ajout de l’attribut additive="sum" est indispensable.

Désactiver les animations

On a beau être bénévoles, on essaie de faire au mieux — et en l’occurrence respecter les préférences utilisateur. Dans le cas des animations, le minimum sur le plan technique est d’honorer la media query prefers-reduced-motion.

Dans le cas de cette illustration, nous ne pouvons pas utiliser la méthode JavaScript svg.pauseAnimations() puisque le SVG est embarqué via CSS — il n’est pas dans le DOM.

L’astuce que j’ai trouvée dans les bas-fonds des internets est de définir un display: contents sur l’élément <g class="boule"> animé : <animateTransform> perd sa cible et devient donc inerte. Ça fonctionne, et ça n’est que du CSS !

Cette portion de CSS est embarquée dans le SVG au sein d’un élément <style>.

@media (prefers-reduced-motion: reduce) {
	.boule {
		display: contents;
	}
}

Mais… WebKit

WebKit (le moteur de rendu de Safari, notamment) n’affiche plus du tout les groupes affublés d’un display: contents, que ce soit sur Epiphany ou Safari Technology Preview 209.

C’est le premier ticket de bug ouvert sur WebKit (en anglais) dans le cadre de ce chantier. Cette astuce n’est donc pas viable pour le moment…

Re-changement de stratégie : on va utiliser des animations et transformations CSS, dans le SVG, dans le CSS ! Ça n’est pas aussi compliqué qu’il y parait.

CSS dans SVG dans CSS

L’animation des boules est récupérée et adaptée aux groupes correspondants dans le SVG, en composant les transformations pour conserver le translate indispensable au bon placement des groupes dans l’illustration.

.boule {
	transform-origin: 50% 0%;
	transform: var(--translate);
}

@media (prefers-reduced-motion: no-preference) {
	@keyframes balance{
		50% { transform: var(--translate) rotate(-3deg); }
	}

	.boule {
		animation: balance 6s ease-in-out infinite;
		transform: var(--translate) rotate(3deg);
	}
}

La translation étant propre à chacun des groupes, elle est définie à l’aide d’une propriété personnalisée sur l’élément lui-même — à l’instar du délai de l’animation :

<g class="boule" style="--translate: translateX(-172px); animation-delay: .5s">

L’origine des animations CSS dans un SVG

Mais là, surprise : les boules semblent suivre la même animation, comme si l’origine de la rotation était la même pour les quatre !

Après quelques recherches, j’ai découvert qu’il fallait indiquer transform-box: fill-box aux éléments dans un SVG pour que transform-origin ait un effet sur eux, sans quoi c’est en réalité la viewBox qui sert d’origine à toutes les transformations CSS au sein d’un SVG ! Il suffisait de le savoir…

.boule {
	transform-box: fill-box;
}

Et ça fonctionne !

Oui, mais…

En cherchant à vérifier le respect des préférences liées aux animations, j’ai pu constater que les émulateurs proposés dans les outils de développement de WebKit et Chromium ne propageaient pas l’état de la préférence aux SVG embarquées dans un background-image CSS — alors que c’est fonctionnel avec la préférence modifiée sur le système.

Voici donc le bug numéro deux chez WebKit (en anglais) et le même bug chez Chromium (en anglais).

Ce sont les derniers, promis.

Plot twist : les performances

Je récapitule :

Nous avons des animations qui fonctionnent en CSS, à la fois côté CSS global et à l’intérieur du SVG de l’illustration ;
Elles respectent les préférences utilisateur ;
Et utilisent les techniques d’animation recommandées pour de bonnes performances.

Pas mal, non ?

Mais alors… Pourquoi l’animation de l’illustration semble grippée, sur Chromium et WebKit ?

Figurez-vous que c’est un choix délibéré de ces moteurs de rendu. Il semble que l’utilisation d’animations CSS dans un SVG embarqué en CSS soit trop peu courant pour faire l’effort de les optimiser lors du rendu. Je suis le seul à faire ce genre de choses, alors ?

Après une micro-formation avec Anthony Ricaud sur les outils de développement de Chromium, nous avons pu identifier le problème et avancer une correction possible : sortir les éléments animés du SVG principal pour que les animations soient effectivement dans le CSS global, et pas embarquées dans le SVG.

En exportant les quatre éléments à animer, j’ai pu les inclure dans des pseudos-éléments sans avoir à modifier le DOM. Parfait !

Reprendre les animations revenait presque à faire un copier-coller. J’ai surtout eu à ajuster les dimensions et positions des boules pour chaque point de rupture ; jusqu’à présent, jouer avec les background-size et background-position suffisaient, mais ce n’est plus le cas.

C’est assez verbeux (trop pour être affiché ici), mais ça permet en contrepartie de charger moins de SVG sur les petits écrans qui ne les affichent pas.

Au-delà des préférences

Jusqu’à présent, les animations ne sont actives que si l’utilisateur n’a pas exprimé de préférence qui s’y oppose. Mais idéalement, chaque utilisateur doit pouvoir interrompre ou déclencher les animations sans devoir passer par les réglages de son système.

Un bouton pour les interrompre toutes

Puisque toutes nos animations sont implémentées en CSS, une propriété magique permet d’en définir l’état : animation-play-state.

La fonctionnalité elle-même est plutôt simple, en s’appuyant sur un bouton.

<button type="button" class="hero-button" aria-pressed="false">
	Stopper les animations
</button>

Une pincée de JavaScript

Difficile de s’en passer pour écouter le clic et mettre à jour une classe .reduced-motion sur le <body>, tout comme l’état du bouton avec aria-pressed.

const pauseAnimations = () => {
  if (window.matchMedia('(prefers-reduced-motion: no-preference)').matches) {
    const button = document.querySelector('.hero-button');
    button.addEventListener('click', () => {
      document.body.classList.toggle('reduced-motion');
      const pressed = button.getAttribute('aria-pressed') === 'true' || false;
      button.setAttribute('aria-pressed', !pressed);
    }, { passive: true });
  }
}

window.addEventListener("DOMContentLoaded", () => {
  pauseAnimations();
});

Un état personnalisé en CSS

Une propriété personnalisée permet de gouverner l’état de toutes les animations de façon cohérente.

@media (prefers-reduced-motion: reduce) {
	.hero-button { display: none; }
}

@media (prefers-reduced-motion: no-preference) {
	.boule {
		animation: balance 6s ease-in-out infinite var(--state, running);
	}
	
	.reduced-motion {
		--state: paused;
	}
}

Rien de bien méchant finalement, mais… ça prend du temps ! Et clairement, ça pourrait toujours être amélioré !

Bilan

Ce travail est vraiment un rush, avec seulement quelques jours (travaillés de surcroît) pour proposer une intégration créative qui soit d’une qualité suffisante pour ne pas subir l’ire d’un lectorat exigeant, et parfois intransigeant.

Certaines fonctionnalités sont arrivées tardivement, après le lancement du calendrier — j’avais enchaîné plusieurs nuits très courtes avant le lancement pour finir dans les temps, et ça n’a pas suffi.

Mais j’ai pu terminer en profitant des conseils des lecteurices, auteurices et camarades de discussion sur IRC — qui furent très enrichissants : merci à tous ceux qui ont participé, j’espère qu’ils se reconnaitront !

Post-Scriptum : cet article est focalisé sur le défi de l’intégration du thème annuel, mais nous avons aussi fait le choix en amont de changer de CMS. Grâce à un impressionnant travail de Joachim Robert (qui s’est également fendu d’un article rétrospectif sur la migration vers Kirby que je vous encourage à lire), c’est un succès — mais ça ajouté au défi puisque nous avons eu beaucoup d’ajustements à faire sur l’intégration commune, notamment sur l’affichage du contenu riche des articles.

Les astuces derrière « l’Invasion du HTML mutant »

Gaël Poupard — Mon, 18 Nov 2024 01:00:00 GMT

Un atelier devant par définition impliquer les participants, j’ai fait le choix de créer un mini-jeu en guise de support. C’est un site statique disponible en ligne, open-sourcé sur GitHub — pour que vous puissiez l’améliorer !

Quand je dis statique, c’est statique : le dépôt a une unique dépendance, servor, chargée de fournir un serveur HTTP basique pour travailler en local et servor n’a elle-même aucune dépendance. Le reste n’est que HTML, CSS et JavaScript.

Ça m’a permis de revenir aux fondamentaux, considérablement gagner en efficience ; mais surtout… découvrir tout un tas de trucs et astuces !

La mécanique du jeu

En démarrant le jeu, vous commencerez par personnaliser votre personnage. Le seul objectif de cette étape est de découvrir la structure visuelle d’un niveau, en vous permettant de vous impliquer personnellement dans le jeu. Les valeurs choisies seront appliquées dès que possible à tous les personnages du jeu, dans une sorte de représentation en miroir.

Après avoir choisi votre personnage, un niveau d’entraînement vous familiarise avec la mécanique très simple du jeu : une portion de code à compléter et soumettre, exécutée en direct, qui affecte la zone envahie progressivement par des mutants ! Ce code est dans la plupart des niveaux les options passées à un mutationObserver, mais parfois aussi dans la fonction de rappel.

En cas d’échec comme en cas de réussite, une fenêtre modale vous informera. Parlons-en, de cette fenêtre modale !

Les particularités de `<dialog>`

J’en parlais en 2022 à Paris Web puis au devFest Nantes dans mon sujet « Découvrez " le bon HTML " et économisez du JS et du CSS », l’élément <dialog> est extrêmement intéressant et devrait à terme supplanter toutes les implémentations de fenêtres modales dans les différentes bibliothèques de composants.

Dans l’atelier, je m’en sers en plusieurs endroits :

pour afficher les règles du jeu dans l’écran d’accueil ;
pour interrompre un niveau, quand le nombre de mutants dépasse la centaine ;
pour informer d’un échec lors d’une soumission de code qui ne fonctionne pas ;
pour informer de la réussite, dans le cas contraire — et permettre de passer au niveau suivant.

Ouvrir la fenêtre

La plupart sont ouvertes programmatiquement, en réaction à un événement. Rien de plus simple : il suffit de récupérer une référence à l’élément <dialog> à l’aide de querySelector() ou une référence à un identifiant via l’accès aux propriétés nommées, ou named properties access (en anglais), et d’invoquer la méthode showModal() (sur MDN, en anglais).

document.querySelector('dialog').showModal();

Sans JavaScript externe

Une exception toutefois, pour éviter d’ajouter un écouteur d’événement inutile : la fenêtre des règles du jeu est invoquée grâce à un gestionnaire d’événement HTML onclick :

<button type="button" onclick="rules.showModal()">Règles du jeu</button>
<dialog id="rules" role="dialog" aria-label="Règles du jeu"></dialog>

Aparté : la projection des identifiants HTML en objets globaux

Dans cet exemple, j’invoque l’ouverture de la fenêtre modale avec rules.showModal(), sans avoir défini la variable rules. Comment est-ce possible ? En résumé, tout élément porteur d’un attribut id devient mécaniquement une propriété globale de l’objet window, et devient donc accessible directement par son nom. C’est spécifié sous le joli nom de Named Access on Window Object (en anglais).

C’est drôlement pratique, non ? Figurez-vous que c’est aussi un vecteur d’attaque méconnu faisant partie d’un groupe sobrement intitulé DOM clobbering (en anglais). Je vous encourage à parcourir les recommandations de l’OWASP pour mitiger le DOM clobbering (en anglais).

Accessibilité

La méthode showModal() permet d’ouvrir une fenêtre modale, pas une simple boîte de dialogue — en respectant les exigences en matière d’accessibilité : la focus est mécaniquement piégé dedans, la fermeture est possible avec la touche Échap, etc.

L’arrière-plan

Une fois la fenêtre modale ouverte, on peut s’appliquer à la styler. Là où moult bibliothèques de composants imposent une <div> (voire plusieurs) pour servir d’arrière-plan à la fenêtre, la version native est livrée avec un pseudo-élément ::backdrop qui s’étend naturellement sur tout le viewport et est promue, avec la fenêtre modale, par-dessus le reste de la page dans ce qui est spécifié sous le nom de top layer.

Vous n’avez plus qu’à lui appliquer une couleur, une opacité ou que sais-je encore. Dans le jeu, j’ai utilisé une propriété au nom évocateur de backdrop-filter pour appliquer un effet de flou grisé sur l’arrière-plan.

dialog::backdrop {
	backdrop-filter: grayscale(50%) blur(.25rem);
}

Les dimensions

Ne maîtrisant pas le mode de consultation du jeu, j’ai utilisé un peu de CSS moderne pour la largeur de la fenêtre modale afin qu’elle ait une largeur fluide, mais avec des valeurs minimum et maximum.

dialog {
	max-inline-size: clamp(50vw, 100%, 67.5rem);
}

La propriété max-inline-size est la propriété logique correspondant à max-width dans le cas du Français. Et la fonction clamp() est un petit bijou, dont j’abuse déjà copieusement dans chaarts (en anglais) pour obtenir un pseudo-booléen en CSS en fonction d’une valeur, comme expliqué slide 27 de ma conférence « Dessine-moi un graphique (en CSS) » donnée au devFest Nantes 2023, TNT #24 et DevQuest 2024.

Fermer la fenêtre

J’ai évoqué la capacité de fermer la modale avec la touche Échap, mais l’élément <dialog> tire d’autres super-pouvoirs du fait d’être natif, et notamment son association avec un élément <form>. C’est parfaitement naturel, puisqu’une fenêtre modale permet généralement de valider ou annuler une action associée à une saisie.

C’est pourquoi la valeur dialog est ajoutée à la method de soumission d’un formulaire. Elle ne correspond pas à une méthode HTTP comme get ou post, mais bien à un contexte HTML, et permet de fermer directement la fenêtre modale parente. L’utilisation est fort simple :

<form id="fermer" method="dialog">

Et, pour revenir à du HTML à l’ancienne : saviez-vous qu’un bouton à l’autre bout du DOM peut soumettre un formulaire ? Il suffit de lui indiquer le formulaire à soumettre :

<button form="fermer">Fermer la fenêtre</button>

Et voilà : c’est un bouton de type submit qui soumettra le formulaire avec l’identifiant fermer, qui lui-même fermera la fenêtre de dialogue. C’est beau, non ? Et cet attribut date (au moins) de 2006, dans les spécifications W3C des Web Forms (en anglais) dont les premiers brouillons remontent à 2004…

Les émojis

Pour cet atelier, j’avais besoin de méchants envahisseurs, et de décors. Clairement pas le temps de faire des illustrations à la main, ni les moyens d’acheter des visuels. Une quête sur les internets m’a appris que le type de visuels que je cherchais se nomme les top down tileset, ces petits décors et personnages généralement en 8-bit avec une perspective écrasée.

À force de regarder des visuels en 8-bit, j’ai fini par faire le lien avec une vieille habitude dans mes supports de conférences : les émojis décoratifs en fin de titre. Bon sang, mais c’est bien sûr ! Des émojis !

Les émojis sont formidables. Ce sont des points Unicode, purement textuels, et extrêmement nombreux désormais avec des pelletées de nouveautés dans chaque version d’Unicode. Il y a même des variantes, composées en séquence !

Les personnages

Le meilleur exemple de séquence Unicode à mon avis sont les personnages : le neutre Personne 🧑 peut devenir un homme 👨 ou une femme 👩 en y ajoutant le point unicode du genre masculin ♂️ ou féminin ♀️, séparé par une jointure de largeur zéro (zero-width joiner, ‍).

Pour obtenir un pompier 👨‍🚒, on ajoute simplement un camion de pompier 🚒 à une personne 🧑 ! N’est-ce pas génial, franchement ? Et on peut évidemment y ajouter le genre et le teint.

La personnalisation

Ainsi le premier palier permet de personnaliser le genre et le teint du héros.

Le formulaire n’est composé que de deux groupes de bouton radio, chacun ayant une valeur correspondant au point Unicode concerné.

<fieldset>
	<legend>Genre</legend>
	<input type="radio" name="genre" id="feminin" value="♀️">
	<label for="feminin">Féminin</label>
	<input type="radio" name="genre" id="masculin" value="♂️">
	<label for="masculin">Masculin</label>
	<input type="radio" name="genre" id="neutre" value="" checked>
	<label for="neutre">Neutre</label>
</fieldset>

Lors de la soumission, les deux valeurs sélectionnées sont poussées dans le localStorage et ré-employées dès que possible dans la suite du jeu. Pour certains méchants, il suffit de concaténer le caractère du méchant avec les deux sélections : voilà comme un Mage 🧙 devient une Mage au teint sombre 🧙🏿‍♀️.

Les décors

J’ai un peu lutté avec les décors, demandant même de l’aide à mon camarade Clément Étienne. Et finalement, je suis revenu aux émojis : certains ont un caractère paysager intéressant, il suffit de les agrandir un peu…

🏔️

Les navigateurs

Les navigateurs et systèmes d’exploitation ont leur propre livrée d’émojis, avec des supports disparates et des rendus variés. Pour palier cet écueil, j’ai opté pour une solution très simple technologiquement parlant : une typographie. Et à ce jeu-là, j’avais déjà ma préférée : la Twemoji-COLR par Mozilla (sur GitHub, en anglais).

Les utilisateurs de Mozilla ne verront pas grand chose de nouveau : elle est embarquée dans Firefox sous le nom de Twemoji Mozilla, ce qui permet de tenter d’utiliser la version locale en CSS.

@font-face {
	font-display: swap;
	font-family: 'Twemoji Mozilla';
	font-style: normal;
	font-weight: 400;
	src: local('Twemoji Mozilla'), url('/assets/fonts/Twemoji.woff2') format('woff2');
}

Et le tour est joué : les utilisateurs de Firefox ne chargeront rien, et les autres téléchargeront une typographie pour afficher la même chose que Firefox. Choisissez mieux votre navigateur, la prochaine fois !

Firefox indique bien « système » pour l’origine de la typographie.

WebKit

Comme souvent quand je prépare un sujet, je me suis heurté à quelques limites des navigateurs. En l’occurrence, WebKit, le moteur de Safari et Epiphany, a des problèmes avec les variantes de teinte de la Twemoji-COLR. J’ai pu ouvrir un ticket sur leur Bugzilla (en anglais).

La coloration syntaxique sans JS

Dans la mécanique du jeu, des portions de code sont affichées (pour faire un « code à trous ») et du code est saisi des éléments <input> et <textarea>.

Et pour lire et écrire du code, la coloration syntaxique est drôlement pratique et agréable ! Mais charger un script tel que PrismJS (en anglais) ou highlight.js (en anglais) m’a toujours semblé démesuré pour la valeur ajoutée. Le bloc de code se retrouve charcuté dans le DOM, où des <span> avec des classes plus ou moins lisibles saucissonnent chaque portion de texte en fonction de son rôle syntaxique. C’est carrément indigeste.

Mais au moment où je préparais cet atelier, Heikki Lotvonen a publié un article ahurissant : Font with Built-In Syntax Highlighting (en anglais). C’est à mon sens, une petite révolution : une typographie tirant parti des fonctionnalités OpenType et notamment la table COLR. Fini les tartines de <span>, place à un code lisible et propre !

Si les détails d’implémentation OpenType vous intéressent, je vous encourage à lire l’article. De mon côté, je me suis focalisé sur la personnalisation de la palette, rendues possibles en CSS avec @font-palette-values (sur MDN, en anglais) et la propriété override-colors (sur MDN, en anglais).

Voilà ce que ça donne pour le jeu, dans lequel je profite de l’utilisation de propriétés personnalisées CSS pour la gestion des couleurs :

@font-palette-values --syntaxHighlighter {
	font-family: 'FontWithASyntaxHighlighter';
	override-colors:
		0 var(--foreground),
		4 rebeccapurple,
		5 var(--accent),
		7 var(--muted);
}

Le rendu est pas mal, non ?

Et c’est de la pure amélioration progressive : si votre navigateur ne supporte pas la table COLR, la règle @font-palette-values ou la propriété override-colors, vous aurez juste du texte brut avec la monospace par défaut.

Les Space Invaders

Le dernier point sur lequel je me suis beaucoup amusé, c’est le niveau des aliens. L’émoji alien monster 👾 ressemble beaucoup, beaucoup, beaucoup aux vaisseaux de Space Invaders. Pour un jeu d’invasion, ça tombe bien.

J’ai donc voulu assumer la référence : arrière-plan noir, animation des envahisseurs qui défilent vers le bas, et… un compteur de score.

Les compteurs

Pour ceux qui font du CSS depuis longtemps, vous avez peut-être déjà entendu parler des compteurs CSS. Notre score correspondra simplement au nombre d’aliens présents.

Cependant, si notre compteur commence à 1 et peut monter jusqu’à 100 — et sachant que le jeu original disposait d’un compteur sur cinq chiffres — le rendu ne sera ni élégant ni une belle citation. Heureusement, CSS nous permet de personnaliser le style du compteur avec @counter-style.

Pour obtenir un compteur sur cinq chiffres, affichant des 0 avant la valeur du compteur, voici la déclaration utilisée :

@counter-style invasion {
	system: numeric;
	symbols: "0" "1" "2" "3" "4" "5" "6" "7" "8" "9";
	pad: 5 "0";
	speak-as: numbers;
}

WebKit (encore)

Là aussi, WebKit est limité : les compteurs CSS ne sont pas incrémentés quand on ajoute des éléments au DOM. C’est Karl Dubost qui a ouvert ce ticket sur Bugzilla (en anglais).

Les couleurs

Un autre point saillant pour citer visuellement Space Invaders, ce sont les couleurs vives. L’émoji utilisé vient avec une couleur qu’on ne peut pas surcharger, donc on va devoir l’altérer. Cette technique n’est pas récente, mais extrêmement utile : l’accumulation de filtres CSS pour atteindre la bonne couleur.

C’est un exercice compliqué, et je remercie Barrett Sonntag pour son générateur de filtres pour convertir du noir vers un code héxadécimal (sur CodePen, en anglais). La seule contrainte est de commencer par du noir ce qui se résout facilement en appliquant en premier grayscale(100%) brightness(0%).

mu-tant[type="invaders"]:nth-child(1n + 1) {
	filter: grayscale(100%) brightness(0%) invert(15%) sepia(90%) saturate(5339%) hue-rotate(6deg) brightness(96%) contrast(127%);
}

mu-tant[type="invaders"]:nth-child(2n + 1) {
	filter: grayscale(100%) brightness(0%) invert(66%) sepia(82%) saturate(4488%) hue-rotate(88deg) brightness(117%) contrast(129%);
}

mu-tant[type="invaders"]:nth-child(3n + 1) {
	filter: grayscale(100%) brightness(0%) invert(9%) sepia(90%) saturate(7442%) hue-rotate(247deg) brightness(91%) contrast(149%);
}

mu-tant[type="invaders"]:nth-child(4n + 1) {
	filter: grayscale(100%) brightness(0%) invert(91%) sepia(27%) saturate(1428%) hue-rotate(1deg) brightness(110%) contrast(104%);
}

C’est verbeux, mais ça fonctionne !

Plutôt ressemblant, non ?

Les Web Components

Et dire que je n’ai parlé que de HTML et CSS, pour le moment… Je ne m’étendrai pas autant, mais côté JavaScript, je me suis (un peu trop) amusé avec les Web Components. En résumé :

<mu-tant> est le composant qui affiche un mutant, et gère sa mutation : un changement d’attribut, de valeur d’attribut, de contenu, de descendance, etc. Le tout à intervalle irrégulier, et de façon désordonnée.
<code-runner> étend la fonctionnalité du formulaire pour normaliser les réponses et les envoyer au <play-ground>. Pour le clin d’œil, l’événement qui permet de diffuser les réponses est intitulé voightkampff.
<play-ground> est le composant le plus critique : il déclenche l’invasion, surveille l’événement voightkampff, exécute le code soumis, et donne le verdict (en ouvrant la fenêtre modale appropriée).

Dans tout ça, j’ai énormément joué avec les mutationObserver, les intervalles et les minuteurs, les émojis, et la génération de valeurs aléatoires.

Conclusion

Si tout ce fatras vous rend curieux, je vous invite à visiter le dépôt du jeu sur GitHub et à en faire ce que vous voulez !

Et si vous vous lancez dans le jeu, je vous invite à consulter les slides adossés au jeu. En avançant, vous verrez que chaque mutant a son slide. N’avancez pas trop vite, car le slide suivant donne la réponse…

Faites chauffer votre inspecteur !

Note

Cet article fait partie du « Advent of Tech 2024 Onepoint », une série d’articles tech publiés par Onepoint sur dev.to pour patienter jusqu’à Noël.

Mon épopée au devQuest

Gaël Poupard — Tue, 18 Jun 2024 16:09:15 GMT

La première édition du devQuest avait lieu à Niort le 14 juin dernier. Et pour une première édition, c’était incroyablement réussi !

Un nouveau joueur dans la cour des CFP, ça n’est pas si courant ! J’ai postulé par curiosité à cet événement, dont la page d’annonce était très attractive… Et j’étais retenu pour ma conférence « Dessine-moi un graphique (en CSS) » ! Accompagné de deux collègues nantaises, Céline Mérand et Charline Humeau — retenues avec leur quickie « Dédramatisons l’accessibilité » — nous sommes partis à l’aventure à Niort.

Je vous raconte cette épopée ?

Le folklore du devQuest

Le devQuest se tenait au Dôme du parc des expositions de Niort, un lieu agréable et enchanteur grâce à sa disposition circulaire. Trois salles étaient occupées :

La forge, la plus grande salle.
L’astrarium, la seconde salle de conférence — dans laquelle mes collègues et moi sommes intervenus.
Et le laboratoire, qui accueillait les ateliers.

Vous l’aurez deviné avec le nom des salles : les organisateurs ont mis en place une ambiance festive et ludique très réussie !

Des énigmes à résoudre, sous forme de quiz accessibles via des QR codes disséminés sur les stands.
Un décorum léger, mais bien présent, pour donner le ton !
Une musique d’ambiance à la taverne, pour se sentir comme dans son RPG préféré.
Des étendards devQuest pour encadrer chaque scène, une coquetterie vraiment sympathique pour habiller le lieu.
Des partenaires qui ont joué le jeu avec des stands ludiques et quelques goodies qui sortent de l’ordinaire — et notamment un stand pour la boutique Sortilèges, avec quelques jeux proposés à l’essai !

J’ai également beaucoup apprécié l’ouverture de la journée, lancée par un générique digne d’un jeu vidéo et un maître du jeu pour nous présenter la guilde des organisateurs, de leurs partenaires et leur quête initiatique pour réussir cette première édition. Et les remerciements pour lancer la journée, ça met vraiment de bonne humeur !

Les récits de la tradition orale

Deux tracks de conférences et une d’ateliers : la journée était bien chargée et le choix parfois difficile !

J’ai moi-même conté une histoire, « Dessine-moi un graphique (en CSS) » que vous retrouverez chez moi. J’ai beaucoup apprécié l’aventure, et les retours sont plutôt positifs.

Retours glânés sur OpenFeedback

Level up ta conf

La keynote d’ouverture était assurée par Julien Landuré et Annabelle Koster, figures bien connues de la scène nantaise — entre autres choses pour leur implication dans le GDG de Nantes, qui organise chaque année le devFest.

Les organisateurs du devQuest ont souligné dans leur introduction le soutien qu’ils ont reçu des organisateurs du devFest Nantes, et cette conférence montrait bien la valeur inestimable de l’expérience partagée : 12 ans d’existence, d’une première édition confidentielle et artisanale à un événement gigantesque rassemblant des milliers de personnes.

Ce retour d’expérience d’une équipe d’organisateurs est vraiment enrichissant, et je le partagerai dès que possible à nos camarades organisateurs de l’Atlantique Day chez Onepoint à Nantes, mais aussi à mes copains organisateurs de Paris Web. On peut toujours s’améliorer !

Arrêtons de (dé)tester nos applications

Louis Fredice Njako Molom et Stanley Servical ont mené un atelier sur la validation de cas d’utilisation centrés utilisateurs, articulés autour de la solution UUV qu’ils éditent au sein de l’organisation GitHub Orange OpenSource.

Je n’ai pas pu assister à cet atelier — étant moi-même sur scène au même moment — mais ils ont déjà mené cet atelier au dernier Devoxx et j’ai pu découvrir la solution UUV récemment. Cet outil s’appuie sur les standards actuels du test (Cucumber, Cypress ou Playwright — au choix ! — et aXe) et permet de rédiger ses cas de tests en langage naturel.

Des dictionnaires dédiés à certains aspects (notamment l’accessibilité) et un assistant (une application Electron) permettent à n’importe quel intervenant sur un projet de rédiger un cas de test. C’est la promesse (tenue) et je trouve ça assez incroyable.

Ne jouez plus solo

Julien Libert a découvert le mob programming en conférence, et nous transmet dans une conférence son expérience après une année de pratique ! De la théorie à la pratique (avec son lot d’aménagements loin de la théorie), il nous raconte ce qui a fonctionné — ou non ! — et quelques anecdotes intéressantes sur la réalité du terrain.

Mon passage préféré : l’utilisation du mob programming en guise d’entretien technique lors des recrutements. Pas de problème à tiroir ou d’exercice en mode fizz buzz, mais un problème sélectionné en amont par la candidate elle-même — qui a donc le temps de potasser — et la solution mise en œuvre est déroulée en binôme le jour de l’entretien.

Je trouve énormément d’avantages à cette pratique !

Chrome Devtools from zero to hero

Simon Belbeoch nous conduit dans une quête annexe : dépasser le basique console.log() en jouant dans les outils de développement.

Des autres méthodes de l’objet console — que j’ai découverte en créant des CLI en Node… — aux outils de simulation de troubles visuels en passant par le debugger;, nous avons vu du paysage et des couleurs !

Le seul bémol que j’apporterai est de restreindre le sujet, dès le titre, à Chrome… alors que toutes ces fonctionnalités existent dans Firefox ou Safari.

Et je préfère Firefox !

Dédramatisons l’accessibilité

Céline et Charline ont pu rejouer leur conférence, qui brosse un portrait de l’accessibilité web bien loin des clichés habituels : moche, compliqué, cher, etc. En vingt minutes, elles réussissent un véritable tour de force : sensibiliser au handicap, illustrer avec des situations concrètes, apporter des ressources théoriques et proposer des outils concrets pour mettre le pied à l’étrier.

Et leur conférence sortait du lot : c’était la seule catégorisée UX / UI de toute la journée !

La récompense de la quête

Une première édition est toujours un pari risqué.

Les spectateurs seront-ils au rendez-vous ? Le plan initial visait 150 personnes, nous étions plus de 400 !

L’appel à sujets sera-t-il visible et fructueux ? L’équipe a reçu plus de 160 propositions, la sélection s’est avérée rude !

Les partenaires trouveront-ils un intérêt ? Avec 19 partenaires présents, le moins qu’on puisse dire est que c’est un grand oui !

Et surtout… va-t-on réussir à aller au bout de l’expédition ?

L’équipe du devQuest s’est entourée pour bénéficier d’expériences enrichissantes, et a su apporter beaucoup de personnalité à ce nouveau venu dans le circuit des conférences. Leur motivation et leurs convictions ont permis aux participants et orateurs de passer une excellente journée, distrayante, faite de rencontres et d’apprentissages.

J’en repars en ayant glâné de nouvelles connaissances, découvert quelques personnes et passé un très bon moment.

Bravo à l’équipe du devQuest, et merci à onepoint de nous permettre de partir en expédition pour des quêtes de ce genre !

HTML comme fondation

Gaël Poupard — Thu, 22 Dec 2022 17:53:57 GMT

Note : cet article est la traduction de ma contribution au calendrier de l’avent de HTMHell, Modern HTML as a foundation for progressive enhancement !

Vous êtes peut-être familier avec le concept d’amélioration progressive. En résumé, c’est une méthode permettant de s’assurer que l’utilisateur dispose d’une version viable de votre page quelque soit son contexte — connexion limitée, navigateur désuet, etc. — mais aussi de rendre ladite page plus résiliente (par exemple aux erreurs JavaScript).

L’amélioration progressive débute par la base :

le contenu,
balisé avec HTML,
stylé avec CSS,
enrichi avec JavaScript,
et amélioré pour l’accessibilité avec ARIA (en cas de besoin uniquement).

Chacune de ces étapes devrait fonctionner telle quelle et améliorer les étapes précédentes sans les abîmer. En d’autres termes, il vous faut rédiger votre HTML indépendamment du CSS ou du JavaScript que vous y appliquerez ensuite.

Cela étant dit, il paraît évident que mieux vous connaissez chaque étape de la liste, plus votre page devrait être robuste. JavaScript est omniprésent donc je présume que vous en êtes familier. ARIA devient de plus en plus visible depuis quelques années, donc on peut supposer que même sans connaître ARIA vous utilisez une bibliothèque ou un outil s’en occupant très bien. CSS s’améliore constamment et j’imagine que votre veille vous permet de découvrir des nouveautés quotidiennement ou presque…

Mais quid de HTML ? Fait-il partie de votre veille technique ? Voyez-vous fréquemment passer des nouveautés HTML dans vos flux d’information ? Pas très souvent, je présume.

Mais voilà. HTML est un standard vivant donc les spécifications changent, les navigateurs améliorent leurs supports en permanence — avec Interop 2022 par exemple — donc il y a des nouveautés, côté spécifications ou côté navigateurs ; et certains d’entre eux sont destinés à devenir des versions natives de composants JavaScript basés sur un amas de div depuis des lustres.

Et si nous pouvions améliorer la couche HTML pour ce genre de composants, rendant le balisage plus résilient au passage ?

Avertissement : il faut voir HTML comme une fondation, en aucun cas un remplacement de votre composant JavaScript existant. Si votre composant requière ARIA, ne tentez pas de l’implémenter sans. Autrement dit, tentez systématiquement de fournir la meilleure expérience utilisateur possible et ne vous préoccupez pas trop de l’expérience développeur. Vous pourriez être intéressé par la série d’articles sur les composants sous-conçus d’Adrian Roselli.

Allons faire une ballade !

`details` et `summary` comme base pour le motif de conception disclosure

Remémorez-vous ces boutons « Voir plus » qui font apparaître des contenus supplémentaires quand vous les activez. Rendre ce genre de composant accessible nécessite généralement que vous implémentiez le motif de conception ARIA disclosure, basé sur un bouton et l’attribut aria-expanded pour communiquer l’état.

<details> et summary> sont les candidats parfaits pour ça. Comme leur nom l’indique, ce motif de balisage va afficher un résumé (summary) et masquer les détails associés, mais les rendre disponibles lors de l’activation du résumé. L’implémentation par les navigateurs et le support sont excellents.

Ça semble plutôt sympa, non ? Alors pourquoi s’embarrasser avec le motif de conception disclosure et ne pas préférer utiliser <details> et <summary> systématiquement ? Pour faire simple, les interactions ne sont pas exactement celles attendues par vos utilisateurs, et le support par les navigateurs et technologies d’assistance n’est pas encore idéal — comme l’a démontré Scott O’Hara.

Mais alors… peut-on l’utiliser comme la fondation de notre motif de conception ARIA disclosure ? Découvrons ça (sur CodePen) !

Rien de magique ici : pour améliorer et harmoniser le support des technologies d’assistance, on transforme le motif HTML en disclosure en ajoutant à l’élément <summary> le rôle button et l’attribut aria-expanded pour expliciter l’état, et en s’assurant que le contenu masqué l’est pour tout le monde avec l’attribut hidden. L’attribut open sur l’élément <details> se charge de tout ça nativement, mais on ne peut pas se reposer dessus dès qu’on personnalise le marqueur triangle par défaut (ce qu’on fera à n’en pas douter) : on doit implémenter le motif de conception disclosure complet pour éviter des restitutions incohérentes entre navigateurs et technologies d’assistance.

De plus, saviez-vous que les navigateurs basés sur Chromium permettent de trouver le contenu masqué par <details> lors d’une recherche sur la page ? C’est une fonctionnalité qui va être standardisée en HTML avec la valeur until-found pour l’attribut hidden mais ça n’est pas censé être le cas des contenus masqués par le motif de conception disclosure.

Comme vous l’avez peut-être compris, utiliser <details> et <summary> enrichis avec le motif de conception ARIA disclosure ne fera aucune différence pour la plupart des utilisateurs… mais si d’aventure votre JS ou votre CSS ne fonctionne pas, votre balisage sémantique prendra le relai et restera interactif — avec toutes ses limitations actuelles dans les technologies d’assistance.

Faites d’ailleurs attention en utilisant ces éléments comme fondation : ils ne sont pas le bon choix pour des accordéons, un menu déroulant, un menu « burger », un groupe d’onglets ou une fenêtre modale… Restez sémantiques !

Et si je vous disais qu’il y a d’autres éléments HTML améliorables progressivement de la sorte ? On jette un œil ?

`output` comme une live region

Avez-vous déjà eu besoin d’alimenter une live region pour communiquer des changements aux utilisateurs de lecteurs d’écran — parfois masquée visuellement en CSS ? C’est assez fréquent de nos jours, et vous retrouverez une gestion des live regions dans la plupart des frameworks : Angular a un LiveAnnouncer dans son CDK Accessibilité, et WordPress a un script interne wp.a11y.speak()… Les live regions ARIA s’appuient sur trois rôles spécifiques : status, log et alert, chacune ayant un comportement légèrement différent.

Mais saviez-vous qu’un élément HTML est une live region native, avec un rôle implicite status ? Je vous présente <output> ! L’implémentation par les navigateurs est complète et le support est excellent. Cependant certains couples de navigateurs et technologies d’assistance précis sont défectueux, comme Scott O’Hara (à nouveau) l’a démontré.

Rendons <output> encore plus robuste en le transformant en live region ARIA (sur CodePen) !

Vous vous en souvenez peut-être, expliciter les rôles des éléments HTML était nécessaire il y a quelques années — pour les landmarks, principalement — afin d’améliorer le support des navigateurs et technologies d’assistance. C’est d’ailleurs toujours une pratique encouragée par le critère 12.6 du RGAA. Nous nous sommes habitués à écrire <main role="main">, <header role="banner">, etc.

Un autre point positif avec <output role="status"> est que ça vous permet de styler vos live regions en sélectionnant l’élément output : spécificité moins élevée, et la possibilité d’appliquer des styles de base renforcés — avec CSS containment, par exemple ?

Une live region particulière : le toast !

Il existe aussi un cas d’usage pour une live region affichée visuellement. Je n’irais pas très loin sur le sujet, car il a déjà été traité dans un grand nombre d’articles de grande qualité :

Scott O’Hara l’a mentionné dans The Output Element,
une précision technique après A toast to an accessible toast… abordant les considérations d’expérience utilisateur,
mais aussi Adrian Roselli avec Defining toast message.

Attention : si votre toast ou votre live region contient des éléments interactifs, vous devriez probablement utiliser un rôle dialog ou alertdialog au lieu d’un élément <output>. Cela dit… il y a peut-être un élément HTML plus indiqué pour ça !

Une boîte de `dialog`

Je ne vais pas creuser beaucoup l’élément <dialog>, mais explorons tout de même ce qu’il fait nativement comparé au modèle de conception ARIA dialog :

il a un rôle dialog implicite,
si on l’ouvre avec la méthode showModal() :
- il a une propriété aria-modal="true" implicite,
- il peut être fermé avec la touche Échap,
il piège le focus en son sein — mais permet d’atteindre la fenêtre du navigateur, c’est toujours discuté…
il restaure le focus à l’élément qui a déclenché l’ouverture, lors de sa fermeture,
il rend le reste du document inert automatiquement.

Mais il y a plus ! Voyez plutôt :

Le pseudo-élément ::backdrop permet de styler l’arrière-plan superposé vraiment facilement.
La pseudo-classe :modal s’applique lorsque <dialog> est ouvert avec la méthode showModal().
Si votre boîte de dialogue contient un formulaire, utiliser l’attribut method="dialog" sur le formulaire permet à votre bouton de soumission de fermer la boîte de dialogue en transmettant les données.

L’élément <dialog> seul n’est pas (encore) suffisamment cohérent entre les différents navigateurs et technologies d’assistance, comme Scott O’Hara (de nouveau) l’a remarqué, mais vous avez saisi le principe : qu’en serait-il si on l’enrichissait en appliquant le motif de conception ARIA dialog, et en s’appuyant sur le comportement natif pour économiser quelques lignes de JavaScript ?

C’est plus ou moins ce qu’Adam Argyle a exploré avec son composant dialog sur web.dev avec quelques astuces sympathiques à apprendre — gardez cependant à l’esprit que les contenus sur web.dev ne sont pas testés avec des technologies d’assistance ni contre les WCAG.

Construire un composant dialog n’est vraiment pas évident, et Kitty Giraudel a détaillé ce dont vous avez besoin pour faire un bon composant dialog. Depuis la rédaction de ces articles, le support de <dialog> s’est considérablement amélioré et fait même partie d’Interop 2022, donc attendez-vous à ce que le support s’améliore encore en ces derniers jours de 2022.

C’est probablement l’exemple le moins évident, puisqu’en parlant d’amélioration progressive l’élément <dialog> pourrait être un mauvais choix : il ne peut tout bonnement pas fonctionner sans JavaScript. Mais si votre JavaScript est en panne pour une raison inopinée, vos écouteurs d’événement pourraient toujours fonctionner.

Conclusion

HTML est incroyable. Ça n’est pas suffisant pour proposer un expérience accessible à tous les utilisateurs, comme Dave Rupert l’a mis en exergue il y a deux dans HTML: the inaccessible parts — bien que certains de ces exemples ne sont plus d’actualité, corrigés dans les navigateurs ou technologies d’assistance.

Mais ne pas être parfait est probablement toujours mieux qu’être neutre, n’est-ce pas ?

Je crois que c’est le genre de choses qu’HTML permet : <details> et <summary> finiront par être implémentés et restitués de façon cohérente aux technologies d’assistance, rendant les enrichissements avec ARIA caduques. Le travail de Scott, du test très avancé aux articles de blogs et à l’ouverture de tickets de bug, est la voie à suivre. Les implémentations complètes dans les bibliothèques comme a11y-dialog de Kitty Giraudel permettent de gagner en maturité et de clarifier les attentes pour ces composants. Et avec l’augmentation des usages, les navigateurs et technologies d’assistance vont certainement reconsidérer leurs priorisations, dans des opérations comme Interop ou ARIA-AT.

Alors utilisons, testons, et aidons les navigateurs et technologies d’assistance à supporter ces nouveaux éléments HTML !

L’état des champs

Gaël Poupard — Thu, 21 Dec 2017 15:09:15 GMT

Mais en arrivant sur la page, ledit champ est vide — et par conséquent, invalide.

Le souci

Lorsque vous appliquez des styles à un champ invalide (en utilisant la pseudo-classe :invalid), ils seront donc appliqués dès le chargement de la page si ce champ est également affublé de l’attribut required. Dommage !

C’est ce qui a conduit Stéphane Deschamps à ouvrir une issue sur le Github du W3C.

L’état indéterminé

Quelques échanges plus tard, on évoque l’existence de l’état indéterminé pour les cases à cocher, boutons radios et barres de progression dans la spécification HTML5 qui pourrait porter le statu quo sur l’invalidité de notre champ. Cet état est facile à cibler en CSS à l’aide de la pseudo-classe :indeterminate.

Le brouillon du module 4 des sélecteurs

Dans le brouillon du module de niveau 4 des sélecteurs CSS, une nouvelle pseudo-classe tente de résoudre ce problème : :user-invalid. Vous noterez par ailleurs que le paragraphe descriptif n’est pas à jour puisqu’il évoque la première dénomination de ce nouveau sélecteur, à savoir :user-error.

Mais vous l’aurez compris, il s’agit d’un brouillon et ce nouveau sélecteur est très loin d’avoir été implémenté où que ce soit.

Un contournement possible

Une idée m’est venue en lisant un article du calendrier de l’avent Digitpaint intitulé Fantastic form pseudo selectors, dans lequel le premier exemple implémente un label flottant non pas au :focus sur le champ, mais lors du début de saisie grâce à la pseudo-classe :placeholder-shown. Génie !

Cette pseudo-classe est active uniquement lorsque le placeholder est affiché, autrement dit tant qu’aucune saisie n’a été effectuée dans le champ. Et ça, ça ressemble beaucoup à une partie de l’énoncé de notre problème du jour. Nous pourrions donc faire en sorte de distinguer un champ invalide vierge d’un champ invalide ayant été saisi, avec les sélecteurs suivants :


input:invalid {
  box-shadow: none;
}

input:invalid:not(:focus) {
  box-shadow: 0 0 0 2px red;
}

input:invalid:placeholder-shown {
  box-shadow: none;
}

Et bien a priori, ça fonctionne !
Et bonne nouvelle, :placeholder-shown est décemment supporté. Je vous ai même fait un petit CodePen pour jouer.^[1]

Remarques post-publication

Note : Merci à Vincent qui me fait réfléchir, dans une discussion sur Twitter.
Note : Gaëtan me signale que sur Chrome, le placeholder ne peut pas être vide pour que cette astuce fonctionne.
Note : Johan me signale que le comportement observé de visu était également vocalisé par les lecteurs d’écran. Là, ça devient vraiment gênant !

Pourquoi pas `:not()`

Peut-être supposez-vous (à juste titre) qu’au lieu d’utiliser deux sélecteurs différents, nous pourrions styler directement les champs invalides dont le placeholder n’est pas affiché, grâce à input:invalid:not(:placeholder-shown).

Le fait est que le support de :invalid est bien meilleur que celui de :placeholder-shown ; de plus, vous n’êtes pas sans savoir que CSS est un langage tolérant à l’erreur. Quand un navigateur rencontre un sélecteur qu’il ne comprend pas, il ignore l’ensemble du bloc de déclaration concerné — et ce pour une bonne raison : être capable d’appliquer les styles suivants.

Ainsi les navigateurs ne comprenant pas :placeholder-shown (Internet Explorer et Edge au premier rang) n’appliqueraient pas nos styles dédiés aux champs invalides. Et ça, a priori, ce n’est pas ce qu’on veut ! Alors en utilisant deux sélecteurs, le seul inconvénient est que les navigateurs ne comprenant pas le second sélecteur conservent leur comportement actuel.

Et ça, c’est mieux.

Au final

Je ne pense pas que ce soit une bonne idée, je tiens à le préciser. Cette combinaison n’a pas vocation à être employée de la sorte, ce n’est qu’un détournement un peu tordu, il est vrai. Mais bon, j’aime les petits défis en CSS, ne m’en voulez pas !

Un précédent

Après de petites recherches sur les internets, j’ai trouvé plusieurs références à cette combinaison de sélecteurs antérieures à cet article, toutes remontant finalement à un article sur la validation des formulaires en CSS rédigé par Chris Coyier en 2016.^[2]

Un véritable CSS trick !

Amusez-vous à commenter le second sélecteur pour voir le comportement ordinaire. ↩︎
Pour la question du support et de la tolérance à l’erreur, Chris Coyier préfère évoquer @supports plutôt que d’accumuler les sélecteurs. Ça ne me paraît pas nécessaire dans le cas présent, mais à réfléchir ! ↩︎

Calculez

Gaël Poupard — Mon, 03 Apr 2017 15:35:56 GMT

Traditionnellement, quand on veut partager une largeur en trois portions égales, on écrit width: 33.3333%;. Alors oui, d’accord, à l’époque pré-industrielle nous n’avions pas vraiment le choix. Mais aujourd’hui ?

Les décimales arbitraires

Savez-vous ce qui pêche avec les décimales ? Plusieurs choses, en fait — à commencer par le fait que vous définissez arbitrairement à quelle décimale vous vous arrêtez…

La précision

Et bien oui, forcément : si vous faites 33.33333% × 3, vous n’obtenez pas 100 %. Il vous manque 0.00001 %. Négligeable ? Peut-être.

Les arrondis et la troncature

Mais si je vous rappelle qu’IE tronque systématiquement les valeurs à la deuxième décimale, ça peut commencer à jouer un peu. En effet sur IE 11 il vous manque donc 0.01 % sur votre largeur totale.

Et si je vous rappelle que sur la même valeur, Chrome va arrondir à la treizième décimale ? Plutôt compliqué à anticiper.

Et alors ?
OSEF !

Admettons. On ne vit qu’une fois, après tout…

C’est probablement anecdotique effectivement, puisque dans le pire des cas vous n’aurez qu’un pixel de plus ou de moins. Cependant si ce « détail » vous intrigue, il est plutôt bien détaillé dans cet article d’Alex Kilgour intitulé Browser Rounding and Fractional Pixels.

Personnellement, je me sens un peu sale en laissant traîner des valeurs arbitraires — comme je l’ai déjà évoqué quand je parlais de calcul magique.

La fonction calc

Finis les tours de passe-passe : calc() vous permet d’écrire de manière concise et précise une valeur égale à un tiers.


.⅓ {
  width: calc(100% / 3);
}

Et voilà.^[1]

Compatibilité

Et le top, c’est la compatibilité : tout est au vert depuis IE 9. Voyez plutôt le tableau sur Can I Use?. Les seules tâches qui subsistent concernent des navigateurs pour téléphones, pour lesquels on peut raisonnablement supposer qu’un affichage d’un tiers de la largeur ne sera pas utile.

Alors, demeure-t-il une raison valable d’utiliser des valeurs décimales arbitraires, selon vous ?

Au fait, si dans le bout de code le .⅓ vous choque, sachez que ça fonctionne — Kitty Giraudel a même déterré une expérience de Mathias Bynens à ce propos : https://mothereff.in/css-escapes#0%E2%85%93 — et que ça me paraît un excellent nom de classe pour exprimer un tiers. Pas vous ? ↩︎

Avec ou sans JS ?

Gaël Poupard — Fri, 03 Feb 2017 18:02:05 GMT

Vous avez déjà vécu ça, pas vrai ?

L’amélioration progressive

Quand on cherche à bien faire ces interactions qui affichent et masquent un élément à l’aide de JavaScript, une des fondations est de s’assurer que le contenu soit accessible sans JavaScript. Ça fait partie intégrante de l’amélioration progressive, que je synthétise comme suit :

le HTML est propre, lisible, cohérent, et permet d’accéder au contenu sans obstacle ;
le CSS améliore l’aspect graphique, ordonne les éléments visuellement ;
le JS enrichit le tout d’une couche de comportements inexistants en HTML et CSS.

Or dans le cas d’un composant qui affiche ou masque un élément, le fonctionnement avant l’exécution du JS est donc d’avoir cet élément affiché par défaut. Ensuite — et seulement une fois que le JS est fonctionnel — on va pouvoir le manipuler pour masquer notre élément.

C’est là où le bât blesse. Le temps que notre JS soit exécuté, nous voyons l’élément affiché (même si ça ne dure qu’une fraction de seconde).

La limite du JS

En l’occurrence, c’est son temps d’exécution — extrêmement dépendant de la machine et du navigateur de l’utilisateur.
Plusieurs pistes existent pour palier ce problème :

on peut par exemple exécuter le plus tôt possible le test d’activation du JS, qui consiste à transformer une classe no-js posée sur la balise <html>… Mais dans certains cas, ce la ne suffit pas ;
on peut également abdiquer : après tout, plus aucun référentiel n’exige d’alternative à JS ;
on peut aussi se la jouer old school en dupliquant le contenu masqué dans une balise <noscript> — mais on ne se sent pas vraiment propre, après ça.

Comme le signale Lionel dans les commentaires, conserver la modification des classes dès le <head> reste une étape incontournable pour optimiser ce mécanisme. Un exemple :


document.documentElement.classList.remove(’no-js’);
document.documentElement.classList.add(’js’);

Et en bonus, on peut réfléchir et utiliser CSS.

Les styles à la rescousse

La base du fonctionnement que je propose est l’astuce utilisée par Nicolas Hoffmann sur ses composants jQuery accessibles. Grosso modo, il effectue une transition sur max-height pour la partie animée, et sur visibility avec un délai pour masquer réellement le contenu.^[1]

J’aime beaucoup cette technique, dont le seul inconvénient — à mon avis — est d’animer max-height, ce qui nous oblige à utiliser un chiffre magique pour une hauteur maximum inatteignable.

L’état de base

Voici l’état de base de ma navigation :

[id="nav"] {
  transform: translate3d(-100%, 0, 0);
  transition:
  transform 300ms ease-in 50ms,
  visibility 0s linear 300ms;
  visibility: hidden;
  width: 18.75rem;
  will-change: transform, visibility;
}

Elle est décalée vers la gauche de la totalité de sa largeur, afin de sortir de l’écran ; et est masquée.

Notez que nous avons un délai sur nos deux transitions. Pour le moment, seul celui sur visibility est important, puisqu’il permet de faire coïncider le changement de visibilité avec la durée de la transformation.

L’ouverture grâce à JS

Là, c’est tout bête. Le JS ajoute une classe .is-opened à la navigation, je m’en sers pour accrocher mes styles :


.is-opened {
  transform: none;
  transition-delay: 0ms;
  visibility: visible;
}

Et pour ceux qui me connaissent, je désamorce une question : je n’utilise pas :not([aria-hidden]), car cet attribut est ajouté via JS. Ainsi la navigation commencerait à apparaître au chargement, puis serait masquée après l’exécution du script — exactement le comportement qu’on cherche à corriger.

Et si JS est désactivé

C’est là qu’on rigole ! Lisez plutôt, je vous explique ensuite :


@keyframes no-js {
  to {
  transform: none;
  transition-delay: 50ms, 0ms;
  visibility: visible;
  }
}

.no-js [id="nav"] {
  animation: 300ms ease-in 300ms forwards no-js;
}

Dans un premier temps, je définis la règle @keyframes pour mon animation. Son seul contenu est l’état final : pas de translation, l’élément est visible, et les délais de transition sont ajustés. En terme de support on abandonne donc IE9 et ses aïeux, ainsi qu’Opéra Mini.

Dans un second temps, j’applique cette animation sur la navigation lorsque la balise <html> porte la classe .no-js. C’est sa classe par défaut, qui n’est retirée que si JS est activé.

Pour éviter que l’animation ne se joue pendant le chargement de la page, je lui intime l’ordre de patienter 300 millisecondes et de durer 300 millisecondes — soit un délai généralement suffisant pour que JS ait magouillé les classes sur <html>.

Et ceux qui ont déjà joué avec les animations le savent, elles reviennent par défaut à l’état initial (soit dans notre cas, le menu masqué). Bien sûr, ça ne va pas : j’ai donc précisé grâce au mot-clé forwards que l’animation devait conserver son état final.

Et voilà ! On profite en sus d’une bien jolie animation qui fait entrer notre navigation dans l’écran au lieu de la fuir. Et une page animée avec JS désactivé, je trouve ça cool. 🙂

Démonstration

Si vous êtes curieux de voir ce que ça donne ou de jouer avec, j’ai monté un CodePen de démonstration dans lequel vous pourrez lire le code.

Pour jouer avec le JS désactivé, vous devrez consulter la vue complète.^[2]

Il explique tout ça très bien dans la documentation de ses divers composants. ↩︎
CodePen affiche un bien joli message si vous désactivé JavaScript. ↩︎

Les nouveautés dʼIE4

Gaël Poupard — Thu, 08 Dec 2016 17:28:58 GMT

Elle apporte son lot de nouveautés à travers les filtres Microsoft, dont le plus connu concerne l’opacité. Pour rappel, la spécification finale de CSS1 ne voit le jour que le 17 décembre 1996.^[1]

Les nouveautés graphiques

Parmi les nouveaux filtres Microsoft débarqués en 4.0, il est stupéfiant de voir à quel point ils ressemblent aux toutes dernières fonctionnalités spécifiées dans CSS et HTML :

transformation ;
filtres graphiques ;
transition ;
dégradés ;
masques ;
ombres…

Oh, et @font-face est apparu dans IE4. Oui oui, en 1997. Vous vous souvenez de la révolution que c’est devenu en 2009, et le battage médiatique autour de CSS 3 ? Ils devaient bien se marrer chez Microsoft, quand ils nous ont vus nous exciter comme des molécules en chaleur douze ans plus tard.

Et si d’aventure ça vous gêne que ce fussent des filtres propriétaires Microsoft, je remets une couche de contexte — toujours pour ceux du fond, décidément : CSS 1 n’existe officiellement que depuis quelques mois. La définition des propriétés et de leurs valeurs n’en est qu’à ses balbutiements.^[2]

Fonctionnalités hors-ligne

Pas de blague. Internet Explorer 4 est la première version à évoquer la gestion de fonctionnalités hors-ligne. Nous sommes évidemment très loin des applications web progressives actuellement tendance — les fameuses PWA, bingo buzzword — mais déjà en 1997, Microsoft en parlait :

mise en cache des pages consultées afin d’améliorer l’expérience sans connexion ;
fonctionnalité d’archivage de site, permettant « tout simplement » d’enregistrer une copie du site sur votre ordinateur — et donc de le consulter sans connexion ;
un type de site appelé active channel qui permettait de synchroniser un site en ligne avec une version enregistrée localement, hors ligne.^[3]

C’est rigolo comme les thèmes abordés dans les notes de version sont les mêmes en 1997 qu’en 2016, non ?

Transitions entre les pages

Ça, c’est vraiment l’apothéose.

Vous connaissez peut-être déjà Jake Archibald ? Je l’apprécie notamment pour son travail sur l’optimisation des SVG, mais il a produit beaucoup de choses très utiles.

En octobre 2016, il a créé un répertoire sur Github intitulé navigation-transition, dans lequel il explore la complexité d’effectuer des transitions entre les pages en respectant l’historique de navigation.

C’est chouette, il évoque des pistes en CSS lancées par Google en 2014 puis Mozilla en 2015, et sa propre exploration. Je suis sûr que ça en fait baver plus d’un !

Je vous présente les transitions interpages introduites par Microsoft dans Internet Explorer 4 en 1997. Concrètement, ce sont des filtres Microsoft utilisés dans des balises meta, comme suit :


<META http-equiv="Page-Enter" 
  CONTENT="progid:DXImageTransform.Microsoft.Blinds(
  Duration=4
  )" />
<META http-equiv="Page-Exit" 
  CONTENT="progid:DXImageTransform.Microsoft.Slide(
  Duration=2.500,
  slidestyle=’HIDE’
  )" />

C’est pas beau, ça ?

De retour du passé

Vous pensiez que le web de 1997 était révolu, et que tout ce que je viens de déterrer reste obsolète ? Je vous présente mes deux trollons.^[4]

la propriété filter fait désormais partie de la spécification CSS, seules les valeurs Microsoft ne sont donc plus standards. Personnellement, ça me fait beaucoup rigoler ;
à l’époque, il était possible d’écrire des scripts dans CSS. Oui oui, chez Microsoft on faisait du JS dans du CSS.^[5]

Alors pour paraphraser le Doc, je dirais seulement :

Nom de d’IE, Marty !

Vous êtes encore là ?

Pour les survivants qui sont parvenus jusqu’au donjon, voici vos récompenses :

la page Wikipédia d’Internet Explorer 4 (en anglais) ;
~~un site fabuleux pour découvrir IE4, en anglais — qui n’est pas sans rappeler ce fameux trombone pot de colle dans les produits Microsoft du début des années 2000 ;~~
~~un historique d’Internet Explorer 1 à 6, en anglais — comme ça, vous avez le choix dans les dates ;~~
une page implémentant les transitions interpages.^[6]

Voilà. Comme je me suis beaucoup amusé à rassembler toutes ces informations et à écrire cet article, je tiens à remercier les vieux croûtons du web qui ont éclairé ma lanterne lors de mes recherches. Ils se reconnaîtront, et si vous les cherchez vous trouverez la liste de leurs nicknames connectés au salon ##openweb sur IRC.

Merci les copains.

Le 17 décembre, c’est la Saint Gaël. Coïncidence ? Je ne crois pas. ↩︎
Pour faire un parallèle avec l’histoire nord-américaine, l’époque succédant à la déclaration d’indépendance est le far-west, la ruée vers l’or, tout ça… ↩︎
J’admets avoir du mal à comprendre cette technologie, je ne l’ai jamais connue… ↩︎
Un trollon est un bébé troll, c’est bien connu. ↩︎
Nos fameux filtres, vous croyiez que ça fonctionnait comment ? ↩︎
Un indice, il faut regarder le code source. ↩︎

Cache-cache CSS

Gaël Poupard — Thu, 13 Oct 2016 15:11:13 GMT

Et j’ai beau trouver ça idiot — masquer du texte pour certains utilisateurs et pas pour d’autres, ça me paraît incohérent avec l’accessibilité — c’est un besoin récurrent.

Il existe de nombreuses façons de faire, que je ne détaillerai pas ici. Depuis quelques années, lorsque je le peux, j’utilise celle de Thierry Koblentz pour Yahoo! qui est décrite sur le blog technique de Yahoo! sur le blog de Thierry. C’est de loin la plus complète, et la seule à ma connaissance à supporter la direction de texte de droite à gauche.

Mais elle n’est pas exempte de problème, désormais.

Mise à jour

Depuis la dernière mise à jour en 2019, d’autres changements ont été apportés. Je les ai récapitulés dans Masquage accessible de point.

Propriété dépréciée

La « magie » de cette solution repose sur la propriété clip. Elle est simple à comprendre et très efficace. Seul bémol : clip est déprécié par le module CSS masking de niveau 1.

Pas de souci. La technique basée sur clip date un peu, il est normal qu’elle tombe en désuétude. La nouvelle spécification recommande l’utilisation de clip-path pour remplacer clip. Ce qui nous laisse pantois, puisque le support de clip-path est encore tout à fait relatif. Nous devons conserver clip et ajouter clip-path en guise d’amélioration progressive.

Cependant la syntaxe est différente également. Après quelques recherches, Yvain Liechti a proposé la version la plus courte pour obtenir le résultat attendu :

clip-path: inset(50%);

Banco. Un problème résolu !

Le texte ratatiné

J. Renée Beach a signalé que la propriété width: 1px; avait des effets négatifs sur le rendu du texte et par conséquent sa vocalisation par un lecteur d’écran.

La solution proposée est à la fois logique et simple : empêcher le texte de passer à la ligne et ainsi garantir que les espaces entre les mots sont conservés.

Une seule propriété suffit :

white-space: nowrap;

Et voilà, second problème résolu.

La totale

Voilà la version finale que je propose actuellement :

.sr-only {
  border: 0 !important;
  clip: rect(1px, 1px, 1px, 1px) !important;
  -webkit-clip-path: inset(50%) !important;
    clip-path: inset(50%) !important;
  height: 1px !important;
  margin: -1px !important;
  overflow: hidden !important;
  padding: 0 !important;
  position: absolute !important;
  width: 1px !important;
  white-space: nowrap !important;
}

Avertissement

Normalement, vous ne devriez utiliser ceci que pour du texte. Autrement dit, il ne devrait jamais y avoir d’élément capable de recevoir le :focus dans un élément masqué de la sorte. Cela pourrait conduire à des comportements étonnants, puisque le navigateur cherchera à positionner le scroll à l’endroit où est placé le :focus.

Cependant, si l’élément masqué peut lui-même recevoir le :focus, il nous faut pouvoir l’afficher de nouveau. C’est généralement le cas pour les liens d’évitement. Lisez la technique G1 des WCAG pour en savoir plus.

Pour ce genre de cas, Bootstrap propose une classe supplémentaire pour remettre à zéro nos valeurs de masquage.

C’est à mon avis la meilleure façon de faire — et étant donné les changements apportés sur la classe de masquage, cette seconde classe doit être revue elle aussi. Voici ma version :


.sr-only-focusable:focus,
.sr-only-focusable:active {
  clip: auto !important;
  -webkit-clip-path: none !important;
    clip-path: none !important;
  height: auto !important;
  margin: auto !important;
  overflow: visible !important;
  width: auto !important;
  white-space: normal !important;
}

Code et traduction

Vous pouvez retrouver ces classes à plusieurs endroits :

sur CodePen ;
dans un Gist.

Qu’en dites-vous ?

Version anglaise

Kitty Giraudel m’a fait l’honneur de traduire cet article en anglais et le publier sur son blog. Merci !

Modifications

Les lecteurs d’écran sur mobile

19 octobre 2016

Ayant besoin de tests sur cette version pour vérifier qu’elle n’introduit pas de régressions, Johan Ramon m’a remonté un bug étrange sur VoiceOver. En creusant un peu avec Sylvain Pigeard, il nous est apparu que position: static posait problème lors de la prise de focus d’un lien ayant la classe .sr-only-focusable.

Nous étions contents, lorsqu’en cherchant à avertir l’équipe de Bootstrap nous sommes tombés sur un ticket ouvert récemment qui implique également TalkBack. Patrick H. Lauke, en investiguant, a décelé de nombreuses incohérences dans la gestion du focus entre les diverses technologies d’assistance sur mobile. Il a ainsi ouvert des tickets un peu partout :

Narrator, le lecteur d’écran intégré à Windows 8, Windows 10 et Windows Phone ;
TalkBack, le lecteur d’écran intégré à Android, interfacé avec Chromium ;
Firefox, qui tend à s’interfacer le mieux possible avec tous les lecteurs d’écran ;
Webkit, le moteur de rendu de Safari ;
Webkit, encore.

L’état des lieux est assez sombre : les liens d’évitement ne marchent globalement pas sur les interfaces tactiles lorsqu’on utilise un lecteur d’écran. Ô joie.

Le référencement naturel

19 octobre 2016

Steve Faulkner — du Paciello Group — a posé la question au forum de support pour webmasters de Google : les contextes supplémentaires pour utilisateurs malvoyants ont-ils un effet négatif sur le positionnement dans les résultats de recherche ?

Réponse courte : non Cependant étant donné que ce texte n’apparaît pas de prime abord il est considéré comme du contenu secondaire et a donc un très faible impact sur le positionnement, et c’est une excellente chose puisque cela dissuade d’en abuser.

Les débordements inopinés

18 janvier 2019

De multiples problèmes de débordements ont été observés, notamment sur Chrome, lorsque les éléments masqués sont contenus dans un élément avec overflow: auto;. Le problème est résolu dans Boosted en ajoutant margin: -1px;.

Mise à jour

Depuis la dernière mise à jour en 2019, d’autres changements ont été apportés. Je les ai récapitulés dans Masquage accessible de point.

Le sens de la sémantique

Gaël Poupard — Fri, 24 Jun 2016 18:06:10 GMT

Mais probablement pas pour les raisons auxquelles vous pourriez penser de prime abord, je pense. Attention, ceci nʼest quʼune réflexion et sera peut-être truffée dʼerreurs, pleine de non sens et de raccourcis.

La séparation du fond et de la forme

Ce principe est assez clair. Parfois on lʼassocie également à un autre principe, celui de la répartition des responsabilités — en anglais, separation of concern — et on aboutit généralement à celui de la responsabilité unique — single responsibility, toujours chez nos amis anglophones.

Dans mes langages dʼaffection que sont le HTML et le CSS, ça se traduit actuellement par les CSS atomiques — dont jʼai déjà parlé, et sur lesquels je vous invite à vous renseigner.

En développement web et notamment sur le front-end, la conception MV* en est le digne représentant. Sommairement, chaque couche a une responsabilité précise :

le modèle est celui des données (pures et dures) ;
la vue est lʼinterface utilisateur ;
et le reste sert à manipuler tout ça comme un marionnettiste — la plupart du temps, on parle de contrôleur.

Super, le tour du propriétaire est terminé. Vous voulez mon avis ? Cʼest nul et non applicable aux couches HTML et CSS.

Lʼimportance du HTML

Un rapide cours dʼhistoire est déjà fait dans lʼintroduction de lʼarticle. Le mauvais emploi de balises HTML à des fins de présentation a traumatisé pas mal de monde, il y a de ça 10 ou 15 ans. Les tableaux, les éléments — coucou font, big, blink, center, marquee ou spacer — et attributs dédiés en sont pour beaucoup.

Là encore, je souhaite nuancer : ce ne sont que des outils. Les ouvriers qui sʼen sont servis ont fait nʼimporte quoi avec. Cʼest ça, la véritable histoire. On sʼest donc mis en tête de récupérer un vieux principe de programmation et de lʼappliquer tant bien que mal sur HTML et CSS en disant :

HTML est le fond, CSS est la forme .^[1]

Cʼétait un moyen simple et efficace dʼéjecter du versant HTML ce qui avait trait à la présentation. Et ça, c’était bien. En effet le HTML doit être employé pour sa sémantique, le sens quʼil apporte au contenu quʼil balise. Car cʼest tout ce quʼest censé faire ce langage : décrire le contenu sur le plan sémantique.
**
Utiliser des propriétés de style dans le HTML revient à corrompre la sémantique** : le contenu ne sera plus marqué correctement et pourra donc être mal interprété. Et ça, cʼest mal.

En quoi est-ce contradictoire avec la séparation fond/forme ?

Jʼai esquissé pourquoi il fallait éviter de mettre des informations de styles dans le HTML. Cʼétait pas trop compliqué.

Cependant aujourdʼhui, cet argumentaire ressurgit pour justifier lʼutilisation de classes partout, tout le temps, dans nos CSS. On nous recommande de ne pas utiliser de sélecteurs dʼéléments ou dʼattributs — voire même dʼimbrications comme ul > li — car elles induisent un lien trop fort avec le HTML et enfreigne donc ce concept de séparation du fond et de la forme.

Précisons mon avis sur le sujet : ce principe ne vaut pas pour les CSS. Je poursuis sur ma lancée.

À quoi sert le style ?

Selon moi, il sert à hiérarchiser visuellement les éléments les uns des autres. Un « gros titre », les « petites lignes »… Ces expressions décrivent un contenu dʼaprès leur aspect visuel mais aussi et surtout, leur (relative) importance sémantique.

Pour résumer le fond de ma pensé : si un élément est important sémantiquement côté HTML, il devrait avoir une représentation visuelle qui reflète cette importance.

Pourquoi ?

Mais ma bonne dame, parce que sinon vous induirez une distinction entre diverses méthodes de lecture de votre contenu — entre les technologies qui lisent le code (les robots, les lecteurs d’écrans, les moteurs en tous genres) et celles qui regardent le style (les personnes bien voyantes, les captures dʼécran, et certains moteurs tels que les outils de test de régression visuelle). Et ça, cʼest pas terrible. Cʼest même plutôt pourri, à mon avis.

En fait jʼirais encore plus loin : si vous séparez trop votre forme de votre fond .^[2]

Lʼaspect graphique devrait renforcer la structure de lʼinformation et la hiérarchisation des contenus, pas la gommer ni la falsifier.

Encore un peu dʼhistoire

Au fait, vous souvenez-vous que CSS est ce qu’on appelle un langage descriptif ? Dʼailleurs, les plus vieux dʼentre vous se rappelleront sans doute quʼà lʼorigine CSS nʼétait pas destiné aux styles visuels mais à la description de la présentation du contenu. Et non, ce nʼest pas pareil. Cela comprenait lʼaspect graphique, mais aussi dʼautres médias oubliés, de nos jours. Voyez plutôt.

La vocalisation avec le média speech — on parlait de feuille de styles orales (en CSS1, le média se nommait dʼailleurs aural), qui comprenaient le contrôle du volume, de la vitesse, mais aussi du type de voix (masculine ou féminine, par exemple). Jetez un œil à lʼappendice à la spécification CSS2 (en anglais). Tout ceci nʼa jamais vraiment été implémenté, sauf par Opéra il y a fort longtemps.
Le braille, avec les médias braille et embossed, qui permettaient de contrôler respectivement le rendu par une plage de lecture braille et par une imprimante braille.
Les projecteurs grâce au média projection, ainsi que les écrans de télévision avec le média tv.
Les téléscripteurs (ou prompteurs), terminaux et tous les systèmes avec des capacités dʼaffichage limitées aux fontes monospaces avec le média tty.

Dès la deuxième partie des années 90, les personnes travaillant sur la spécification CSS envisageaient cette multitude de façon dʼaccéder au contenu. Et aujourdʼhui on se gausse de faire un site qui sʼaffiche sur la plupart des écrans…

Morale de lʼhistoire

Simplifions.

CSS ne devrait pas être utilisé pour altérer lʼimportance sémantique d’un contenu. Et par extension, utiliser les sélecteurs dʼéléments ou dʼattributs semble une bonne idée. Je reformule au cas où : séparer le fond de la forme est une bonne idée, mais pas séparer la forme du fond. La forme dépend du fond, là où le fond ne dépend pas de la forme.

Pour ceux qui ont tenu jusque là, je vous invite à prendre le temps de lire la page Wikipédia dédiée à CSS. Cʼest fort intéressant .^[3]

Toute ressemblance avec le slogan dʼune enseigne de sport est parfaitement fortuite. ↩︎
Notez lʼordre des termes fond/forme, forme/fond. ↩︎
Par exemple, on y apprend que le mécanisme de la cascade tant décrié de nos jours par lʼécosystème des développeurs JS est conçu pour permettre aux utilisateurs dʼappliquer leurs propres styles. Cʼest oublié, mais ça nʼen reste pas moins génial. ↩︎

Sarah Bourne

Gaël Poupard — Wed, 25 May 2016 16:28:56 GMT

Nothing is obvious to the uninformed!

Les champs images cassés

Gaël Poupard — Thu, 31 Mar 2016 12:27:00 GMT

Ire Aderinokun a brisé un mythe il y a quelques jours à propos des pseudos-éléments sur la balise img.

On récapitule, pour ceux du fond

Lʼélément img est ce quʼon appelle un élément remplacé. Je vous conseille à ce propos la lecture de « Qu’est-ce qu’un élément remplacé ? », traduction en français sur La Cascade de « What The Heck Is A Replaced Element? » écrit par Dudley Storey.

Cela signifie que la balise nʼest fonctionnelle que si le contenu qui est censé le remplacer est présent. Pour la plupart des éléments remplacés, ça a peu dʼincidence puisque cʼest le système qui sʼen charge — cʼest notamment le cas des éléments de formulaire tels que input, textarea ou select.

En revanche dʼautres éléments ont besoin quʼon leur dise par quoi ils vont être remplacés, et le système nʼintervient pas. Cʼest donc le cas des img. Ainsi, si malencontreusement la source est introuvable, lʼélément nʼest pas remplacé et peut alors supporter les pseudos-éléments. Voilà, vous savez tout.

Comble de lʼironie, ça fait bientôt deux ans que jʼapplique un test dans a11y.css pour vérifier que la source est mentionnée.^[1]

Mais alors, se pourrait-il que cette astuce fonctionne également sur ce type de champ ? Et bien oui. Je vous ai préparé un codePen de démonstration avec le champ de type image.

Ce nʼest pas une révolution — et globalement personne ne sʼen servira — mais allez savoir.

Notons tout de même que si la technique est amusante, vous ne devriez jamais avoir à vous en servir et vous assurer systématiquement que vos images sont bien là. Les alternatives sont primordiales, mais si vous nʼavez pas dʼimage à afficher, mettez du texte 🙂

Impossible de vérifier, lorsque la source est présente, quʼelle est bel et bien valide. Dommage. ↩︎

À qui parlent vos CSS ?

Gaël Poupard — Wed, 30 Mar 2016 12:07:39 GMT

Le dernier article rédigé par Adam Morse est amplement diffusé ces derniers jours, vous lʼaurez certainement déjà lu : « CSS and Scalability » — vous pouvez en lire une traduction en Français sur le blog de Marc Perrien. Il y prône une méthode de rédaction des CSS dite « atomiques », issue du formidable travail de Thierry Koblentz de Yahoo sur le projet Atomic CSS.^[1]

Les CSS atomiques ⚛

La métaphore est la même que celle utilisée par Brad Frost dans son livre (en cours de rédaction) sur le design atomique. Cependant là où Brad Frost file la métaphore jusquʼà la matière, les CSS atomiques se contentent des atomes et vous laissent vous débrouiller avec le reste.

Pour résumer, une classe atomique ne dispose que dʼune seule propriété, avec une seule valeur. Voici un exemple — tiré directement de la foire aux questions dʼAtomic CSS — qui devrait être plus clair :

.Fz(large) {
  font-size: 18px;
}

Vous démultipliez ce principe pour tous vos styles redondants, et vous obtenez des CSS atomiques. Il sʼagit dʼune optimisation massive des CSS en terme de poids, de spécificité, de portabilité. Les chiffres avancés par Thierry Koblentz sont ahurissants, et les explications données par ses présentations et la foire aux questions sont très convaincantes.

Cʼest lʼapproche également défendue par Adam Morse dans son article. Il pousse la réflexion encore plus loin en précisant que si cette conception est menée correctement, alors écrire du CSS devrait être lʼexception et non la règle.

Writing new css should be the exception, not the rule.

Je trouve ça bien. Et vous ? Cette méthode est indubitablement la meilleure à lʼheure actuelle pour qui cherche à réduire ses CSS, ainsi que leur coût de production.^[2]

Toutefois je pense que cette technique est à réserver exclusivement aux sites monstrueux, massifs, des balourds. Pour un intégrateur commun, qui travaille sur des sites plus ou moins simples, je suis persuadé que le jeu nʼen vaut pas la chandelle. À mon avis, le site dʼAtomic CSS et lʼarticle dʼAdam Morse devraient le préciser : plus le site est petit, plus cette méthode coûte cher. Et je ne parle pas que sur le plan technique.

Interrogeons la destination des CSS

À qui sʼadressent les CSS atomiques ?

Conceptuellement, cette approche déplace un certain nombre de chose. Pour commencer, elle induit quʼun intervenant ne touche plus les CSS directement.^[3]

Cependant afin que la magie opère, la plupart des sélecteurs comprenant des caractères spéciaux vont être échappés. Cʼest (très) difficile à lire pour un humain. Pourtant jʼai déjà eu lʼoccasion de lire des CSS écrits de la sorte — notamment dans debugCSS.^[4]

Je pense que ce procédé est une technique dʼobfuscation des CSS. Ces CSS ne sont pas fait pour être lus par un œil humain. Ils sont lʼexpression du système technique qui sous-tend une intégration graphique. Ils sont optimisés pour la machine.

Et lʼhumain, dans tout ça ?

Vous lʼaurez compris, cet aspect me dérange un peu. Jʼaime rédiger mes CSS en imaginant que quelquʼun les lira, que ce soit par curiosité — comme le fait Adam Morse.^[5]

Il nʼy aura pas de problème particulier à reprendre un projet intégré à lʼaide de CSS atomiques, en revanche je subodore que ça semblera bien terne et froid. Aucun parti-pris, aucune manière personnelle de travailler, probablement aucun commentaire rigolo dans les sources.^[6]

Bref, aucune identité.

Dʼoù viennent mes CSS ?

Jʼai une opinion, peut-être très mauvaise, sur lʼobjet des CSS : à mon avis, ils équivalent à une charte graphique. On y précise ce qui peut ou ne peut pas être fait, ce qui doit ou ne doit pas être fait.

Et quand je parle de ce qui peut / doit être fait, je parle du HTML. Je fais un peu mon coming-out, mais oui, mon CSS sert de garde-fous pour le HTML. À dire vrai, un autre article à été largement diffusé il y a quelque temps déjà, à contre-courant de ce système nucléaire. Vous pourrez lire sur le blog dʼEbay comment leur framework CSS les aide à renforcer lʼaccessibilité.^[7]

Et cʼest chouette, je suis content de travailler de la sorte.Je ne suis jamais seul à intervenir, ni sur le HTML ni sur le CSS, et suis pourtant le seul intégrateur de métier dans mon équipe actuelle (comme dans la précédente lors de mon arrivée). Et ce genre de sélecteur qui se rapporte à un composant graphique est nettement plus compréhensible par des profils non experts, voire même carrément attractif. Et pour cause, en ne nécessitant pas dʼajouter des dizaines de classes précises pour former un composant mais une seule sur le conteneur, les développeurs sont heureux. Ils écrivent le bon HTML — chopé sur un guide de style, par exemple — et hop, ça marche.

Nʼest-ce pas merveilleux ?

Ce qui lʼest encore plus, cʼest que si jamais le HTML ne correspond pas (disons, par exemple, quʼil manque lʼattribut alt sur une image) et bien les styles ne sʼappliquent pas. Que fait alors la personne qui se trompe, pour peu que vous lʼayez prévenue que ceci pourrait arriver ? Elle va lire vos CSS pour comprendre ce quʼil manque.

Par ailleurs je trouve beaucoup plus naturel dʼécrire les styles de cette façon : on décrit quelque chose, après tout CSS est un langage descriptif. De plus nous pouvons parler facilement de ce sur quoi nous travaillons, et pouvons même nous référer à un élément commun dans un guide de style ou une documentation quelconque.

Nos CSS ne sont pas censées gonfler lorsquʼon a défini une architecture en amont. On a une somme peu ou prou figée pour nos besoins précis. En cas de refonte graphique la structure ne bouge pas, puisquʼelle est solidaire du contenu.

Je n’ai pas une vision mécanique de mes CSS, j’en ai une vision humaine : quelquʼun dʼautre (une personne) va les lire, chercher à les comprendre, les utiliser, les modifier peut-être. Je communique avec cette personne, je documente, je commente, jʼinduis des erreurs pour obliger à lire, comprendre et respecter certaines bonnes pratiques.

Je fais erreur, et après ?

Je sais, oui. Peu importe lʼapproche sur mes propos, il existe des façons de travailler qui ne me font pas écrire mes CSS de manière démodée. On peut utiliser des outils pour vérifier que le HTML est correct.^[8]

Donc encore une fois, je sais que mes propos ne feront pas le poids comparés aux gains multiples en terme de performance, de vitesse, de maintenabilité, dʼautomatisation. Mais soyons honnêtes, le gain de poids pour un site lambda nʼest pas si énorme[10]. Certes, il reste dommageable pour un utilisateur de télécharger un octet supplémentaire, donc je suis dʼaccord : les CSS atomiques sont une idée absolument géniale, un gain véritable et très intelligent tant pour lʼutilisateur que pour le matériel.

Je trouve tout de même un intérêt bien supérieur dans mes échanges avec mes collègues ou camarades de métier. Jʼaime répondre aux questions. Jʼespère quʼun nouvel arrivant parcourant mes styles éprouvera du confort et aura envie dʼécrire de cette façon, tout comme un curieux qui lirait mes sources.

Après tout, « Code is poetry ».

Filez lire en détail le site en question, il se montre réellement instructif. ↩︎
Entre autres avantages évidemment, le sujet est bien plus complexe quʼil nʼy paraît ↩︎
Je me demande bien comment on gère une refonte graphique dans ce cas : on reprend tout à zéro, ou on repasse sur tout le HTML ? ↩︎
Cʼest une des sources dʼa11y.css, pour ceux qui suivent :p ↩︎
Pour les feignasses, dans son article militant pour les CSS atomiques Adam Morse sʼappuie sur une habitude quʼil a prise : lire les CSS de certains sites, de bout en bout, pour apprendre des choses. Jʼaime beaucoup cette idée, je lʼai fait parfois. Cependant cela lui a inspiré dʼécrire moins de CSS :/ ↩︎
Probablement très peu de commentaires tout court dʼailleurs, lʼoutil de Yahoo intitulé Atomizer générant les fichiers CSS en fonction de ce quʼil croise dans le HTML… Le CSS nʼest même jamais ouvert. ↩︎
Je suis ravi de retrouver parmi les commentaires un article dʼHeydon Pickering sur Smashing Magazine à propos des sélecteurs intelligents. Et également surpris dʼy découvrir que Daniel Eden a poussé sur les CSS de DropBox une fonctionnalité qui ressemble beaucoup à celle dʼa11y.css, via un mixin simple. Je vais lire tout ça en détail ! ↩︎
Par exemple a11y.css vérifie la présence de lʼalternative sur une image, ce qui permet de se passer dʼun sélecteur contraignant. De nombreux autres outils de bien meilleure qualité le font également. ↩︎

La dette technique

Gaël Poupard — Fri, 19 Feb 2016 14:03:53 GMT

Et ça, cʼest vraiment chouette car leurs livres sont simples, efficaces, et très justes pour un prix vraiment très abordable — pour moi, en tout cas. Ils nous avaient déjà proposés lʼexcellent « Petit Précis de Créativité » de Virginie Caplet, que je vous recommande chaudement !

Ça fait peur

Celui-ci ne démérite pas. Il est effectivement très simple à lire, ne fait pas de détours et ne tombe jamais dans les discours abscons dont sont friands les experts en tous genres. Fort dʼune expérience très riche en remboursement de dette technique — quʼil nʼhésite pas à partager à coups dʼanecdotes ou de démonstration — Bastien Jaillot nous fait cheminer à travers les différents aspects de son sujet.

Généralement méconnu, souvent mal compris, ce sujet est vraiment délicat et peut se montrer intimidant voire effrayant de prime abord. Cʼest pourtant un phénomène naturel et inévitable, et ce livre a le mérite de démystifier la dette technique en expliquant clairement ses origines, ses causes, ses effets — mais aussi les problèmes quʼelle peut engendrer, les réactions qui peuvent apparaître et les diverses manières de gérer sa dette.

Mais cʼest humain

Jʼen retiens deux choses principalement, que jʼai découvertes ou verbalisées grâce à cet ouvrage :

la dette technique est aussi un sujet humain et ne saurait être abordé sur le seul plan technique ;
malgré le terme péjoratif qui constitue son appellation, cette dette nʼest pas nécessairement négative et il faut également savoir en contracter si elle peut contribuer à ajouter de la valeur à notre travail — le tout étant de conserver lʼobjectif de la rembourser, en définissant en amont les conditions attendues pour fournir lʼeffort nécessaire à ce remboursement.

Je force le trait évidemment, mais je ne souhaite que vous inciter à filer le lire ! Ce livre est important, il devrait vous plaire et surtout vous servir.

Un fichier vide

Gaël Poupard — Fri, 12 Feb 2016 20:29:10 GMT

Et c’est bien normal. C’est ainsi que nous découvrons nos outils, les personnalisons et atteignons leurs limites (ainsi que les nôtres).

Éternels insatisfaits

Cependant aucun outil magique n’existe. Parmi les outils auxquels je pense, Bootstrap et Foundation se tirent la bourre depuis quelques années pour le titre de « Meilleur framework de l’année ». Cependant tout le monde leur trouve des défauts :

trop de dépendances ;
trop de composants ;
des choix techniques trop orientés ;
des partis-pris graphiques trop saillant ;
etc.

Un peu plus récemment sont apparues des alternatives — plus légères, agnostiques et moins élaborées graphiquement. On peut citer Röcssti de Nicolas Hoffmann ou Knacss de Raphaël Goetter.

Elles corrigent certains défauts des usines à gaz précédemment citées, mais ne sont pas pour autant exemptes de travers : elles reflètent les choix de leurs auteurs, et généralement nous n’aurions pas fait les mêmes.

What if?

Que se passerait-il si on détaillait vraiment les avantages de ces solutions ? Nous font-ils gagner autant de temps que nous l’imaginons ? Quid de la charge de travail qu’impliquent l’appropriation et la personnalisation des ces outils ?

Vous le savez peut-être déjà et l’aurez deviné sinon, je ne suis pas un grand fan des ces choses pré-mâchées. Ces outils permettent de démarrer rapidement un projet et de montrer des pages presque instantanément — mais ils font également perdre un temps fou dès qu’il s’agit de personnaliser le design, de rajouter des composants, ou d’optimiser les performances.

Les solutions de Nicolas et Raphaël sont un brin plus intéressantes puisqu’elles sont personnelles : vous y trouverez un condensé de leurs années d’expérience, des cas tordus qu’ils ont pu rencontrer. Cependant leur façon de nommer les choses, d’écrire leur code, et la limite qu’ils fixent entre une base propre et une ébauche de design leur est personnelle également. Peu de chances que vous vous y retrouviez totalement.

Mes deux centimes

Fut un temps ou j’ai fourché.^[1]

Désormais lorsque je travaille sur des projets personnels, j’ai adopté mon propre framework prêt à l’emploi, simple d’utilisation, sans opinion ou choix technique contraignant, agnostique, sans parti-pris graphique…

Un fichier vide.^[2]

De l’anglicisme « forké » que je n’aime guère. ↩︎
Saint-Exupéry disait que « le désert est la seule chose qui ne puisse être détruite que par la construction ». J’y vois un lien :) ↩︎

Marie Guillaumet

Gaël Poupard — Fri, 12 Feb 2016 20:28:52 GMT

Bien faire et laisser braire

NantesCSS

Gaël Poupard — Wed, 20 Jan 2016 14:59:51 GMT

tl;dr : si vous êtes intéressés mais que ma prose vous importune, filez directement sur le Doodle proposant quelques dates, aux horaires du déjeuner.

Une communauté de praticiens

En arrivant chez Kosmos mi 2014, jʼétais le troisième intégrateur en poste — après une décennie passée avec un seul intégrateur. Parmi les sujets de conversation émergeants, celui dʼune communauté de pratique mʼa particulièrement intéressé. Jʼai donc creusé le sujet et, sans parvenir à une application concrète au sein de Kosmos, en ai conservé lʼineffable envie de regrouper des intégrateurs pour causer de HTML et CSS — et plus si affinités.

De plus, déjeuner régulièrement avec quelques camarades éclairés comme Emmanuel Clément, Vincent Valentin, Gaëtan Ark, Jean-Christophe Brebion ou Marie Guillaumet mʼa beaucoup motivé et appris. Jʼai envie de partager ça !

Ça me trotte dans la tête depuis un moment, au point dʼavoir un brouillon ici-même et quelques pages noircies dans mon carnet ; mais cʼétait mon sujet no2 derrière a11y.css.

Mais cʼest important, CSS ?

Oui, parfois je trolle. Évidemment, cʼest important ! Le temps passe vite, sur le web. Aujourdʼhui, tout nʼest que JavaScript sur le web : les nouveaux frameworks, les nouvelles spécifications, les nouvelles rustines pour se servir des nouvelles spécifications dans les nouveaux frameworks…

Et même les styles commencent à être gérés via JavaScript. Elle est bien loin, lʼépoque ou la séparation des responsabilités était primordiale (le fond, la forme, tout ça…).

Alors pourquoi voguer à contre-courant et parler de CSS ? Tout simplement parce que peu importe la technologie ou le langage que vous utilisez — et peu importe que vous soyez un gourou, un hipster, un ninja ou un vieux croûton du web — vous ne servez que des interfaces en HTML et CSS saupoudrés de JavaScript.

Pour enfoncer une porte ouverte, sachez que sans HTML ni CSS votre JavaScript est à peu près aussi utile quʼun parpaing à un morpion. Alors autant parler de langages utiles, non ?

Quand soudain, les grands esprits

Comme on dit sur les internets, « un lien vaut mille paragraphes ». Alors voilà :

@WeAreSparkk @shinze Bon ça serait pas mal de faire des meetup CSS-Nantes un jour non ?

— Loïc Goyet (@loicgoyet) January 19, 2016

Je ne connais pas encore Loïc Goyet ni lʼéquipe de Sparkk, mais vais me faire une joie de les rencontrer et les découvrir. Pour la petite histoire, Gʼest Gaëtan Ark — avec lequel jʼavais probablement déjà évoqué lʼidée — qui mʼa drafté dans la discussion, et en quelques minutes tout sʼest enchaîné :

@htmlvv @ffoodd_fr @loicgoyet @shinze @WeAreSparkk @emmanuelc @jcbrbn Interessé aussi 🙂

— Eric R (@NumEricR) January 19, 2016

Nous voilà au moins 8 à bord ! Et avec un joli compte Twitter créé par Loïc.

Quelques idées

Le type de rencontre

Le traditionnel after work hébergé quelque part avec pizzas et bière peut être évoqué, tout comme les dîners avec un bon Chardonnay. Personnellement, jʼai une préférence pour les déjeuners, qui ont lʼavantage de na pas déformer votre journée quand vous avez des enfants, des chats ou tout autre animal dépendant de vous à la maison. Et cʼest compatible avec les pizzas et la bière, tout comme (bientôt) avec les barbecues et les pique-niques.

Un contenu minimal

Lʼobjectif est surtout de se rencontrer et dʼéchanger, à mon avis formaliser des interventions nʼest pas indispensable. Nous pourrions en programmer :

une à chaque rencontre ;
sur un format court de préférence ;
sur un retour dʼexpérience, que ce soit le cas pratiquer dʼun projet ou la recherche sur un thème spécifique.

Quʼen dites-vous ? Mon rêve serait de réussir à définir un sujet au début de la rencontre, à force de discussion — et que quelquʼun tente une impro. Ça mʼéclaterait vraiment, mais pas sûr que ça plaise à tout le monde !

Un objectif pédagogique ?

Et comme jʼaime apprendre — mais aussi expliquer — je souhaiterai y saupoudrer un peu de pédagogie. La plupart des débutants en intégration que jʼai croisé ont des connaissances plutôt limitées sur de nombreuses choses, et une compréhension généralement étriquée du fonctionnement des CSS. Autrement dit, il me semble important de traiter autant des bases que des nouveautés — si ce nʼest plus.

De plus quelques cours dʼHistoire pourraient sʼavérer bénéfiques. Je pense à la découverte de CSS 1 (ce qui en reste, ce qui a disparu), aux nouveautés débarquées dans IE 4, au début du référencement (on parlait uniquement dʼannuaire, et les résultats étaient par ordre alphabétique), au DHTML, etc. Il me semble important de connaître le parcours jusquʼà maintenant pour mieux saisir la situation actuelle.

Produire du matériel ?

Et par matériel jʼentends matériel pédagogique. Des projets comme TrainDrop existent et je pense que nous pourrions y participer. Lʼobjectif est dʼéchanger, dʼapprendre, de faire des rencontres — alors pourquoi se limiter au moment présent ?

Des propositions de sujets

Parmi les sujets que nous pourrions aborder, Vincent nous suggère par exemple :

un cours sur flexbox ;
un comparatif des techniques pour faire des colonnes ;
présenter vos derniers projets (perso ou pro).

De mon côté, la première idée dont je ne parviens pas à me détacher est de parler de CSS 1. Je sais, je suis lourd !

Vous venez ?

Alors voilà, il ne reste quʼà faire le premier pas. Et comme je suis un peu foufou, je vous propose des dates la semaine prochaine, aux horaires dʼune pause déjeuner classique. Vous pouvez évidemment mʼindiquer ici-même où sur Twitter si vous avez dʼautres plages horaires de prédilection, ou si la semaine prochaine est un peu tôt pour vous.

PS : pour le nom, jʼavais pensé à la Communauté des Spécialistes des Styles. Je sais, je ne suis pas réputé pour mon humour 😶

Réserve d’espace pour le contenu

Gaël Poupard — Thu, 03 Dec 2015 13:30:49 GMT

C’est ce quʼutilisent notamment Facebook et Medium, dont le contenu respecte un gabarit constant. En terme dʼinterface, ça me semble vraiment plus agréable que le classique ouroboros.

Et figurez-vous que pour le moment, tous les retours sont extrêmement positifs. En session de test utilisateurs, la plupart des testeurs lʼont remarqué et ont tenu à le signaler comme un élément « très agréable ». Moi qui pensait mʼamuser à suivre un effet de mode à la mords-moi-le-nœud et être passé du côté obscur de la Force, me voilà confondu. Cet effet semble conférer une réelle valeur ajoutée à lʼexpérience utilisateur, alors jʼaie envie de vous montrer ce quʼil y a sous le capot afin de partager et dʼaméliorer encore tout ça.

Quelques recherches pour démarrer

Bon, bizarrement, je nʼai pas trouvé beaucoup de ressources pour faire ce truc. La plus visible est une expérimentation sur codePen qui est franchement sale. Une soupe de div, chacune positionnée en absolu et calée au pixel près. En revanche lʼarticle de lʼapprenti magicien est relativement intéressant : « Facebook content placeholder deconstruction ». Très relativement, hein. Ça manque cruellement de référence donc si vous avez, elles mʼintéressent !

En revanche il lie un autre article un peu plus intéressant qui aborde le sujet de lʼexpérience utilisateur : « Making Wait Times Feel Shorter » de Dmitry Fadeyev. Jʼen retiens surtout la dernière phrase :

This isn’t just simple courtesy, watching the progress bar move makes time fly faster.

Je traduis sommairement : ce nʼest pas une simple question de courtoisie, regarder lʼindicateur de progression fait passer le temps plus vite. Ma foi, ça a du sens. Dans cet article, lʼauteur préconise également de spécifier le délai dʼattente quand cʼest possible afin que lʼutilisateur sache à quoi sʼattendre. Et bien cet effet de faux contenu en attendant le contenu réel donne une indication plus précise du format de données que lʼon attend et nous permet dʼanticiper la lecture du contenu et de nous projeter dans son parcours.

Faire plus simple

Utiliser un élément graphique

Tout ça est bien joli, mais niveau code cʼest quand même assez moyen (à mon goût en tout cas). Par exemple nous parlons ici dʼun effet purement graphique — voire esthétique — alors pourquoi utiliser des éléments HTML pour le fabriquer ? Un élément graphique semble plus adapté, et ô comble de joie il est possible dʼutiliser des images en HTML depuis 1994.

Prévoir une alternative

Cʼest un visuel porteur dʼinformations, et à ce titre il doit disposer dʼune alternative textuelle pertinente. Je vous laisse (re)lire le critère associé du RGAA qui, comme pour témoigner de son importance, porte le doux nom de critère 1.1. Ce point nʼest a priori pas très complexe à mettre en œuvre.

Faire passer le temps

Il ne faudrait pas omettre que lʼobjectif est avant tout de faire patienter lʼutilisateur de la manière la plus agréable possible. Pour cela nous évitons le (très frustrant) petit disque qui tourne en rond, cʼest déjà bien. Mais si lʼexpérience peut sʼavérer agréable, ce serait encore mieux ! À cette unique fin, je vais suivre les exemples de Facebook et Medium qui ont mis en place un effet de balayage lumineux afin de cadencer le temps dʼattente.

Super ! Ça donne quoi ?

Créer lʼimage dʼattente

Pour démarrer, on va choisir un contenu quʼon pourrait attendre. Jʼen ai choisi un assez connu et avec un gabarit familier et reconnaissable : la carte de profil sur Twitter.

La carte de profil indique le nom, le pseudonyme et l’avatar Twitter, mais aussi les nombres de tweets, d’abonnements et d’abonnés.

Cʼest donc la-dessus que va se baser la création du visuel dʼattente. Sur le principe, je me contente de créer un bloc en aplat gris par élément, afin de représenter sa masse visuelle.^[1]

Gabarit de carte de profil twitter représenté en masses colorées

Bon, jʼadmets également avoir exporté un SVG plutôt quʼune bête image bitmap. Pour tout vous dire ça nʼest pas nécessairement le meilleur choix, étant donné que pour une image aussi simple le SVG est plus lourd quʼun PNG bien optimisé et quʼon perd nécessairement en support navigateur.

Implémenter une alternative accessible

Pour celui-ci aucun mérite, puisque lʼaccessibilité des SVG commence à être bien documentée. Je vous laisse farfouiller un peu les artères du web pour trouver votre bonheur — personnellement jʼai abouti à ceci :


<svg viewBox="0 0 320 215" width="320" height="215"
   aria-labelledby="title desc" role="img"
   xmlns="https://www.w3.org/2000/svg"> 
  <title id="title">Chargement en cours…</title>
  <desc id="desc">La carte de profil est en chemin !</desc>
  <path role="presentation" d="…" />
</svg>

Je vous passe les détails sordides des multiples <path> dans le SVG, vous pourrez jouer avec dans la démo — et accessoirement, cʼest une partie que vous devrez personnaliser, donc… Mais normalement ce magnifique assortiment de <title> et <desc> liés au SVG via aria-labelledby fait lʼaffaire et rend le tout intelligible.

Implémenter une animation

On est dans du SVG

À lʼaube du premier jour, jeune et fougueux que jʼétais, je me suis dit « Yay, dans du SVG, je vais enfin pouvoir jouer avec SMIL ». Que nenni !

Deux (plutôt) bonnes raisons de sʼen dispenser :

Le support est très moyen, notamment absent des navigateurs Microsoft ;
Chrome et Opéra lancent (depuis deux ou trois versions) une alerte dans la console lorsquʼon utilise SMIL, quʼils considèrent déprécié et dont ils vont abandonner le support un beau matin.

Ça nʼest guère glorieux, même si un charmant tutoriel en anglais me montrait quʼon pouvait facilement animer un dégradé en remplissage dʼun SVG. Dommage.

Mais on fait du CSS

Cʼest donc finalement vers les animations CSS que je dois me tourner. Cʼest moins rigolo puisque je connais déjà, mais au moins le support est excellent.

En revanche impossible dʼanimer via CSS le remplissage dʼun SVG. Le SVG sera donc rempli en aplat, et il va falloir se débrouiller autrement pour lʼeffet de balayage. Voilà comment jʼai réssolu la chose :

un dégradé linéaire allant du transparent au transparent — afin de profiter du merveilleux SVG derrière — en passant par une étape de blanc pour apporter la lumière en ce bas-monde ;
une dimension dʼarrière-plan pour ajuster la mise en scène du dégradé ;
et finalement, une animation dont la seule préoccupation est de déplacer lʼarrière-plan.

Cʼest donc un poil plus complexe que de simplement remplir le SVG avec un dégradé qui sʼanime tout seul, mais bon ! En revanche il ne vous aura probablement pas échappé quʼil nous faut cette animation devant le SVG. Et pour cela un pseudo-élément serait fort agréable. Malheureusement SVG est un élément remplacé, ce qui empêche de lui appliquer un pseudo-élément. Pour pouvoir implémenter lʼanimation, il nous faut donc un élément conteneur qui portera le pseudo-élément (ce même conteneur qui pourrait fort bien vous servir dans un contexte adaptatif ou simplement pour la mise en page).

La démonstration

En supposant que vous utilisez une division comme conteneur, voici les styles du pseudo-élément :


div::after {
  animation: placeholder 2s linear infinite;
  background-image: 
  linear-gradient( 
  110deg, 
  rgba( 255, 255, 255, 0) 10%, 
  rgba( 255, 255, 255, .33) 30%, 
  rgba( 255, 255, 255, 0) 60% 
  );
  background-size: 20em 13.4375em;
  bottom: 0;
  content: "";
  left: 0;
  position: absolute;
  right: 0;
  top: 0;
  z-index: 2;
}

Un détail peut vous surprendre : je nʼutilise pas le mot-clé transparent mais la notation rgba( 255, 255, 255, 0 ). Peut-être le savez-vous déjà mais le mot-clé qui semble définir la transparence est en réalité une notation raccourcie de rgba( 0, 0, 0, 0 ), comme le précise la spécification du module « Couleurs » de CSS3. Ça nʼa lʼair de rien comme ça, mais ça a son importance si vous appliquez un dégradé — disons du blanc au transparent, par exemple — et que vous regardez le résultat sur Safari : il interpole le dégradé en tendant vers le noir (ce qui est relativement logique) et vous donne donc un intermédiaire immonde entre votre blanc nacré et votre transparence parfaite. Un gros pâté noir, quoi. Bref, cʼest moche. Utiliser le blanc avec une opacité nulle résout facilement ce travers.

Ensuite pour animer le dégradé, cʼest plutôt simple puisque vous avez déjà vu lʼappel à lʼanimation placeholder, pour une durée de deux secondes et en boucle. Elle se contente de déplacer le fond dʼune distance équivalente à la largeur du bloc, afin de générer une véritable boucle visuelle.


@keyframes placeholder {  
  from { 
  background-position: -10em 0; 
  } to { 
  background-position: 10em 0; 
  }
}

Et voilà !

Si vous souhaitez jouer avec ou le reprendre, vous trouverez le tout sur Dabblet. Rien de bien complexe, mais cʼest tellement simple et efficace quʼil serait dommage de sʼen priver 😇

Cʼest le même principe que le gris typographique en composition de page. ↩︎

Un test Modernizr pour les contrastes élevés

Gaël Poupard — Wed, 25 Nov 2015 16:06:44 GMT

Malheureusement, il ne répond pas correctement lorsque lʼutilisateur a personnalisé les couleurs des liens ou utilise un thème navigateur aux contrastes élevés — ce que jʼai testé avec Firefox. En sus, et bien quʼil soit conçu de façon à renvoyer un booléen, il se couple difficilement avec un outil spécialisé tel que Modernizr.

Les changements

On va faire simple, puisque vous avez lʼexemple de Karl Groves en amont ! Les seules modifications apportées sont :

un peu de nettoyage, principalement des variables inutiles ;
lʼélément créé est un lien au lieu dʼune division ;
la condition finale pour renvoyer le booléen a été allégée.

Le code

Pas de miracle, lʼajout de test dans Modernizr est bien documenté. Voici ce que jʼai réalisé — qui est probablement améliorable.^[1]


Modernizr.addTest("highcontrast", function() {
  var objA = document.createElement("a"),
  strColor;
  objA.style.color = "rgb(31, 41, 59)";
  document.documentElement.appendChild(objA);
  strColor = document.defaultView ? document.defaultView.getComputedStyle(objA, null).color : objA.currentStyle.color;
  strColor = strColor.replace(/ /g, "");
  document.documentElement.removeChild(objA);
  return strColor !== "rgb(31,41,59)";
});

Rien de bien méchant 😊 Jʼai créé un CodePen dédié uniquement à ce test avec quelques commentaires et une illustration basique en HTML.

La couverture

Pour commencer, cette version est un test Modernizr. Nul besoin de télécharger tout la bibliothèque de tests cependant, sa seule et unique dépendance est la méthode addTest(), dont lʼoutil de construction personnalisée de Modernizr indique quʼelle pèse 2,53 kB (et 1,08 kB une fois compressé avec gzip).

Ensuite et pour le cas ou vous ne liriez pas couramment le JavaScript, le test procède ainsi :

il crée un lien ;
il attache ce dernier au document
il lʼaffuble dʼune couleur via CSS ;
il récupère la valeur calculée pour la couleur du lien ;
il supprime le lien créé au début ;
et il renvoie finalement une affirmation quʼon peut formuler ainsi : « la couleur calculée est-elle égale à la couleur définie par le test ? ».

Le résultat est donc soit vrai, soit faux (cʼest le principe du booléen). Donc pour résumer, ce test vérifie que la couleur calculée par le navigateur correspond à la couleur quʼon lui demande : si ce nʼest pas le cas, lʼutilisateur interfère avec les styles envoyés dʼune manière ou dʼune autre. Les cas les plus courants sont le mode de contrastes élevés du système dʼexploitation, et les styles utilisateurs fournis par le navigateur sur demande de lʼutilisateur.

Ce test répond correctement dans deux cas précis identifiés :

le mode de contrastes élevés de Windows, testé avec Edge et Firefox ;
les paramètres de personnalisation de thème et couleurs dans Firefox, sur tous les systèmes.

Il serait génial de tester plus avant dʼautres configurations, afin de préciser la couverture et de repérer dʼéventuels faux positifs ou négatifs. Jʼai créé un Gist dʼaprès le CodePen précédemment lié — nʼhésitez pas à le forker, le commenter, le triturer comme bon vous semble !

Ceci est une invitation, toutes les aimables personnes qui apporteront leur aide auront droit à ma gratitude éternelle et plein de trucs dans ce goût-là. ↩︎

Le soulignement factice

Gaël Poupard — Fri, 20 Nov 2015 16:16:37 GMT

Je vous enjoins à lire la « Signalétique des hyperliens » sur le train de 13 h 37, par Romy Duhem-Verdière. On y apprend notamment que — typographiquement parlant — le souligné nʼest dʼaucune utilité, sauf éventuellement à palier lʼabsence dʼitalique (ce qui est somme toute assez rare). En revanche sur le web, cʼest le meilleur moyen de signaler un lien.

Graphiquement grossier

Le souligné ordinaire est effectivement grossier : cʼest un reliquat des toutes premières typographies affichées sur un écran — que je nʼai pas eu la chance de croiser. Vous pouvez le constater avec cet exemple de souligné ordinaire.^[1]

Sur le plan visuel, le souligné croise les jambages inférieures, ce qui crée un attroupement inopportun de pixels quʼon pourrait qualifier de « petits pâtés ».^[2]

Quelques tentatives existaient déjà il y a fort longtemps, comme en témoigne lʼarticle de Susan Robertson sur A List Apart qui utilisait background-image pour mettre un une image répétée en guise de soulignement. Ça peut sembler étrange — notamment quand vous aurez vu les exemples animés — mais en 2004, cʼétait parfaitement fabuleux.

Le truchement CSS

On ne peut malheureusement pas encore intervenir sur la propriété text-decoration: underline; de façon satisfaisante. Ce sera en revanche le cas un jour avec text-decoration-skip: ink; qui est à lʼétat de brouillon au W3C (en anglais). Il nʼexiste actuellement aucun support de cette propriété, cependant celle-ci est émulée sur les engins Apple omme le mentionne Chris Coyier sur CSS-Tricks (en anglais). En attendant, vous allez voir que Susan Robertson était déjà sur la bonne piste il y a 10 ans.

Lʼastuce — a priori trouvée par Marcin Wichary pour Medium et expliquée dans « Crafting link underlines on Medium » — consiste à supprimer le text-decoration et le trucher à lʼaide dʼun dégradé pour la ligne, et dʼune ombre portée sur le texte pour « nettoyer les jambages ». Comme Susan Robertson, nous allons nous servir de la propriété background-image, mais au lieu de charger un gif nous utiliserons la fonction linear-gradient();. Si vous nʼêtes pas encore familier avec les dégradés, prenez le temps de lire la page dédiée aux dégradés en CSS sur MDN.

Du code, du code !

Jʼai croisé plusieurs implémentations de cette solution, toutes très intéressantes mais aucune ne fonctionnant « telle quelle ». En voici deux notables :

la méthode utilisée par tufte-CSS (sur Github) ;
la réflexion menée par Adam Schwartz pour Eager (en anglais) avec une illustration interactive particulièrement réussie.

Ça donne suffisamment de matière pour avancer, donc jʼai trituré tout ça jusquʼà obtenir un résultat satisfaisant mes besoins. Vous en trouverez un aperçu rigolo sur CodePen. Pour les feignasses, voici le CSS incriminé :


.underline {
  text-decoration: underline;
}

.no-highcontrast.cssgradients .underline {
  background: white 0 88% / 100% 0.1rem no-repeat content-box content-box;
  background-image: 
  linear-gradient(
  rgba(255, 255, 255, .67), 
  rgba(255, 255, 255, .67)
  ), 
  linear-gradient(
  currentColor, 
  currentColor
  );
  display: inline;
  text-decoration: none;
  text-shadow: 
  .05rem 0 0 white, 
 -.05rem 0 0 white, 
  .1rem 0 0 white, 
 -.1rem 0 0 white, 
  .2rem 0 0 white, 
 -.2rem 0 0 white;
  width: auto;
}

/* Pour la sélection */
/* https://developer.mozilla.org/en-US/docs/Web/CSS/::selection */
.no-highcontrast.cssgradients .underline::-moz-selection {
  background-color: black;
  color: white;
  text-shadow: none;
}

.no-highcontrast.cssgradients .underline::selection {
  background-color: black;
  color: white;
  text-shadow: none;
}

@media screen and (-ms-high-contrast: active) {
  .underline {
  background: none !important;
  text-decoration: underline !important;
  }
}

Vous noterez les occurrences multiples de la couleur blanche — tant sous la forme du mot-clé white que de sa notation rgba(). Simplement parce que mon exemple à un arrière-plan blanc. Évidemment si votre texte repose sur un fond coloré, ces valeurs doivent respecter la couleur dʼarrière-plan.^[3]

Petite astuce à prendre en considération, le second paramètre du mixin concerne la position du soulignement par rapport à la hauteur de lʼélément. Je ne suis pas parvenu à rendre ça dispensable, le changement de corps et de caractères entraînant une trop grande variation sur la hauteur de ligne. Dans mes différents cas, la position varie entre 88% et 96%.

Cʼest pas un peu verbeux ?

Si. Pour plusieurs raisons que je tente de vous expliquer :

les propriétés dʼarrière-plan sont très riches, avec dans la notation raccourcie :
- background-color
- background-position
- background-size
- background-repeat
- background-origin
- background-clip.
deux dégradés, dont le premier (couleur dʼarrière-plan en semi-transparent) sert à alléger visuellement le second — qui utilise currentColor pour conserver la couleur du texte sur lequel il est appliqué ;
lʼombre sur le texte, dont le seul et unique objectif est dʼéviter la collision entre les jambages inférieurs et le soulignement ;
et deux propriétés auxquelles vous ne vous attendiez peut-être pas : display: inline; et width: auto; dont lʼintérêt est de sʼassurer que notre charmant souligné suive bien le texte et uniquement le texte.^[4]

les classes de tests du support des dégradés CSS et de lʼactivation du mode de contrastes élevés.

Ça fait beaucoup de code, mais tout est indispensable.

Et lʼaccessibilité ?

Pour commencer, il est nécessaire de mettre en place deux scripts fonctionnant sur le même principe :

un test de fonctionnalité tel que Modernizr — dont vous pouvez générer une version uniquement pour les dégradés CSS — afin dʼappliquer ce CSS de soulignement uniquement si le navigateur supporte les dégradés ;
un second test pour détecter lʼactivation du mode de contrastes élevés — qui supprime les arrières-plans et laisserait donc nos éléments soulignés complètement nus et sans soulignement — mais qui détecte également si lʼutilisateur a personnalisé la couleur des liens : vous trouverez la source sur un JSFiddle de Karl Groves du Paciello Group (quʼil a lui-même récupéré de Hans Hillen) que jʼai modifié afin de tester un lien plutôt quʼune division.

Les navigateurs ne supportant pas les dégradés ou étant utilisé conjointement au mode de contrastes élevés resteront avec leur bon vieux text-decoration: underline;.

Un autre cas pointu est à signaler : la sélection du texte en question. Il est impossible à ma connaissance de simplement supprimer les styles ajoutés (unset sert a priori à ça, mais son fonctionnement et son support ne sont pas convaincants). Il faut donc personnaliser la sélection, ce que je fais en inversant couleur dʼarrière-plan et couleur de texte et en supprimant lʼombre sous le texte à lʼaide du pseudo-élément dédié (en anglais).

Merci à Johan Ramon pour mʼavoir rappelé à lʼordre avec ces détails croustillants !

Modifications

27 octobre 2016

Une petite amélioration est apportée, de la manière suivante :

si le navigateur gère les requêtes de fonctionnalités via @supports et qu’il supporte text-decoration-skip: ink;, on applique cette propriété ;
si le navigateur gère les requêtes de fonctionnalité mais pas la propriété, on applique le background-image lorsque le mode de contrastes élevés n’est pas activé.

Si ces ajouts vous intéressent, voici un peu de lecture supplémentaire :

Tout peut se résumer comme suit :


@supports (text-decoration-skip: ink) {
  text-decoration-skip: ink;
}

Le CodePen est à jour pour que vous jetiez un œil, et je l’ai exporté dans un Gist également.

Cet ajout a quelques effets notables :

certains navigateurs sont désormais exclus par le manque de support de @supports, tels que le Stock browser Adnroid, Blackberry Browser ou IE Mobile. Ça me semble une bonne chose puisque ces styles sont relativement coûteux, ces vieux navigateurs mobiles seront épargnés ;
seul Safari 9 supporte text-decoration-skip: ink;, et je ne suis pas certain que le rendu soit le même. Ce serait à tester et ajuster au cas par cas.

Mais nous voilà avec un pied dans le futur !

20 janvier 2017

Xavier Zalawa rencontre un bug de Blink gênant impliquant currentColor dans un linear-gradient en cas de changement d’état. C’est le cas dans ce soulignement factice : currentColor utilisé dans le background n’est pas mis à jour lors du survol ou de la prise de focus, sans être répété— ce qui ruine littéralement l’intérêt de currentColor…

Le bug est ouvert chez Chromium.

Vincent De Oliveira a cependant trouvé une astuce pour le faire fonctionner sans devoir répéter la propriété et ça, c’est cool.

En repassant donc sur le CodePen pour le mettre à jour, je me suis également rendu compte que la media query -ms-high-contrast: active était inutile ; je l’ai donc supprimée. Cette requête n’est comprise que par IE 11 et inférieur — cependant comme elle était imbriquée dans une règle @supports ces derniers ne pouvaient pas la lire. Hop, un peu de code en moins !

Percevez-vous comme ce soulignement est affordant ? On a envie de cliquer dessus, pas vrai ? ↩︎
Terme technique issu dʼune longue histoire de la calligraphie à la plume (ou de lʼapprentissage de lʼécriture avec un stylo plume pour les plus jeunes dʼentre vous). ↩︎
Vous avez probablement déjà compris que si votre texte repose sur une image ou un dégradé, il nʼy aura probablement pas de salut pour votre soulignement. ↩︎
Sans cette astuce, certains éléments auraient un soulignement sur toute la largeur, même si le texte ne la remplit pas — et dʼautres éléments auraient un soulignement uniquement sur la dernière ligne, si dʼaventures ils fussent sur plusieurs lignes. ↩︎

Les éléments remplacés

Gaël Poupard — Mon, 16 Nov 2015 20:16:54 GMT

Pourtant — et malgré le fait que la plupart des éléments remplacés soient des balises auto-fermantes — ça nʼest pas la même chose !

Les mauvaises définitions

La définition de Dudley Storey

La plus connue est celle proposée par Dudley Storey dans son article « What’s A Replaced Element? » (traduit en Français sur La Cascade) que voici :

Les éléments remplacés sont essentiellement des éléments qui ont des dimensions pré-déterminées, sans bénéficier de CSS. Une autre façon de comprendre les éléments remplacés est “ ce sont les éléments dont le contenu est remplacé par une source extérieure ”.

Il prend pour exemple lʼélément input qui, même vide, aura des dimensions intrinsèques — car le navigateur remplace lʼélément par un objet avec des dimensions par défaut pré-déterminées.

Cʼest très bien, mais ça nʼest pas tout à fait ça. En réalité cette définition est orientée vers la conclusion de lʼarticle, qui précise que les éléments remplacés ne peuvent pas se voir appliquer de contenu généré à lʼaide de pseudo-élément.

Figurez-vous que cʼest parfois possible. Il sʼagit dʼune simplification abusive.

La référence de SitePoint

SitePoint propose une définition un peu plus pointue (en anglais) indiquant quʼun élément remplacé est un élément dont lʼapparence et les dimensions sont définies par une ressource externe. Les détails sont assez intéressants (notamment le dernier paragraphe sur le contexte inline) mais là encore cʼest en léger décalage avec la réalité.

En revanche ce qui est amusant, cʼest que la définition réelle est cachée dans le troisième paragraphe : « Les éléments remplacés peuvent également avoir des pré-requis de mise en forme imposés par lʼélément, hors du contrôle du CSS ; par exemple, les contrôles de lʼinterface utilisateur rendus pour les éléments de formulaires ».

En fait ils ne se contentent pas de pouvoir.

La spécification cachée

Soyons honnête, elle est vraiment galère à trouver. Le W3C précise dans CSS2.1 (en anglais) quʼun élément remplacé « est un élément dont le contenu est hors de la portée du modèle de mise en forme CSS ». Si vous en avez le courage, la spécification HTML5 est plus absconse mais rejoint globalement ce qui est dit précédemment.

Simple, non ? Ça inclut effectivement les éléments qui ont des dimensions intrinsèques, même lorsquʼelles peuvent être surchargées via CSS. La liste dont je dispose est documentée sur a11y.css. Elle contient lʼensemble des balises auto-fermantes, ainsi que les éléments de formulaires et les objets multimédias.

Le cas des boutons

Vous remarquerez que cette liste nʼinclut pas lʼélément <button>. Pour une bonne raison, à mon humble avis : cet élément nʼest pas un cas particulier dans la perspective de travail dʼa11y.css puisquʼil accepte les pseudos-éléments.

Voilà qui discrédite poliment la définition de Dudley Storey. Cela fait cependant de <button> une exception parmi les cas particuliers…

Cependant comme Nicolas Hoffmann me lʼa indiqué, <button> est bel et bien un élément remplacé. Fidèlement à la spécification, il dispose en effet de styles pré-définis — un savant mélange entre la vision de votre navigateur et celle de votre système dʼexploitation.

La singularité

Les éléments remplacés ont donc des dimensions intrinsèques, et ça inclut les boutons. Lorsque vous spécifiez une largeur sur un élément remplacé, vous écrasez sa largeur intrinsèque. Jusque là, tout va bien. Vous pouvez jouer avec une image, effectivement cʼest chouette.

Maintenant pour rigoler, prenez un <button> et affublez-le de ce CSS :


button {
  display: inline;
  width: 20em;
}

Jʼavais tendance à penser que ce CSS ne produirait rien, puisquʼon ne peut pas définir de dimension sur un élément inline. Sauf quʼun bouton a donc des dimensions intrinsèques quʼon peut surcharger — alors même que ces styles sont considérés comme hors de portée de CSS. La magie opère : un bouton en ligne obéira à une définition de sa largeur.

Vous pouvez jouer avec ce dabblet pour vous en convaincre.

Un réel problème ?

Probablement pas. Mais je me suis malgré tout retrouvé dans une situation enquiquinante. Je souhaitais tout bêtement mettre en place un soulignement amélioré en CSS à lʼaide dʼun dégradé et dʼune ombre. Or ce soulignement doit évidemment suivre le texte, y compris si ledit texte passe à la ligne. Cʼest généralement aisé pour nʼimporte quel élément : on le met en display: inline; et le tour est joué. Sauf que sur un bouton, ça ne fonctionne pas.

Heureusement, Vincent mʼa donné une solution qui fonctionne. Tant pis pour le bouton, cʼest le <span> qui aura droit à un soulignement amélioré.
**
Mais bon sang, quelle aventure pour un bête bouton qui ne veut pas se mettre en ligne !**

Le web en kit

Gaël Poupard — Fri, 30 Oct 2015 11:11:52 GMT

Beaucoup de gens qui fabriquent le web se sont plaints de lʼhégémonie dʼIE6.

Pour protester, ils se sont rués sur les nouveaux arrivants : Firefox et Chrome. Puis les produits Apple ont débarqué, apportant avec eux Safari. Cʼétait encore une révolution — et de fait, le nouvel endroit ou aller. Or Safari fonctionne sur la même base que Chrome, à savoir le moteur de rendu Webkit. Et petit à petit, nous nous sommes retrouvés avec un nouveau monopole.

Malheureusement, on ne casse pas un monopole avec un monopole. Car tous ces gens qui se sont rués sur les navigateurs WebKit ont produit des morceaux de web qui ne sont pas inter-opérables : on ne pouvait sʼen servir (voire simplement y accéder) autrement quʼavec un sésame estampillé WebKit.

Microsoft et Edge

De façon parfaitement sensée, Microsoft — qui détenait environ 95% des parts de marché des navigateurs web (ce qui lui est reproché) — a voulu faire table rase du passé pour en finir avec la mauvaise réputation de son navigateur vedette.^[1]

Alors ils font passer Edge pour WebKit.

Le -webkit-only

Les préfixes vendeurs

Vous commencez à flairer lʼarnaque, pas vrai ? Edge interprète désormais les CSS préfixées par -webkit-. Bon allez, si ça nʼest que ça cʼest de bonne guerre !

Sauf que… Non. Ça ne sʼarrête pas à ça.

Les propriétés hors spécification

Pendant très longtemps, Chrome et Safari ont implémenté des nouveautés avant de les proposer aux concepteurs des spécifications — notamment des propriétés et valeurs CSS. Ça permet de mettre un peu de pression sur le processus de spécification et de tenir en haleine les développeurs.

Parmi ces nouveautés, la valeur text pour la propriété background-clip.

Cette propriété fait partie intégrante de la spécification (en anglais) depuis longtemps. La valeur text a été proposée en 2008 par WebKit (en anglais), et nʼétait — jusquʼà preuve du contraire — supportée que par les navigateurs basés sur WebKit.

Edge gère !

Edge lʼinterprète, cette valeur exotique — et sans souci. Jʼai découvert ça inopinément, en me disant que la solution de repli proposée par Divya Manian (en anglais) était robuste. En terme de logique, elle est imparable : lʼarrière-plan est conçu pour ne sʼappliquer que si le clip est interprété, car lʼensemble est préfixé par -webkit-. Voyez plutôt :


[class="rainbow"] {
  color: #fff;
  display: inline-block;
  /* -webkit-only: Chrome, Safari, Opera */  
  background: -webkit-linear-gradient(…);
  background: -o-linear-gradient(…);
  -webkit-text-fill-color: transparent;
  -webkit-background-clip: text;
}

Mais Edge considère désormais les préfixes -webkit- comme des aliases, et les mange tout crus. Ça aurait pu être un problème dans ce cas précis, puisque théoriquement la paire background-clip: text; nʼest reconnue que par les navigateurs basés sur WebKit. Là encore : surprise ! Edge lʼapplique sans rechigner.

Cas isolé ?

De nombreuses techniques ont vu le jour et nʼont vécu que pour WebKit. Je mʼinterroge donc : parmi ces techniques que nous pensons réservées à WebKit, combien dʼautres encore ont atterri dans Edge discrètement ?

Et Windows Phone, on en parle 😄 ?

Et bien… En quelque sorte ! Pour clarifier, précisons que jʼutilise Windows Phone 8.1, qui embarque IE11. Dʼaprès mes lectures sur le blog technique de Edge, ce mécanisme dʼinterprétation des préfixes vendeurs -webkit- nʼest inclus que dans Edge — en tout cas, il nʼy est fait aucune mention du cousin IE11.

Figurez-vous que cʼest pourtant le cas (je suis sûr que vous nʼavez rien vu venir, avec mes gros sabots 😇). Enfin… Presque.

Le cas qui pique

Une fois nʼest pas coutume, Windows Phone et son IE représentent une configuration particulière. En lʼoccurrence, IE11 interprète les valeurs -webkit-linear-gradient(…) mais est incapable dʼappliquer la valeur text pour la proriété background-clip. Oups 🙈 !

Captures à lʼappui

Dans un monde merveilleux et homogène, nous « devrions » voir ceci :

Un arc-en-ciel incrusté au texte en CSS, visible sur les navigateurs WebKit et Edge

Et, le cas échéant si votre navigateur est allergique aux arc-en-ciels, voici le résultat attendu :

Le texte est simplement blanc sur Firefox et IE, pas dʼarc-en-ciel à lʼhorizon

Jusque là, tout va bien. La mécanique est belle, aucun danger grâce à la solution de repli évoquée précédemment. Maintenant, cassons tout ! Voici le rendu sur IE11 et UC Browser sur Windows Phone 8.1 :

Le texte est blanc, mais lʼarrière-plan arc-en-ciel est appliqué

Difficile de garantir quoi que ce soit dans ces conditions. A priori ce problème nʼexiste pas dans les versions antérieures de Windows Phone, et il faut noter que la version bureau dʼIE11 nʼapplique pas lʼarrière-plan !

Si vous voulez tester par vous-mêmes ou compléter mes propos, nʼhésitez pas à dupliquer mon dabblet.

Et pour ceux qui rigolent dans le fond, sachez que Windows Phone représente 4% de parts de marché des systèmes dʼexploitation sur mobile en France, entre juillet et septembre 2015 (en anglais). Ce nʼest pas négligeable, si tant est quʼon admette négliger une population.^[2]

Jʼaime rappeler aux gens qui pestent après IE quʼil est ma foi fort probable quʼils fissent partie des 95% dʼinternautes qui naviguaient avec. Ça pique. ↩︎
Je mettrais dʼailleurs ma main a couper quʼen réalité ce chiffre est déjà sous-estimé, à en croire mes yeux de lynx qui officient dans le tramway, le bus ou le TER à Nantes ↩︎

Paris Web et la vie

Gaël Poupard — Fri, 16 Oct 2015 11:22:50 GMT

Il sʼen est passé, des choses, cet été ☺.

Livres

Guide pratique de choix typographique

Je lʼavais peut-être déjà mentionné, mais tant pis — jʼen suis fier : David Rault mʼa fait lʼhonneur de citer mon compte-rendu de lecture de son « Guide pratique de choix typographique » sur la 4^e de couverture de sa réédition. Cʼest un excellent livre, je vous le conseille vraiment ! Vous le trouverez sur le site des Ateliers Perrousseaux.

Optimiser son référencement WordPress

Lʼouvrage de Daniel Roch sʼest — comme attendu — bien vendu. Pour sa seconde édition, Daniel a eu la riche idée dʼinviter des camarades à étendre le contenu afin dʼaborder des sujets connexes tels que :

la sécurité, par Julio Potier ;
le choix du thème, par Alex Bortolotti ;
ou encore lʼutilisation dʼAJAX, par Willy Bahuaud.

Il mʼa ainsi fait lʼhonneur de mʼinviter pour cette réédition à rédiger une introduction à lʼaccessibilité. Un défi passionnant pour moi, et une gratification remarquable ! Je dois bien avouer quʼen relisant ce contenu, jʼai déjà envie de le réécrire et lʼaméliorer encore — mais je ne cache pas mon plaisir et ma fierté dʼavoir pu participer à cet ouvrage.

Évidemment, je ne saurais assez vous conseiller de vous procurer ce livre sur le site des éditions Eyrolles.

Éco-conception des sites web

Simple aparté pour mettre en avant la participation de mon frère Luc Poupard à la relecture de la réédition de ce livre — dont la première édition est une mine dʼor — parce que ça aussi, jʼen suis fier ! Pour la petite histoire, il a été invité à cette relecture suite à son intervention lors de Paris Web 2014 intitulée « Internet et les TIC, pas très écologiques ? ».

Vous pouvez vous le procurer sur le site dédié au livre.

Événements

WP Tech

Lʼan passé, jʼai découvert le rôle dʼorateur au WP Tech lors de lʼatelier « Thème enfant : au-delà de la bonne pratique ». Cette année, jʼai opté pour un autre rôle, à découvrir également : bénévole. Je suis entré dans lʼéquipe un peu en retard, mais je commence à travailler un peu et jʼai hâte de passer cette journée avec le staff ! Si vous ne connaissez pas ce formidable événement, découvrez lʼédition 2015.

Paris Web

Déjà la 3^e édition à laquelle j’assiste et je prends toujours autant de plaisir à découvrir les gens et les sujets. Je ne vais pas mʼétendre sur un compte-rendu, le web en fourmille déjà et ce nʼest pas mon propos du jour — mais comme dʼhabitude il y a eu de grands moments. Peut-être vous ferais-je un véritable retour plus tard ☺.

Travail

Dans un contexte différent, jʼai changé de travail !

Après un an et demi de bons et loyaux services chez Kosmos, jʼai terminé le 30 septembre au soir afin dʼenchaîner sur Paris Web. Juste après ces trois jours autour de la Lune pour prendre de la vitesse (jʼai regardé Armageddon récemment), jʼai donc démarré au poste dʼintégrateur chez Ornikar — et pour le moment jʼen suis ravi.

Le changement de type dʼentreprise, de méthodes et pratiques de travail ainsi que dʼéco-système technique est très enrichissant ☺.

Projets

Jʼai toujours une multitude de projets en tête, mais la plupart relèvent de la sphère privée. Pour lʼaspect métier, je poursuis mes travaux sur a11y.css — même si ça sʼavère de plus en plus lent. Jʼai planifié deux nouvelles bornes, lʼune technique et lʼautre « identitaire » (graphisme, ligne éditoriale, réseaux sociaux…).

Et jʼai toujours de nombreux articles en attente. Vous repassez bientôt ?

21e séminaire AccessiWeb

Gaël Poupard — Wed, 15 Jul 2015 17:06:31 GMT

C’est donc une grande première, et moi qui lisait les comptes-rendus des précédents séminaires sur internet ait enfin pu y assister !

En tant qu’orateur

Le thème du séminaire était « Choisir et utiliser un CMS pour créer des contenus accessibles », organisé par Olivier Nourry.

Non seulement j’ai pu y assister, mais j’ai même été invité par Olivier à y faire une intervention autour de la même thématique que celle abordée lors du WP Tech au sujet des thèmes enfants dans WordPress (et leur utilisation dans une méthodologie de travail basée sur l’amélioration perpétuelle).

WordPress étant le CMS le plus utilisé au monde – et de loin – Olivier souhaitait mettre en avant une pratique concrète pour incorporer l’accessibilité à la production de sites WordPress. C’est avec plaisir que j’ai accepté le défi.

Je suis cependant peu satisfait de ce que j’ai pu montrer à cette occasion, j’étais très impressionné par mon auditoire et la nervosité m’a fait perdre pied à quelques reprises. En revanche je suis très heureux d’avoir pu rencontrer des personnes intéressantes, et assister aux autres présentations.

En tant que spectateur

C’est surtout dans l’assistance que j’ai pu apprécier la qualité de la journée. Toutes les présentations étaient incroyablement riches, je retiens notamment :

la présentation d’ATAG2 par Jean-Pierre Villain (qui travaille chez Access42 dont je vous ai déjà parlé) ;
l’adaptation d’EZ Publish lors de la refonte du site du Pas de Calais par Telmedia, présentée par Christophe Caron ;
l’atelier barbecue consistant à évaluer « comment ces quatre CMS permettent de répondre à des besoins de contribution typiques en respectant les critères d’accessibilité », avec quatre acteurs représentant chacun leur CMS de prédilection :
- WordPress était décortiqué par Claire Bizingre ;
- Édouard Cunibil a analysé Drupal ;
- SPIP fut passé au crible par Jacques Pyrat ;
- et finalement Mikael Ruzafa a dépiauté Joomla! ;
les démarches respectives de WordPress et Drupal pour proposer un CMS accessible dès son cœur, de l’interface d’administration jusqu’aux affichages proposés.

Les sujets étaient extrêmement intéressants, et comme l’a évoqué Olivier pour conclure le séminaire : ce type de démarche n’a – à ma connaissance, comme à la sienne – jamais été mené en profondeur.

La comparaison de la prise en compte de l’accessibilité des différents acteurs de l’écosystème des CMS est tout à fait pertinente et totalement absent des comparatifs qu’on peut trouver ça et là.

La présentation des ATAG2 en des termes compréhensibles par un humain est également une performance, que peu de personnes pouvaient réaliser. Ayant déjà tenté l’aventure de lire et comprendre les ATAG2, j’ai été épaté par le travail produit par Jean-Pierre Villain et ait noirci de notes quatre ou cinq pages de mon carnet.

Ce n’est pas fini !

Comme Dominique Burger (président de BrailleNet) et Olivier Nourry l’ont annoncé, un livre blanc est en cours d’élaboration afin de diffuser le contenu de ce séminaire.

Une invitation est également lancée aux professionnels du web – qui utiliseraient couramment un CMS oublié de ce séminaire – de se plier à l’exercice d’évaluer l’accessibilité de leur outil préféré afin d’enrichir le comparatif.

Pour conclure, je suis réellement ravi d’avoir pu rencontrer, échanger, apprendre autant et je tiens à remercier chaleureusement l’association BrailleNet pour avoir permis que cet événement ait lieu, et Olivier Nourry de m’y avoir invité en tant qu’intervenant : j’en suis très honoré.

WPMX Day

Gaël Poupard — Thu, 02 Jul 2015 18:42:39 GMT

Souhaitant toucher un maximum de personnes dans le public — tous profils confondus, j’ai donc proposé aux organisateurs de parler des points d’accessibilité que chacun traite sans le savoir. Mon objectif était bien entendu d’évoquer d’autres pratiques abordables et bénéfiques pour les utilisateurs.

Accessibilité et efficience

Voici mon support de présentation. Je ne vais pas forcément m’étendre étant donné qu’une vidéo devrait arriver bientôt, mais je suis relativement satisfait de cette présentation. Le temps de préparation a été énorme, incluant :

une phase de recherche assez longue ;
la rédaction d’un synopsis et la définition des différents métiers types ;
une carte heuristique afin de faire émerger les sujets principaux pour chaque métier ;
la création d’un plan puis son enrichissement ;
la mise en place du support ;
les échanges et relectures, notamment par Luc Poupard et Emmanuel Clément.

Globalement les retours ont été positifs et ça, ça fait plaisir :).

Les présentations

Les sujets étaient variés, et c’était extrêmement plaisant.

La présentation de WooCommerce par Rémi Corson était très intéressante, j’ai découvert beaucoup de choses et ai été impressionné par la progression fulgurante de ce qui fut une simple extension il y a quelques années. De plus Rémi est un orateur expérimenté, très agréable à écouter !

J’en cite une dernière pour ne pas m’éterniser, j’espère que les autres orateurs ne m’en voudront pas : « Faites rentrer votre éléphant dans une Smart™ — Bonnes pratiques sur mobiles » dont vous trouverez les slides sur Speakerdeck. Présentée par Stéphanie Walter et Jean-Pierre Vincent, cette présentation était rythmée, très dense, et extrêmement instructive. Jetez-y un œil !

L’organisation

Pour l’histoire, le nom WPMX vient de l’association WordPress Meet & eXchange. Ce sont donc les membres de l’association qui ont organisé le WPMX Day, et je tiens à les remercier à nouveau ainsi qu’à les féliciter car ils ont fait un boulot incroyable ! Entre la gestion des orateurs qui arrivent qui part avion, qui par train, l’hébergement, la restauration, le flux des présentations alternées avec les spots publicitaires des sponsors, leur plan s’est déroulé sans accro. Chapeau !

À la prochaine !

Et bien oui, car il y en aura une je l’espère. Vraiment la journée à Biarritz, dans un super hôtel, avec tout ces gens accentués (si, si, ils ont un accent) était vraiment chouette. Et je ne vous parle pas du samedi soir : dîner sur la plage avec Stéphanie, Jean-Pierre ainsi que Philippe Gélas et les organisateurs. C’était vraiment top, merci !

AccesSlide : la prise en main

Gaël Poupard — Sun, 24 May 2015 13:06:51 GMT

Access42 est la société créée conjointement par Armony Altinier (rédactrice du livre « Accessibilité web » dont j’ai écrit un compte-rendu de lecture) et Jean-Pierre Villain après qu’ils aient remporté le marché de refonte du RGAA3. Ils ont été rapidement rejoint par Sylvie Duchateau et Audrey Maniez.

Si vous ne connaissez pas ces noms, sachez qu’ils sont incontournables dans le domaine de l’accessibilité numérique en France. Et c’est peu dire !

Premier contact

Pour commencer, je tiens à signaler la manière tout à fait attractive qu’a trouvé d’Access42 pour communiquer sur ce nouvel outil : c’est suite à ma participation à leur jeu-concours : le secret de la licorne que j’ai reçu un mail signalant dans un premier temps le dépôt Github d’AccesSlide.

C’est bête, mais ça donne envie de regarder ! Étant donné que j’avais déjà cherché une solution lors de la préparation de mon atelier pour le WP Tech et que je prépare une conférence pour le WPMX, je me suis lancé dans l’utilisation de cet outil.

De prime abord, cette solution est très riche. Le sommaire ainsi que les réglages utilisateurs sont de très gros atouts pour ce système de diaporama.

Commençons par créer le contenu !

La contribution

Partie cruciale s’il en est, AccesSlide permet de rédiger ces slides de façon extrêmement simple, en imposant très peu de contraintes sur le balisage. Il suffit d’une section avec la bonne classe, et le tour est joué :

<section class="slide"> [votre diapo] </section>

Il est difficile de faire plus simple, et c’est équivalent en terme d’efficacité aux solutions populaires telles que Reveal.js. Ainsi pour la saisie du contenu, c’est top !

La personnalisation

L’équipe d’Access42 a gardé cet aspect important pour l’appropriation en tête, et c’est tant mieux. Un système de thèmes fonctionne très bien, ce qui m’a permis d’implémenter très rapidement des styles qui correspondent à la fois à ce site mais aussi à ma précédente présentation. Quelques ajustements ont évidemment été nécessaires, mais rien de bien compliqué.

Je dois même avouer avoir été agréablement surpris par la facilité de personnalisation, car la majorité des styles structurels sont cloisonnés dans un fichier principal et évite toute forme de collision désagréable.

Mon thème

Ni une, ni deux : j’ai donc créé mon thème. Voici donc le support de mon atelier du WP Tech refondu en utilisant AccesSlide. Qu’en pensez-vous ?

Pour rester fidèle à ma première présentation — mais aussi pour essayer de creuser un peu plus — je suis allé faire quelques modifications plus profondes.

Les pictogrammes en SVG

Mon dada du moment. Les boutons et liens icônes sont intégrés à l’aide d’une police d’icône dans la version « officielle » proposée par Access42. Personnellement, je n’aime pas cette technique, que je trouve moins robuste qu’une bonne vieille balise image avec une source vectorielle. J’ai donc changé la façon de gérer ces boutons. Ça m’amène à une première remarque d’ordre général, mais sans être expert je pense que le javascript peut encore être amélioré car on trouve beaucoup de répétitions.

Pour information, il s’avère que si une balise image a une source svg, il faut ajouter le rôle image afin que VoiceOver accède à l’alternative textuelle :

<img src="*.svg" alt="Quel essai !" role="img" 
   width="8" height="8" />

Étant donné que ça ne constitue pas un effort insurmontable ni même complexe, je préfère toujours cette version (qui fonctionne à partir d’IE9).

Un petit coucou et un grand merci à Nicolas Hoffmann qui, suite à mon interrogation, a permis de confirmer ce diagnostic en haranguant la plèbe sur Twitter. Lisez le fil de discussion, c’est très intéressant !

La transition en CSS

J’avais particulièrement apprécié la gestion des transitions sur Reveal.js, plutôt simple et efficace à l’aide de CSS. Aucun des effets proposés par AccesSlide ne correspondaient à celui que j’utilisais précédemment, alors je l’ai re-créé et ajouté !

Là encore, ce fut extrêmement facile en déclarant la nouvelle animation conformément aux isntructions laissées dans le fichier javascript principal. Côté utilisateur, vous pourrez voir cette animation en la choisissant dans les réglages : je l’ai nommée « Coulisse vers la gauche » puisque c’est ce qu’elle fait !

Ainsi le conteneur principal se voit affubler d’un attribut data-effect dont la valeur est le nom de l’effet. Il n’en faut pas plus pour appliquer la transition CSS de mes rêves (même si je dois avouer devoir truander un peu afin de ne pas toucher aux fichiers originels) :

[data-effect="ffoodd"] .slide {
  display: block !important;
  opacity: 0;
  margin: .5rem;
  position: absolute;
  top: 0 !important;
  visibility: hidden;
  transform-style: preserve-3d;
  transition: 
  transform-origin .8s cubic-bezier(.26, .86, .44, .985),
  transform .8s cubic-bezier(.26, .86, .44, .985),
  visibility .8s cubic-bezier(.26, .86, .44, .985),
  opacity .8s cubic-bezier(.26, .86, .44, .985);
}

[data-effect="ffoodd"] .slide[style*="display: none"] {
  opacity: 0;
  pointer-events: none;
  position: absolute;
  transform: translate3d( -150%, 0, 0 );
  visibility: hidden;
}

/* C’est là que je truande :P */
[data-effect="ffoodd"] .slide[style*="display: block"] {
  opacity: 1    !important;
  position: relative  !important;
  visibility: visible !important;
}

[data-effect="ffoodd"] .slide[style*="display: block"] ~ .slide[style*="display: none"] {
  transform: translate3d( 150%, 0, 0 );
}

Et puis pour le fun, j’ai ajouté une animation au chargement de la page :

@keyframes move-up {
  from {
  transform: translateY( 100% ) translateZ( 0 );
  opacity: 0;
  }
}

[data-effect="ffoodd"] #wrapper {
  animation: move-up .8s cubic-bezier(.165, .840, .440, 1);
}

Et le tour est joué ☺.

Participez !

Pour le moment mon thème est trop éloigné de la solution originelle pour que je puisse le proposer simplement, mais avec un peu de réécriture ce devrait être faisable (tout comme l’animation). Je tenterai de les proposer à Access42 dès que mon temps libre me le permettra !

Même si je ne m’en suis pas servi, je tiens également à souligner l’utilisation de fichiers partiels et du post-processeur Myth pour générer les sources. Le découpage en fichiers partiels rend l’orientation dans les fichiers encore plus clair. Côté compilation, une configuration basique pour Grunt est aussi mise à disposition.

Tout est fait pour que quiconque puisse s’approprier la solution rapidement.

Ah oui au fait, il y a d’autres fonctionnalités que je n’ai même pas évoquées :

les styles pour l’impression ;
le responsive ;
un mode plan ;
un système d’internationalisation géré via javascript.

Plutôt pas mal, non ☺ ?

Alors à votre tour de contribuer : AccesSlide est sur Github !

Épilogue

Il me reste un point important remonté par Sophie Schuermans concernant l’aspect responsive que j’ai un peu endommagé. Et je tiens également à remercier Nicolas Hoffmann pour sa relecture attentive et ses conseils, ainsi qu’Olivier Nourry pour son intérêt !

Choisir ses couleurs pour le Web

Gaël Poupard — Tue, 07 Apr 2015 11:00:38 GMT

Ce livre nous donne quelques clés pour en apprendre les tenants et les aboutissants.

Les fondations

Le livre est plutôt bien conçu, démarrant à la base de la théorie pour terminer par des exemples de mise en pratique. Le sommaire est d’ailleurs révélateur de la logique du livre :

Terminologie
Groupes de couleurs
Signification des couleurs
Accords de couleurs
Créer une palette de couleurs
Règles d’utilisation de la couleur pour le web
Appliquer la couleur à vos sites web
Références

Globalement, bien que simple, cet ouvrage couvre un large éventail de connaissances au sujet des couleurs. La terminologie est détaillée et illustrée, la signification des couleurs mentionne l’aspect culturel avec exemples à l’appui, les accords et les palettes sont présentés de façon très communicative également.

Qualités

La couleur dans la création graphique se heurte souvent au même écueil : la subjectivité. Comme on dit souvent :

Les goûts et les couleurs

Palier cette difficulté se fait relativement facilement, en qualifiant les couleurs et leurs accords. et bien ce livre le fait à merveille, et en tout transparence. Ça s’avère très agréable à parcourir. De plus la qualité des visuels et des exemples est bonne, sans être extraordinaire.

Il ne s’agit pas d’un livre destiné aux spécialistes mais il permet aux profanes de découvrir en profondeur la thématique des couleurs.

Cas pratique

Les couleurs ont été un sujet très particulier lorsque j’ai réalisé la refonte de ce site, au même titre que la typographie et la mise en page par exemple. C’est pourquoi j’ai analysé rétrospectivement la gamme de couleurs choisies, avec l’aide du livre.

Pour faire simple, voilà les connotations transportées par les couleurs principales :

bleu sombre : loyauté, honnêteté, force, confiance, sagesse, assurance, masculin, dignité, force, autorité, sérénité ;
rouge vif : passion, optimisme, énergie, dynamisme.

L’accord de ces deux couleurs génère de la tension, et le blanc cassé permet d’adoucir l’aspect général et d’établir une zone confortable contrastant avec le fond. Ça correspond assez bien à ce que je souhaitais obtenir lors de la refonte.

C’est une lecture très basique, mais c’est le niveau dont je dispose actuellement :).

Un avis

Pour terminer, c’est une lecture intéressante pour quiconque est pris de curiosité pour ce domaine. Si les couleurs vous parlent, n’hésitez pas à vous procurer ce livre.

Découvrez le calcul magique

Gaël Poupard — Mon, 30 Mar 2015 16:30:04 GMT

Et ça, c’était pas terrible. Non, vraiment pas. On cherchait frénétiquement à obtenir le même rendu sur tous les navigateurs et tous les écrans. Aujourd’hui, c’est drôle — à l’époque, c’était le nerf de la guerre.

Les valeurs uniques

Cette recherche de perfection était régulièrement entravée par plusieurs limitations techniques :

les styles par défaut des navigateurs différaient, parfois beaucoup — ce problème a été résolu à coup de reset ou de normalize ;
les unités relatives étaient parfois compliquées à manœuvrer, à cause d’inconsistances dans les valeurs calculées par les navigateurs (notamment la question des arrondis) mais ces derniers ont plutôt bien corrigé le tir, depuis ;
les unités différentes, difficiles à manipuler ensemble (px, %, em, etc.) ;
l’incompréhension des modèles de boîte, au moment ou tout le monde blâmait le mode quirks d’IE avant de l’adopter massivement sous sa forme CSS (box-sizing: border-box;, pour ceux qui se posent la question).

Pour l’intégrateur, ces différents tracas pouvaient être résolus de la même façon : des valeurs absolues en pixels, de préférence. Ainsi ajustions-nous nos largeurs, marges internes et marges externes au pixel près.

Désormais il est relativement rare d’en arriver à ces extrémités, grâce aux nombreux outils qui sont apparus ces dernières années. Il en est un en particulier qui aide bien, lorsque box-sizing ne suffit pas : la fonction calc().

La fonction calc() à la rescousse

Pour faire simple — vous la connaissez sûrement déjà — elle permet de réaliser des calculs simples directement dans les styles, en mixant les unités.

Dans un écosystème rempli de nombres magiques et d’intégration pixel perfect, une reprise partielle du code peut s’avérer extrêmement fastidieuse.

En l’occurrence, c’était mon cas lors d’un POC l’an dernier. Je devais travailler un gabarit souple en surcouche d’une structure figée, sans accès au DOM.

Ce fut relativement simple à l’exception d’un point : il fallait un bloc image avec titre superposé, qui prenne les deux tiers de la largeur du site — largeur devenue relative, je le rappelle — en partant de la colonne centrale. Jusque là, ça va ! Le point vraiment compliqué est que le bloc de la colonne de droite devait suffisamment se décaler en hauteur pour laisser la place à ce nouveau contenu, tout en respectant le ratio de l’image constituant ce nouvel élément — puisqu’elle sera souple également. Ah, et pour s’amuser un peu visuellement, il faudrait conserver un rappel visuel du colonage au-dessus du nouveau bloc !

Bien, utilisons une bordure en haut pour gérer le décalage !

Ça commence à faire un certain nombre de calculs, vous ne trouvez pas ?

La situation complexe

Textuellement, ça n’est pas forcément évident. Voici une petite illustration, dans laquelle la zone blanche est le nouvel élément, et le bloc rouge est la bordure dont je devais ajuster la dimension :

Représentation graphique des proportions entre les blocs

Finalement, je suis parvenu à simplifier le calcul en tournant autour du ratio de l’image utilisée (en blanc sur le schéma), soit 431:950. Il s’agissait donc d’exprimer la hauteur de la bordure selon 3 valeurs :

la proportion en largeur que représente ce nouveau bloc par rapport au viewport, soit 72% ;
le ratio de l’image utilisée, en l’occurrence 431/950 ;
le décalage supplémentaire à ajouter au-dessus et en-dessous pour l’esthétisme, ici 4.8em.

La magie opère

Et voilà comment on aboutit à :

aside {
  border-top-width: calc( 72vw * 431 / 950 + 4.8em);
}

Grâce à ce calcul, le décalage reste correct et proportionnel au reste de l’écran, et l’aspect graphique est homogène dans tous les contextes d’affichage.

Les suppléments

Depuis ce POC, j’ai découvert le travail de Nicolas Hoizey sur esviji V2, qui utilise les ratios, les calculs et les unités de viewport pour atteindre un degré d’adaptation aux écrans extraordinaire. Je vous conseille de garder un œil sur son projet, et surtout de parcourir la feuille de styles générée qui est remarquablement écrite !

Sass pour les webdesigners

Gaël Poupard — Mon, 23 Mar 2015 10:00:27 GMT

En revanche, cette collection est dédiée à la découverte des sujets. Leur accroche le sous-entend :

Brief books for people who make websites

C’est pourquoi les livres abordant un langage particulier ne m’ont jamais réellement appris : concernant le HTML5 ou le CSS3, je connais les bases et ma veille régulière me permet de les entretenir. Cet ouvrage sur Sass ne déroge pas, je n’ai pas appris grand chose — malgré ça je vous recommande ce livre !

À l’abordage

Pour débuter, précisions que le livre a un objectif. Il ne se contente pas d’énumérer les fonctionnalités de Sass, mais vise plutôt à persuader les personnes réticentes ou intimidées par Sass qu’il n’y a aucun risque ni aucun investissement particulier à commencer à l’utiliser.

En effet, il est toujours possible d’écrire son CSS normalement, sans rien changer à ses habitudes de travail établies. On peut cependant débuter gentiment par définir une variable et l’utiliser, ou jouer avec un mixin simple. Ça ne coûte rien, c’est facile à faire, bref : que du bonheur !

À l’américaine

On peut en dire ce qu’on veut, mais les auteurs de la collection sont des orateurs hors pair et des rédacteurs nés. La plupart ont apporté tellement d’idées à nos métiers, nos façons de les voir et nos méthodologies de travail qu’ils sont l’équivalent de prophètes, que tout le monde écoute attentivement.

Dans cet ouvrage, Dan Cederholm (qui a déjà publié « CSS3 pour les webdesigners », dans la même collection) démontre une fois de plus sa capacité à expliquer clairement les points techniques, à établir une connivence avec le lecteur et à s’exprimer avec efficience. Tout ça rend ce livre extrêmement agréable à lire.

À l’envie

Même si je n’ai pas appris grand chose, ce livre est un bon ouvrage, agréable à lire et que je conseille tout particulièrement aux personnes qu’on peut affubler de l’étiquette webdesigner et qui n’ont pas encore mis les mains dans le cambouis de Sass.

Toutefois je place un léger bémol sur le fait que ce livre en VO a déjà deux ans, et que certaines recommandations de l’époque sont devenues désuètes. Je pense notamment à l’imbrication des sélecteurs pour refléter le DOM, qui est désormais considéré comme une mauvaise pratique à bien des égards.

Étant donné le rapport qualité prix de cet ouvrage, je le recommande à tous les débutants en Sass, qu’ils soient étudiants ou professionnels aguerris !

JavaScript and Jquery

Gaël Poupard — Mon, 09 Mar 2015 09:00:48 GMT

Ce livre vise à faire le premier pas vers une utilisation correcte du JS. Il explique en détail les concepts clés du langage.

La métaphore des objets

Très appréciable pour le débutant que je suis, la première partie sur les bases de la programmation et la présentation des fonctions, méthodes et objets est abordée efficacement : imaginez une voiture. La suite est simple, il s’agit de votre objet et elle dispose de propriétés, de méthodes et de fonctions pour gérer le tout.

Je ne vais pas vous présenter le contenu (vous irez le lire !) mais simplement évoquer l’approche choisie, qui m’a semblée extrêmement pertinente. C’est le reproche que je fais très souvent aux livres qui souhaite vous faire démarrer avec le JS : ils sont rédigés par des techniciens, avec un vocabulaire de techniciens.

Ici, le seul pré-requis est de connaître un minimum HTML et CSS.

Illustrations et schémas

La véritable force de cet ouvrage réside dans sa mise en page et ses multiples illustrations. La représentation graphique — sous forme de schémas — des enchaînements logiques est un atout considérable. C’est la solution par laquelle je transitais systématiquement lorsque je découvrais le langage, bien que mon approche était plus textuelle que graphique.

La normalisation d’un système graphique pour représenter la logique inhérente aux scripts est un élément que je vais probablement tenter d’intégrer à mon travail.

Les limites annoncées

Ce livre s’adresse avant tout aux débutants. Évidemment, les sujets n’iront pas en profondeur.

Cependant je reste malgré tout sur ma faim, car très peu de problématiques pratiques sont abordées. Les exemples sont certes bien choisis et travaillés, mais ils sont légèrement utopiques. Personnellement, en me lançant dans l’apprentissage du JS, j’ai rencontré des situations complexes et des problèmes qui ne sont qu’effleurés. Ça ne me surprend pas mais c’est ce qui explique que cette lecture ne m’ait pas énormément appris, alors que je pars de loin.

Ensuite, le parti est pris de travailler avec jQuery. C’est annoncé, pas de surprise. Mais par un heureux hasard, jQuery n’est employé que dans les situations qui pourraient devenir complexes. C’est son intérêt, mais j’aurais beaucoup apprécié que le livre évoque la création des mêmes fonctionnalités avec et sans jQuery. Premièrement, pour mettre en avant les avantages de jQuery et la pertinence de son utilisation. Deuxièmement, pour mentionner les écueils potentiels .^[1]

Une référence du genre

Malgré ces aspects négatifs, ce livre est de loin le meilleur ouvrage d’apprentissage du JS que j’ai lu jusqu’à présent. Mon profil étant intermédiaire je reste légèrement frustré, mais j’ai tout de même appris quelques trucs et surtout, les explications claires et illustrées ont éclaircies beaucoup de choses que je pensais savoir.

En bref, si comme moi vous n’êtes pas un spécialiste, je vous recommande chaudement cette lecture 🙂

Et les contournements possibles, autant que faire se peut. ↩︎

a11y.css, version deux

Gaël Poupard — Mon, 02 Mar 2015 20:45:32 GMT

Ainsi depuis la toute première mouture (en CSS) de cette feuille de style de diagnostic, beaucoup de choses ont changé. Voyons ça en détail 🙂

Corrections multiples

Comme vous pourrez le voir sur Github, pas moins de 97 issues ont été résolues. Cela a été possible grâce aux retours de quelques personnes, que je tiens à citer et remercier à nouveau :

Entre les bugs et les découvertes diverses, la qualité et la pertinence d’a11y.css ont considérablement progressé.

Compteurs CSS

Les compteurs sont au nombre des améliorations simples mais utiles — ces choses parfois qualifiées de quick win. Même si l’idée cheminait dans mon esprit depuis longtemps, c’est l’implémentation dans le DebugCSS de Yahoo qui a produit le déclic.

Les fonctions CSS de compteurs font partie des outils qui trouvent rarement un contexte d’utilisation pertinent. Pour une fois, c’est le cas !

Personnalisation

Après la fastidieuse relecture de mes différentes sources, ce qui n’était qu’un simple fichier CSS de diagnostic est devenu un système complexe basé sur Sass — dont le fichier de sortie final compressé pèse 80kb !

Il devenait indispensable de permettre aux utilisateurs le désirant de charger seulement les portions qui leur sont utiles. Avec l’aide de Kitty Giraudel, deux mécanismes ont été mis en place.

Générateur de bookmarklet

Il était déjà possible aux utilisateurs de Sass de ne compiler que les niveaux de critères qui les intéressaient. Désormais, ces fichiers nivelés sont mis à disposition dans le projet.

Le bookmarklet existait depuis quelques temps déjà, mais désormais un petit formulaire sur le site de présentation permet de le paramétrer en définissant le niveau minimum nécessaire.

Désactivation de tests

Pour que les utilisateurs de Sass aient toujours un intérêt à disposer du projet sur leur poste, mais aussi afin que les utilisateurs les plus avertis puissent personnaliser cet outil, Kitty a également conçu une fonction pour désactiver les tests au cas par cas. Par exemple, si vous voulez désactiver les erreurs à propos des mauvais tabindex et du href manquant, voici comment faire :


@include disable-errors("tab-order, no-href");

Et ça, c’est plutôt pratique 😀 !

Traduction

Pour celle-ci, je vais applaudir discrètement et vous renvoyer vers l’article écrit par Kitty (en anglais) qui détaille le fonctionnement de son système de traduction en Sass.

Oui, vous avez bien lu :désormais a11y.css est multilingue en demeurant écrit uniquement en Sass. Outre la portée accrue de façon incroyable suite au passage en anglais, l’exploit technique de Kitty est incroyable. J’en profite pour signaler la parution de son premier livre « CSS3 : pratique du design web » en vente aux éditions Eyrolles, que je vous recommande chaudement.^[1]

Documentation & test

Vous vous en doutez, le projet est devenu relativement complexe. Les solutions apportées par les différents contributeurs on tellement enrichi ce projet que même moi, je ne m’y retrouvais plus.

J’avais déjà mentionné lors de mon atelier au WP Tech mon intérêt pour la documentation ; c’est donc tout naturellement que j’ai cherché à documenter plus précisément a11y.css. Et de mon point de vue, il y a deux aspects très différents à documenter :

le contenu des tests : pourquoi ces critères, comment ont-ils été défini, quel est leur intérêt.^[2]

la structure du projet Sass, ou pour parler le technicien : l’API.

Premier chantier : trouver les outils adaptés !

Hologram

Ayant démarré ce projet seul et n’ayant pas imaginé le partager, les recherches qui m’avaient permis d’aboutir à certains tests n’étaient pas suffisamment documentées. J’ai donc étoffé les références de chaque test en indiquant, autant que faire se peut :

Les bonnes pratiques Opquast ;
Les critères et tests Accessiweb HTML5 et ARIA ;
Les succès WCAG 2.0 ;
Les sources dans des projets équivalents.

Ces ressources étant réunies, je souhaitais mettre à l’épreuve cet outil en mettant en place une page de démonstration qui servirait aussi à suivre les éventuelles régressions. Et parce qu’il ne s’agit pas seulement de pouvoir tester, mais également d’expliquer et de partager ces bonnes pratiques, un court descriptif du test était nécessaire.

Pour résumer, je cherchais donc un outil capable :

D’afficher la description et les liens associés au test ;
Un exemple de code HTML lisible ciblé par le test, et une version interprétée par le navigateur
La capacité d’organiser les nombreux tests présents.

C’est là qu’intervient Hologram, une gem Ruby créée par Trulia. Elle m’a semblé parfaite puisqu’elle repose sur des commentaires CSS formatés pour générer la documentation. Son objectif premier est la création et la maintenance de guides de style, ce qui n’est pas si loin du sens premier d’a11y.css : gérer et maintenir un ensemble de pratiques à vérifier.

Hologram est incroyablement simple à manipuler, puisqu’une fois la gem installée il suffit de commenter son CSS de la façon suivante :


/*doc
---
title: "[tabindex] > 0"
name: tab-order
category: Errors
---
The `[tabindex]` attribute should never be greater than 0.
* <https://github.com/Heydon/REVENGE.CSS/blob/master/revenge.css#L337>
```html_example
<button tabindex="1">Positive tabindex is bad</button>
```
*/

La syntaxe est intelligible, et reste utile sans Hologram pour générer la documentation. Un point que j’apprécie ! Pour générer la documentation, c’est très simple :


hologram

Et voilà ! Hologram génère un mini-site statique grâce à un jeu de ressources très simple. Il est ainsi possible de personnaliser l’entête, le pied-de-page et les ressources statiques pour aménager sa documentation à volonté. Magique 🙂

Et puisque j’avais déjà créé une branche pour servir de présentation en ligne sur Github, j’ai ajouté ces nouveaux fichiers HTML afin d’en faire un véritable site de démonstration.

Jetez un œil au site de démonstration d’a11y.css !

SassDoc

Pour finir, l’architecture du projet s’étant alourdie d’options et de fonctionnalités, il fallait permettre aux utilisateurs de Sass de s’approprier plus facilement l’outil.

Par chance, la majorité de ces enrichissements étaient l’œuvre de Kitty Giraudel, qui s’avère aussi être le créateur de SassDoc. La personne a tendance à faire des trucs un peu fou en Sass, et cet outil de documentation correspond à la perfection aux besoins d’une API Sass.

Ni une ni deux, Kitty a mis en place SassDoc !

Et voilà un projet complètement documenté.

Ce n’est pas fini !

Il reste quelques sujets à avancer :

Mettre à niveau SassDoc pour utiliser la V2 ;
Créer un thème SassDoc pour l’intégrer au site ;
Essayer d’ajouter une version française de cette documentation — ce qui semble complexe ;
Trouver une façon de cibler les éléments auto-fermants dans les tests génériques ;
Chercher de nouveaux tests à ajouter :D.

Et, bien sûr, maintenir tout ça dans le temps !

Je ne sais pas si ça se sent mais ce projet me passionne et je suis enchanté d’avoir pu partager mes réflexions, mes pratiques et mes idées avec toutes les personnes qui sont intervenues. J’ai énormément progressé grâce à ces échanges, et ma plus grande fierté est de voir a11y.css cité dans la section debug de la méthode Daisy, créé par une personne que j’admire : Romy Duhem-Verdière.

Sans rire, le mec est un génie alors achetez son livre et lisez son blog. ↩︎
Je ne l’ai pas encore dit mais un des objectifs du projet est clairement devenu l’apprentissage et l’accès aux savoirs. Asséner un message sans l’expliquer me parait inutile, tout comme appliquer religieusement le contenu du message n’est pas pertinent. ↩︎

WP Tech 2014

Gaël Poupard — Thu, 04 Dec 2014 22:08:44 GMT

Car non, je ne vais pas vous en faire un compte-rendu : j’étais orateur, et ça me fait beaucoup de choses à raconter !

La sélection des sujets

L’organisation en amont

À l’instar de nombreux événements de ce type, les organisateurs ont lancé un appel à orateurs. La seule demande était une orientation technique du sujet, et Willy et Daniel avaient même offert des suggestions de sujets. Leur grande idée a été de sonder l’intérêt de leur public avant de se lancer dans l’organisation, et ils en ont profité pour demander si des sujets particuliers les intéressaient.

Et j’aimerais à nouveau remercier Willy et Daniel, qui ont initié le mouvement, mais aussi Simon et Stéphanie qui ont prêté main forte ainsi qu’Emmanuel. J’en oublie certainement, mais je suis vraiment heureux de vous avoir rencontrés à cette occasion, et ce fut incroyablement plaisant de sentir ce staff à l’écoute de son futur public.

L’invitation au voyage

J’ai évidemment été parmi les premiers à répondre à leur sondage. Parmi les sujets qui sortaient du lot, les thèmes enfants ont fait leur apparition. Pour une raison inconnue, Willy m’a proposé de participer en tant qu’orateur — sur un sujet de mon choix parmi les suggestions — et autant vous dire que, passée la joie procurée, le challenge m’a vite motivé. Les thèmes enfants m’ayant été indispensables dans mes projets WordPress depuis au moins trois ans, j’ai rédigé une proposition de sujet sur leur utilisation avancée.

Et devinez quoi ?

Il a été retenu.

La préparation

Il a donc fallu me plier à l’exercice. Comme bon nombre de professionnels, j’ai déjà eu l’occasion de faire des présentations devant un public plus ou moins vaste, mais pour la première fois j’allais m’adresser à un panel de techniciens probablement bien meilleurs que moi.

La différenciation

Le sujet des thèmes enfants est relativement connu, avec le biais dénoncé dans mon synopsis : les bonnes pratiques prônées par WordPress, qui sont loin d’être motivantes pour s’investir dans ce mécanisme génial. Je savais déjà que ma façon de faire tire ses origines à l’extérieur de l’écosystème WordPress : j’aime mon travail, et j’aime le faire bien.

J’ai donc mis en valeur la qualité web, et comment les thèmes enfants couplés à de bonnes habitudes de travail permettent de gérer sans frais la qualité globale de nos productions.

En parlant d’habitudes

Mon cursus de communication visuelle m’aura enseigné de nombreuses façons de cultiver mes idées. Je suis donc parti, de façon assez ordinaire, sur une carte heuristique :

Carte heuristique des concepts liés à l’utilisation de thèmes enfants dans WordPress

Comme toute bonne carte heuristique, c’est touffu. Une fois les termes clés regroupés autour de thèmes principaux, j’ai formalisé et éclairci le tout en créant un simple tableau :

Tableau des concepts clés

Me voilà fin prêt à rédiger ma présentation, le plus compliqué étant d’en trouver des illustrations techniques en cohérence avec mes propos. Mais je pense avoir réussi :). Si le cœur vous en dit, vous pouvez consulter la présentation de l’atelier « Les thèmes enfants : au-delà de la bonne pratique ».

Le dîner des orateurs

Malgré le stress qui montait, je me suis rendu au dîner des orateurs et des bénévoles, la veille de l’événement. Et j’ai été très chaleureusement accueilli par Daniel, puis eut le loisir d’échanger avec Emmanuel, Simon, Stéphanie et Amaury durant le repas.

Comme pour l’ensemble du WP Tech, je suis seulement déçu par le manque de temps : j’ai raté pas mal d’occasion pour rencontrer certaines personnes que je côtoie sur le web depuis longtemps, telles que Julio Potier, Julien Maury, Aurélien Denis, et même Willy et Daniel que je n’ai finalement fait que croiser (comme tout le monde, je pense :D).

Le jour-même

Levé à 6h, la tête dans la pâté, mais très, très motivé ! L’accueil à l’Epitech par l’équipe était vraiment agréable, et parmi les goodies nous avons pu trouver un T-shirt et des stickers à ajouter sur nos badges. Le choix était amusant : entre déclaration d’amour et troll en bonne et due forme, tout le monde y a trouvé son bonheur. Sans surprise, j’ai choisi « Mes thèmes enfants ne parlent avec des inconnus ».

Je vous enjoins à nouveau à lire l’excellent compte-rendu sur WP Marmite, car je vais directement passer à ma prestation.

J’en suis relativement content, bien que je doive avouer qu’elle ne s’est pas déroulée du tout comme je l’avais prévue ! Je souhaitais générer des échanges tout au long de l’atelier, mais très vite je me suis aperçu que je n’y parviendrais pas : j’avais trop de choses à dire.

J’ai donc insisté auprès de mes spectateurs du jour pour qu’ils interviennent également, quitte à m’arrêter quelques instants et attendre que quelqu’un prenne la parole. Et ça a fonctionné.

Ma peur d’être dépassé techniquement par certaines suggestions s’est estompée rapidement, car je crois être parvenu à comprendre les propositions et y adapter mes réflexions au fil de l’eau.

Bien terminer la journée

Puis j’ai eu la surprise de recevoir quelques retours agréables sur cet atelier, dès la fin de la journée puisque quelques personnes m’ont interrogé sur certaines pratiques concernant les thèmes enfants et la gestion de la qualité.

C’était une chouette expérience, et j’en retiendrais vraiment la simplicité des échanges et les (pas suffisamment nombreuses) rencontres de la journée. Les prestations étaient toutes d’une très grande qualité, alors empressez-vous de regarder les vidéos dès leur mise en ligne !

Robert J. Hanlon

Gaël Poupard — Fri, 14 Nov 2014 22:55:32 GMT

N’attribuez jamais à la malveillance ce qui s’explique très bien par l’incompétence.

Retour de Paris Web

Gaël Poupard — Thu, 30 Oct 2014 24:41:28 GMT

Comme en 2013, c’est en compagnie de mon frère Luc que j’ai pu arpenter le métro parisien. Mais cette année était particulière pour Luc, puisqu’il était orateur !

Internet et les TIC

Pas très écologiques ?

C’est l’intitulé de sa conférence, que je vous invite à consulter en vidéo sur le site de Paris Web. Sur un sujet quelque peu parallèle, Luc a pris le parti de sensibiliser son auditoire à l’impact environnemental des nouvelles technologies à l’aide de données choc. Bien qu’ayant lu une partie de ses sources avant sa conférence, j’ai été agréablement surpris par le déroulement de sa prestation qui s’est avérée fluide, rythmée et réellement intéressante. Et je crois qu’elle a produit son effet !

Trêve de flagorneries, d’autres conférences se sont montrées tout à fait passionnantes.

Des orateurs captivants

Les sujets cette année m’ont semblé globalement moins techniques, et pourtant bien plus profond. Un certain nombre de conférences abordaient le web sous un angle différent, à l’instar de Luc mais j’aimerais également citer :

Goulven Champenois : « Intitulés de poste, bas les masques ! » ;
Jean-Philippe Simonnet : « Petits secrets entre amis : les acteurs du web doivent ils prêter serment ? » ;
Jérémie Patonnier : « La « logiciellisation » du web ».

Parmi les quelques sujets techniques, deux se sont brillamment illustré — autant dire que je les ai adorés — grâce à des orateurs phénoménaux :

Rémi Parmentier : « Sortons l’intégration d’e-mails de la préhistoire » ;
Christophe Porteneuve : « JS + toi = ♥ ».

Chacun dans un style bien particulier, ils nous ont tous deux fait passer un moment terrible. Rémi Parmentier, suppléé par des séquences de Jurassic Park et de Toy Story, a dressé un état des lieux au vitriol des difficultés rencontrées lors de l’intégration d’e-mails. Les extraits vidéos, les exemples de bugs incongrus et le ton décapant ont rendu un cauchemar extrêmement amusant ! Christophe Porteneuve quant à lui a survolé les bases du Javascript en Flash (le super-héros, pas la technologie pompée sur… Javascript). Je pense qu’il n’est pas humainement possible d’expliquer et vulgariser plus de choses en si peu de temps. L’humour, la concision et la précision, ainsi qu’une gestuelle impressionnante ont fait de cette conférence un exemple en la matière. À voir et à revoir !

Mention spéciale également à Julien Wajsberg et Anthony Ricaud dans « Code de qualité : ce qu’il faut savoir » qui ont parcouru le sujet avec une grande maturité, beaucoup d’humour et des anecdotes pertinentes tirées de leur travail sur Firefox OS.

Les histoires

Deux conférences sortaient du lot, non pas grâce à un regard différent sur le web ou à un niveau technique incroyable, mais parce qu’ils témoignaient d’une expérience de vie bien particulière. Et ces morceaux de vie étaient contés avec talent :

Stéphane Deschamps : « Le burnout et comment on lévite l’évite » ;
Billy Gregory : « Things I wish I knew when I started in Digital Accessibility ».

Un juste retour à la terre ferme, pour nous rappeler que les travailleurs du web sont des êtres humains avant tout.

Les informelles

Une tradition à Paris Web, les informelles sont des discussions qui se déroulent sur les mêmes créneaux que les conférences, mais dont les sujets sont proposés le jour-même par les spectateurs.

Cette année, j’ai ainsi pu participer à une informelle suggérée par Olivier Nourry : « Accessibilité, c’est quoi le problème ? ». Je ne m’étendrai pas sur son contenu puisqu’Olivier en a fait un compte-rendu sur son blog, en revanche quelle joie de rencontrer et discuter avec des pointures comme Monique Brunel, Johan Ramon, Sophie Schuermans, Aurélien Levy, Jean-Philippe Simonnet, et j’en oublie encore un certain nombre. C’était un échange précieux pour moi, car n’étant pas formé à l’accessibilité je subis régulièrement le syndrome de l’imposteur en la matière — et ce genre de discussion me permet de réaliser que même si je ne dispose pas de l’expertise, mon approche et mes idées sont loin d’être absurdes. Alors un grand merci à toutes les personnes qui ont participé à cette informelle, ça fait un bien fou !

Les ateliers

Les ateliers étaient eux aussi très intéressants, et un peu plus intimes que les conférences. Deux d’entre eux m’ont particulièrement plu :

Thomas Parisot nous a présenté une façon extrêmement ludique d’améliorer son algorithmie en Javacript (pour tout vous dire, je travaille encore dessus) : « Un peu de musique programmation d’ascenseur » ;
Delphine Malassingne et Rémi Parmentier nous ont mobilisés pour « Construire ensemble un enseignement du front-end pertinent, pédagogique et pérenne », afin de créer des fiches pratiques permettant à l’étudiant de se confronter à des obstacles et au formateur de s’outiller et d’évaluer plus simplement ses étudiants.

J’aimerais aussi partager un moment magique : la séparation. Quand il ne reste que le staff, obligé de mettre les quelques personnes (Monique Brunel, Delphine Malassingne, Jean-Philippe Simonnet, et bien d’autres encore) qui restent à la porte. Aurélien Levy qui part avec le reste de salade sous le coude, la mini-haie d’honneur lancée par Romy Duhem-Verdière et Goulven Champenois pour la sortie du staff, et la séparation au compte-goutte dans le métro…

Ces personnes sont des inspirations pour moi, des mentors qui s’ignorent peut-être. Partager ces quelques moments avec eux, je pense que c’est ça qui me donne autant de joie et de motivation après Paris Web. #sharethelove.

Le reste

Vous vous en doutez, je n’évoque ici que les moments qui m’ont réellement plu parmi ceux auxquels j’ai pu assister. Pour autant, les autres conférences et ateliers que j’ai suivis valent aussi le détour, et tout ceux que j’ai ratés également ! J’ai encore beaucoup de vidéos à regarder avant de rattraper ça, mais grâce à l’excellent staff de Paris Web, toutes les vidéos sont disponibles en ligne.

J’en profite pour féliciter le staff qui a encore fait des merveilles, et qui se défonce tellement pour apporter à nous autres passionnés du web un événement humain et de grande qualité.

Parmi les autres choses que je partagerai, les notes que j’ai prises lors des différentes conférences seront bientôt scannées et retranscrites sur le blog ! Un joli chantier en perspective mais ça me tient à cœur de montrer ce que j’ai pu saisir au vol 🙂

Fabrice Flipo, Michelle Dobrée et Marion Michot

Gaël Poupard — Fri, 23 May 2014 21:34:21 GMT

On ne peut attendre d’un outil qu’il modifie les comportements.

Mutisme relatif

Gaël Poupard — Sat, 17 May 2014 13:59:35 GMT

Voici un résumé de mes activités des derniers mois, ainsi que de mes projets pour cette année. Je souhaite seulement signaler que cette baisse de régime dans mes publications n’est que temporaire.

Les actualités

Le plan professionnel

Le principal événement qui s’est produit est mon changement d’employeur : je travaille désormais chez Kosmos, toujours à Nantes. C’est un travail d’un tout autre genre que celui que j’effectuais pour l’agence 1-ter-net puisque Kosmos est un éditeur de progiciel. Pour être plus précis je vais travailler sur le front-end de la solution K-d’école, afin d’en améliorer la qualité globale, l’accessibilité — et d’en faciliter la prise en main, la personnalisation et les évolutions futures.

J’apporte avec moi certaines compétences sur les aspects graphiques et ergonomiques qui participeront aussi à conserver un front-end et un look & feel homogènes pour renforcer l’identité de la solution.

Le plan personnel

Après mon travail sur La Nizanerie l’an passé — qui reste un projet vivant — j’ai aidé à mettre en ligne le site du Petit Marché Nature pour des amis. Ce fut plus un accompagnement qu’une création de site puisque nous nous sommes basés sur un thème Prestashop à peine revu.

J’ai également soutenu mon frère Luc Poupard (a.k.a KlohFR) à personnaliser mon thème ffeeeedd et à approfondir ses connaissances de WordPress, dans le cadre de son projet Continuum(s) mené avec son ami plasticien Olivier Vary (a.k.a Bendder). C’est également un projet enrichissant puisque Luc a permis de faire évoluer mon thème, son fonctionnement et certaines extensions et ainsi gagner en qualité et en souplesse.

Ce qui m’amène aux projets personnels qui m’occupent, depuis longtemps et a priori encore pour un bon moment.

Les projets

Les origines en 2013

Nous parlions du thème WordPress que j’ai développé depuis plus d’un an et demi maintenant : je continue, et je creuse toujours plus. Beaucoup de choses ont évoluées depuis ma première annonce, notamment sur un plan technique.

Je suis dans un premier temps passé aux thèmes enfants, dont le mécanisme est un réel bénéfice pour quiconque veut modifier un thème. Je m’étais conçu un processus de travail tout à fait personnel, en deux temps :

ffeeeedd–développement devait me permettre d’étendre facilement le thème parent, en ajoutant gabarits, scripts et styles directement ;
ffeeeedd–production était la version optimisée pour la production : scripts et styles concaténés et minifiés à la main, sprites et images optimisés, etc.

Ce mécanisme a très bien fonctionné pendant plusieurs mois, durant lesquels il a été utilisé sur plusieurs projets. Au fil du temps j’ai tout de même atteint certaines limites, et mes recherches m’ont amené deux réflexions parallèles :

certaines évolutions que j’ajoutais au thème enfant dépendait plutôt du « territoire des extensions » dans WordPress ;
mes procédures d’optimisation et de personnalisation des styles étaient lourdes et redondantes.

ffeeeedd–extensions

Ce qui m’a naturellement conduit à développer une flotille d’extensions afin de déporter certaines fonctionnalités vers des extensions, et d’en créer de nouvelles qui n’alourdiront pas inutilement le thème.

ffeeeedd–sass

Dans le même temps, j’ai complètement revu ma façon de travailler et me suis lentement mis à utiliser Sass, puis quelques portions de Compass. Je dis bien lentement puisque, comme je l’ai fait remarquer dans un article il y a quelques temps, j’ai tout fait pour éviter les pièges inhérents à ce type d’outils. Me faire gagner du temps, oui — mais sans perdre la qualité de mon travail.

J’abouti à ffeeeedd–sass, un thème enfant dont les styles s’appuient sur Sass, et ai utilisé PrePros pour homogénéiser facilement le traitement des scripts et des styles lors de leurs optimisations.

ffeeeedd–racine

Et pour parachever ce travail, un répertoire ffeeeedd–racine me permet de définir une configuration optimale de mon installation avec quelques légères modifications seulement.

Évidemment le thème enfant basé sur Sass embarque une version à jour de mon a11y.css — qui est à mon sens ma plus belle réussite pour 2013. Ce projet a fédéré quelques personnes, m’a permis d’apprendre énormément de choses sur l’accessibilité en m’astreignant à lire plusieurs référentiels en entier, et j’ai fait de belles rencontres en en discutant.

Voilà ce qui m’a occupé la majeure partie de l’année 2013. Et le meilleur cas pratique que vous pourrez rencontrer pour l’ensemble de ce travail est le site que vous lisez actuellement.

Et il se pourrait que vous entendiez à nouveau parler de tout ça avant la fin 2014 🙂

L’avenir

Honnêtement, je vais travailler. Beaucoup. Mon nouvel emploi va me demander beaucoup de temps, de lectures et de recherches pour mener ce travail de front !

Mais parmi les choses dont je suis sûr, c’est que je vais aller à Paris Web cette année encore mais aussi assister au tout frais WPTech qui va naître à Nantes fin 2014 — grâce à l’initiative de Willy Bahuaud et Daniel Roch.

Alors, on se voit quand pour discuter de tout ça ?

Clip-path, pourquoi pas ?

Gaël Poupard — Tue, 11 Mar 2014 16:44:26 GMT

Mais lorsque Kitty Giraudel a lancé son CSS brain teaser.^[1]

Les spécifications actuelles

Ne connaissant que de très loin cette propriété, il a fallu me mettre à jour. clip-path, à l’instar de clip, sert à délimiter la zone d’affichage d’un contenu. Je m’oriente vers les spécifications pour compléter cet embryon de culture — et là, c’est le drame :

La spécification de la propriété clip-path au sein du module CSS masking, encore à l’état de brouillon;
Qui nous renvoie aux formes basiques en SVG;
Tout cela en se référant sans arrêt à l’élément SVG ClipPath;
De fil en aiguille, citons également le module Masking de la spécification SVG — et notamment la section sur les Clipping paths.

On peut d’ores et déjà noter une différence remarquable entre les états de ces deux spécifications : l’une est en brouillon, l’autre en recommandation. La spécification SVG est extrêmement aboutie et claire, les ressources ne manquent pas.^[2]

En revanche le module CSS est obscur. Il existe un lien étroit entre les deux spécifications, car le brouillon du module CSS Masking s’appuie énormément sur la spécification SVG — et qu’en SVG il existe l’attribut clip-path. Ça génère des incompréhensions qui ne vont pas faciliter la prise en main de cette propriété.

Pour éclaircir un peu tout ça — et vous épargner la lecture des spécifications — vous devriez pouvoir écrire ceci pour utiliser une forme basique :


.clip { 
  clip-path: circle( 50%, 50%, 5em );
}

Mais ceci devrait fonctionner également — en appelant un élément SVG :


.clip { 
  clip-path: url(#circle);
}

Les origines

Il faut sonder un peu les origines de ce module CSS pour en comprendre l’obscurité. Bien que déjà en cours d’élaboration dans le cadre technique du SVG, la possibilité de masquer des éléments en CSS existait depuis CSS 2.1 grâce à la propriété clip, désormais dépréciée.^[3]

Cette propriété n’a jamais réellement trouvé son public, car elle a deux inconvénients majeurs :

L’élément masqué doit être en position absolue;
Le masque ne peut être que rectangulaire, et son placement est contre-intuitif.

Embêtant. Constatant les progrès possibles de cette fonctionnalité en CSS, c’est le navigateur Safari qui a ouvert les hostilités en 2008 avec les propriétés -webkit-mask-… supportées dès Safari 4. Cette technique a rencontré un franc succès car elle permet d’utiliser une image comme masque. Malheureusement cette propriété n’était supportée que par le moteur de rendu Webkit.^[4]

Là, j’ai vu poindre le problème : la spécification CSS en cours d’élaboration mélange joyeusement les clips issus de SVG et la proposition de Safari.^[5]

Des ressources dissonantes

Il est fort peu probable que personne avant moi ne s’y soit intéressé. Et en effet, quatre ressources principales sont indispensables pour appréhender clip-path :

CSS Masking sur HTML5Rocks;
L’article dédié sur Web Platform Docs;
Un tutoriel avancé sur The Nitty Gritty;
L’article de l’Avent par Vincent De Oliveira sur 24 jours de web;

Comme vous vous en apercevrez en les lisant, le contenu est disparate. La compatibilité navigateur est abordée différemment.^[6]

À l’instar de la spécification qui intègre les clips et les masques, ces ressources présentent les deux techniques. Dommage car deux articles distincts auraient été bien plus clairs !

Un bilan mitigé

Après avoir compulsé maladivement les spécifications, articles, tutoriaux et autres exemples pendant quelques jours, j’ai abouti à un exemple ressemblant à ceci :


/**
 * 1. Définition d’une forme rectangulaire de repli pour les navigateurs ne supportant pas clip-path;
 * 2. Création d’une forme SVG basique, circulaire;
 * 3. Appel d’un fichier SVG contenant un élément clipPath. 
 */
.clip { 
  clip: rect( 7em, 30em, 17em, 20em ); /* 1 */
  -webkit-clip-path: circle( 50%, 50%, 5em ); /* 2 */
  clip-path: url(#circle); /* 3 */
}

Évidemment, cela implique un balisage précis côté HTML :


<p class="clip">
  ♬ Tout, tout, tout : vous saurez tout sur le clip-path ♬
</p>
<svg width="200" height="200">
  <defs>
  <clipPath id="circle">
  <circle cx="50%" cy="50%" r="80" />
  </clipPath>  
  </defs>
</svg>

Ainsi je tente de vous livrer un état des lieux aussi complet que possible.^[7]

Chrome 23, Safari 6.1 et Opéra 15 supportent clip-path sous toutes ses formes — incluant la définition de formes SVG basiques dans le CSS;
Firefox 4 supporte clip-path si on référence un élément SVG clipPath — ce qui implique d’ajouter un fichier SVG — en revanche vous serez obligés de définir des positions en unités absolues comme le px pour positionner votre clip si vous souhaitez éviter les bugs, et c’est bien dommage;
Opéra 7, Chrome 14, IE8 à 11 et Safari 1 se replient sur clip;
Une note sur IE9 à 11 : ces navigateurs supportent clip-path si on référence un élément SVG clipPath, à condition d’appliquer le clip sur un élément SVG. Il est envisageable d’intégrer la zone à clipper dans un élément ForeignObject au sein d’un SVG, mais ça devient trop tordu à mon goût;
Un mot sur IE4 à 7 : surpris vous êtes ? Ne le soyez pas, clip est reconnu sur IE4 à 7 (et même Netscape 4). Le hic, ce sont les pseudo-éléments que j’emploie dans mon exemple; ainsi en ajoutant un élément dédié dans le DOM, vous devriez pouvoir supporter IE4 facilement 😀 .

Une solution correcte

Malgré le support disparate et le funambulisme nécessaire pour aboutir à un résultat viable, j’ai trouvé clip-path extrêmement intéressant — et notamment grâce à la dégradation possible à l’aide de clip sur de très vieux navigateurs et de façon simplissime.

Ce repli implique de perdre les formes personnalisées au profit d’un rectangle « simple », ce qui fut considéré comme acceptable lors de l’avènement de border-radius par exemple. Et je suppose que dans la plupart des cas, cette solution reste acceptable.

Vous trouverez donc ma solution au casse-tête proposé par Kitty sur CodePen, détaillée, commentée, agrémentée de diverses précisions — en Anglais.

Tout retour sera le bienvenu 🙂 .

Mise à jour

Moins d’une semaine avant la publication de mon article, le brouillon du W3C concernant la notation des formes basiques a évolué. Je cite Vincent De Oliveira, qui a partagé l’information avec moi :

Par contre, la notation des basic-shapes ont (encore) changées récemment! 😛 dev.w3.org

Ô joie. Merci à Vincent en tout cas !

Papa, Maman : j’aime les casses-têtes. ↩︎
Un petit « cocorico » s’impose pour féliciter Jérémie Patonnier, qui a grandement contribué à la documentation sur le Mozilla Developper Network notamment. ↩︎
La propriété est dépréciée mais très bien supportée, et le W3C indique que les agents utilisateurs (navigateurs web) doivent la supporter malgré sa déprécation. ↩︎
Je ne compte pas traiter du marronnier de « la guerre des navigateurs » ni du syndrome « Webkit only ». ↩︎
Fabriqué par Apple® en Californie. ↩︎
La palme revient à HTML5Rocks qui détaille Chrome et Firefox, et oublie les autres. ↩︎
Je tiens à préciser que je n’ai aucune expertise en la matière : ce ne sont la que les conclusions trouvées par un intégrateur lambda. ↩︎

Réflexion sur Sass

Gaël Poupard — Mon, 10 Mar 2014 13:00:58 GMT

Un outil est fait pour faciliter le travail — pas pour en améliorer la qualité.

La qualité web en solitaire

Gaël Poupard — Thu, 27 Feb 2014 16:56:32 GMT

Très souvent sur le web — et au travail, je croise ce type de propos tenus par des professionnels du web :

Valider le code n’est pas important, du moment que « ça » fonctionne;
L’accessibilité, c’est du travail supplémentaire;
Si ça n’est pas vendu, ça nous coûte de l’argent;
L’accessibilité ? Pour deux péquins par an ?
Le client n’en veut pas.^[1]

Mais même cerné par cet état d’esprit, je me sens concerné et je tends toujours plus vers la qualité et l’accessibilité — seul. J’ai conscience de mon immaturité dans le domaine, mais sans faire les premiers pas et me faire remonter les bretelles de temps en temps, comment apprendrai-je ?

Pré-requis : Cet article étant légèrement impulsif, je tiens à préciser qu’à mon sens l’accessibilité fait partie intégrante de la qualité web — pour limiter les confusions dans mon propos.

Un état des lieux éloquent

Je ne pense pas forcer le trait, tant les remarques précédemment listées sont légions sur les forums comme Alsacréations. Nicolas Hoffmann a lui aussi rédigé sa petite liste d’âneries. De nombreux professionnels reconnus ont réagi à ce sujet il y a un peu moins d’un an, alors que QuentinC relativisait la joie de fêter les 10 ans du forum Alsacréations.^[2]

L’accessibilité, peut-on s’en foutre parce que ça coûte ? — Olivier Nourry
L’accessibilité, on s’en fout de plus en plus ? — Sophie Drouvroy
Défaitisme et accessibilité — Stéphane Deschamps
L’accessibilité, on s’en fout de plus en plus ? Moi, non. — Nicolas Hoffmann

J’en oublie évidemment de nombreux. J’ai cependant la vilaine impression que plus l’auteur est reconnu en tant qu’expert, plus l’impact du discours est réduit en conséquence. J’ai déjà entendu cette remarque :

C’est facile d’aborder l’accessibilité de cette manière quand on est expert et qu’on a les moyens de la mettre en œuvre — mais ça ne peut pas me concerner, moi et mon petit site.

Une approche personnelle

Malgré ce contexte compliqué, je reste intimement persuadé qu’il est possible pour tout professionnel du web de produire un travail accessible et de qualité.

Il suffit de se dire que la qualité web n’est pas une valeur ajoutée mais une valeur intrinsèque. Elle n’est pas optionnelle, mais « de série ». Elle ne constitue pas une ligne supplémentaire sur le devis, dont le client comprendra qu’il peut la faire retirer pour alléger le tarif.

Des pratiques extrêmement simples peuvent considérablement améliorer la qualité et l’accessibilité de vos productions :

Utilisez des solutions éprouvées, déjà accessibles;
Documentez votre code de façon complète : citez vos sources, précisez à quoi ça sert, quels éléments contextuels peuvent influer…
Instaurez des checklists qualités — comme celles proposées par OpQuast ou suggerées par Corinne Schillinger — et faites les premiers pas dans cette démarche qualité;
Créez vos propres outils et capitalisez dessus : intégrez-y les solutions choisies et les documentations;
Contre-pillez tous vos projets spécifiques afin de pouvoir recycler chacun de vos travaux spécifiques;
Partagez vos ressources, mettez-les en commun.^[3]

Demandez conseil à des gens compétents : vous allez être surpris par la bienveillance et la disponibilité de la plupart d’entre eux.^[4]

Apprenez à échanger et instruire de façon constructive et positive : « Les petits ruisseaux font les grandes rivières » — Luc Poupard.

Peut-être pourrais-je trouver d’autres façons d’encore améliorer mon travail — et je suis tout ouï si vous voulez bien m’en suggérer. Mais celles que j’applique actuellement ne sont qu’une question de discipline, et sont donc à la portée de tout un chacun.

« Mon client ne veut pas payer pour de la qualité »

C’est l’argument le plus répandu. Personnellement, je comprends votre client : ça ne devrait pas être payant ! Vous imaginez, vous, débarquer dans un garage et vous entendre dire :

Ha non, si vous voulez une voiture qui roule il faut payer plus…

Bien sûr que non : ça va de soi.

Quand un client paie son site web, il va de soi qu’il doit être de qualité. Il paie des professionnels, tout de même.^[5]

— Vous voulez que votre site soit accessible ?
— C’est quoi, accessible ?
— C’est compliqué techniquement (et donc très cher) et ça aide environ deux personnes par an.

Surpris je suis que refusé votre client ai.

Donc chers professionnels du web, confrères, collègues, jeunes et anciens : arrêtez ce délire paranoïaque. Faites votre travail, et faites-le bien.

Même si cela ne vous est pas demandé.

Même si lorsque vous le suggérez, on vous rit au nez.

Même si vous êtes le seul de votre équipe à vous en soucier.

Même si vous ne pensez pas en être capable.

Même si vous savez que personne ne prendra le relais.

Même si vous n’en tirez aucune reconnaissance.

Faites-le

J’en profite pour remercier Muriel de Dona dont l’échange gratifiant sur Twitter a généré cette envie d’écrire — et je fais un peu de publicité supplémentaire pour son travail chez OpQuast (notamment la rédaction du livre « Qualité web » et des fameuses bonnes pratiques). Cette initiative est absolument indispensable et je tiens à signaler les progrès considérables que j’ai fait grâce à eux 🙂

Celle-ci, c’est ma préférée ! ↩︎
Ce qui m’évoque la capacité des gens à se réjouir de l’augmentation des dons aux Restos du Cœur chaque année — oubliant trop facilement que c’est un symbole négatif du besoin croissant et urgent. On se réjouira le jour ou on pourra se passer des Restos du Cœur. Et puisque j’en suis là : allez faire un don sur le site dédiés : dons.restosducoeur.org . Merci à vous ! ↩︎
GitHub est magique : mon a11y.css a beaucoup évolué grâce aux participations de Guillaume Demesy, Xavier Zalawa et Luc Poupard. ↩︎
Petite pensée et gros remerciements pour Johan Ramon, Monique Brunel, Victor Brito, Willy Bahuaud, Julio Potier, Kitty Giraudel — et j’en passe de nombreux. ↩︎
Au lieu de faire travailler le cousin de son neveu après les cours. ↩︎

a11y.css : un crédo

Gaël Poupard — Wed, 04 Dec 2013 17:43:09 GMT

a11y.css .^[1]

Les références

Les projets reposant sur CSS

Le premier projet de ce type que j’ai rencontré est Holmes.css. L’idée m’a rapidement séduit. Des projets similaires ont fleuri, dont :

Diagnostic.css par Karl Groves ;
Debug-css par Seth Warburton.

La découverte d’OpQuast et des bonnes pratiques ayant accentué mon exigence, les outils précédemment cités m’ont semblé un peu légers.

Les checklists

Définir des « checklists qualités » est également une bonne idée, et les exemples lus dans « Intégration web, les bonnes pratiques » de Corinne Schillinger ou dans le projet Outline de Vincent Valentin m’ont persuadé de tenter cette solution. Cependant, c’est plus contraignant que les solutions de repérage en CSS, et légèrement différent puisqu’une solution CSS ne permettra pas d’évaluer la pertinence des textes ou solutions techniques. Les checklists sont également rapidement contextuelles à un projet, puisque les objectifs et contraintes peuvent varier — je cherchais plutôt un outil générique.

Les solutions en ligne

Les solutions automatisées en ligne sont également très utiles, mais ne permettent pas de faire un suivi au fil de l’eau. Je m’en sers lorsque je touche au but, à savoir en préambule à une recette complète. Voici une liste de ceux que j’affectionne particulièrement :

Mais à moins que vous ne soyez fan des allers-retours, ces services ne sont pas adaptés à une utilisation intensive.

Une organisation lisible

J’ai donc travaillé sur ce fichier CSS pendant un moment, égrainant les règles à tester, les façons d’afficher le message, etc. Mon récent apprentissage de Sass m’a permis d’organiser beaucoup plus précisément ce fichier, en définissant quatre degrés de gravité :

Les erreurs, dénoncées en rouge : principalement des attributs absents, vides ou très fortement déconseillés ;
Les alertes, signalées en jaune : notamment les éléments vides, les imbrications douteuses et les attributs sensibles ;
Les éléments & attributs obsolètes, marqués en gris et relevés d’après la liste maintenue par le W3C ;
Les conseils, mentionnés en vert. Il s’agit de simples suggestions d’utilisation de certains attributs, ou de bonnes pratiques méconnues.

L’organisation du projet est simple : la feuille de style « reine » contient un mixin, quelques explications et des placeholders pour chaque degré de gravité. Des fichiers partiels sont importés en deux groupes : un pour les sélecteurs — pour la maintenabilité, c’est bien plus lisible ainsi — et un pour les messages eux-mêmes.

Une cible précise

Comme vous vous en doutez, cet outil n’est destiné qu’aux intégrateurs soucieux de la qualité de leur production. C’est pourquoi la compatibilité des sélecteurs et de l’affichage des messages ne prend pas en compte IE8 :D.

De plus, les messages sont affichés via un pseudo-élément ::after — et vous le savez sûrement, mais les contenus générés via des pseudos-éléments ne sont pas du contenu.

Et pour que ça ne me gratte pas trop la rétine, j’ai également ajouté un effet de transition pour l’apparition du message.

La documentation

Reste une question à se poser : comment ai-je choisi les tests à effectuer, les formulations des messages et leur degré de gravité respectif ?

Pour faire simple, j’ai lu. Beaucoup. Les premières ressources ont été les projets similaires déjà cités, bien sûr. Puis je me suis inspiré des indications récurrentes obtenues sur Tanaguru ou OpQuast Reporting. La page du W3C listant les éléments obsolètes s’est imposée d’elle-même en tant que ressource complète pour un degré bien précis de vérification.

Et finalement, le forum de discussion du référentiel AccessiWeb pour sa version 2.2 ( sous-titré « Mesure de la conformité WCAG 2.0 via le référentiel AccessiWeb 2.2 avec HTML5/ARIA » ) que m’avait précédemment indiqué Johan Ramon m’a appris énormément.

Car oui : j’ai tout lu, tout détaillé. Pour chaque critère j’ai essayé d’en saisir le sens, les implications techniques et fonctionnelles, mais aussi ma capacité à les vérifier en CSS. C’est pourquoi les fichiers .scss sont plutôt bien documentés : chaque test indique, via un commentaire, le critère Accessiweb et/ou la bonne pratique OpQuast concerné(es).

Les tests susceptibles d’évoluer ou dont la vérification en CSS m’a semblé discutable ont été soit retirés, soit inclus aux conseils avec la mention utile concernant le contexte de rédaction du test en question.

Une capitalisation indispensable

Voilà, vous savez tout. J’estime ce projet suffisamment mûr pour être soumis aux regards de tous, en espérant que ceux-là me permettront d’enrichir encore cet outil qui m’aide déjà beaucoup.

J’ai peu détaillé l’origine concrète de ce projet et comment il est né d’un réel besoin. Il faut savoir que dans mon travail, je ne maîtrise pas toujours l’environnement de la phase d’intégration. Lorsqu’un nouveau projet est lancé, il peut parfois m’être imposé un thème ( sur WordPress ) ou une solution ( Prestashop, si tu nous regardes ) ; et lorsqu’il s’agit d’une maintenance ou d’une refonte partielle, je ne vous raconte pas ce que je déterre parfois…

C’est dans ce cadre qu’a11y.css prend tout son sens. Car si vous maîtrisez parfaitement la chaîne de production, il ne pourra vous servir que de pense-bête ( car vous aurez déjà appliqué toutes les bonnes pratiques, n’est-ce pas ? ), surtout si vous automatisez ce type de tâches grâce à Grunt ou d’autres outils du même acabit.

Alors, qu’en dites-vous ?

a11y est la contraction de « Accessibility » : un « a » suivi de 11 caractères, et conclu par un « y ». ↩︎

Sass : commencez par les deux « S »

Gaël Poupard — Thu, 28 Nov 2013 15:26:04 GMT

Malheureusement, vous aurez peut-être déjà fait ce constat : ce réflexe n’est que trop rarement encouragé. J’ai beau parcourir des dizaines d’articles, de tutoriaux, de frameworks CSS ou de Gist, trop peu font ce rappel : testez, relisez, améliorez, testez à nouveau et finalement améliorez encore. Ça devrait se passer comme ça. On peut argumenter qu’un bon intégrateur le ferait — mais c’est trop facile, non ?

Premier contact avec Sass

Après avoir lu énormément de ressources sur Less puis Sass pendant longtemps, je ne m’étais toujours pas décidé à franchir le pas pour plusieurs raisons :

le changement bien sûr : rien de plus naturel que la résistance au changement;
la perspective d’une « naturalisation » des avancées intéressantes dans les évolutions prévues de CSS .^[1]

l’intérêt limité — ou imitable — de certaines fonctionnalités .^[2]

Dans l’ensemble, je pensais — et je pense toujours — que l’utilisation de Sass n’avait pas d’intérêt à mon échelle : petits projets, récupération de code, très peu de collaboration… J’y percevais plus de risques et d’inconvénients que d’avantages, et certaines de mes lectures le confirmaient.

L’évolution de mon projet personnel ffeeeedd conjointe à la lecture de l’excellent CSS maintenables puis de Sass & Compass avancé m’ont finalement motivé : bien qu’à l’aise avec mon workflow, je voulais l’améliorer et Sass m’a semblé être l’outil idéal.

Découvertes particulières

J’y suis allé pas à pas, dans l’ordre de la documentation. Des règles imbriquées aux fonctions, j’ai pris un temps considérable et me suis consciencieusement appliqué à découvrir le résultat de chacune des fonctionnalités .^[3]

La définition de variables — et par extension, la structuration d’un projet — est un gain de clarté évident. La compilation automatique est un gain de temps remarquable, et la qualité est au rendez-vous. Les fonctions, mixins et autres boucles sont extrêmement intéressantes, mais on touche aussi aux limites de l’outil : il faut de très, très bonnes bases en CSS pour s’en servir de façon optimale.

Étendre une classe est un piège parfait, probablement le plus efficient en tant que piège ; les nombreuses subtilités des fonctions et mixins peuvent également générer des erreurs très discrètement — et elles peuvent donc rester, pour peu que l’utilisateur ne soit pas consciencieux.

Je ne gâcherais pourtant pas mon plaisir : créer des mixins, fonctions et placeholders pour factoriser mes feuilles de styles « sources » est terriblement agréable 😀 .

Une simplification, vraiment ?

Je suis encore en phase de découverte et pourtant me voilà sur ma faim : beaucoup de choses sont considérablement simplifiées, mais je garde l’impression que la complexité « d’avant » est simplement déportée vers les fonctionnalités dynamiques .^[4]

La distance « cognitive » entre les fonctions/mixins et leur contexte d’utilisation, ainsi que la séparation des feuilles de styles en fragments .^[5]

Sass n’est qu’un outil

Vous connaissez le dicton :

Il n’y a pas de mauvais outil, il n’y a que de mauvais ouvriers.

Et bien elle se vérifie avec Sass. Ce qui ne me convainquait pas l’an dernier ne me convainc toujours pas : les articles vantant les mérites des pré-processeurs sont relativement évasifs, et l’élan massif vers l’adoption de Sass me fait penser au crime passionnel au pays des Toupoutous.

Oui, Sass est un outil formidable qui peut grandement faciliter et accélerer votre travail d’intégration ; oui, les possibilités semblent infinies ; oui, son utilisation est plutôt simple…

Mais n’oublions que Sass reste un outil, et en tant que tel sa vocation est seulement de faciliter votre travail et pas d’en améliorer la qualité. Ce n’est pas le marteau qui fait en sorte que le clou rentre droit, c’est votre geste.

Les calculs simples sont déjà là grâce à calc(), les variables sont à l’état de brouillon au W3C, etc. ↩︎
Les placeholders, par exemple, sont limités puisqu’on peut créer ses propres classes transportables et modulables. ↩︎
Soit dit en passant, je préfère ne pas passer à Compass tout de suite, je pense devoir manier Sass correctement avant d’ajouter un autre crayon à ma palette. ↩︎
Compass me semble d’ailleurs être un écueil remarquable pour le débutant, qui ne comprendra pas en profondeur le fonctionnement et la portée des mixins et fonctions proposées. ↩︎
Des « partials » dans le vocabulaire Sass ↩︎

Sass & Compass avancé

Gaël Poupard — Wed, 20 Nov 2013 18:17:48 GMT

En tant qu’intégrateur avec un peu d’expérience — mais débutant avec Sass et Compass — les explications et retours d’expérience de Mehdi Kabab ( a.k.a @piouPiouM ) sont forcément intéressants. Au-delà de la présentation de l’outil, de nombreuses informations et bonnes pratiques viennent enrichir un livre déjà complet.

Le tour du propriétaire

Évidemment, l’étape inéluctable est l’introduction à Sass : ces principes généraux, son installation, son fonctionnement, et le détail de sa syntaxe. Une présentation complète, sans détour et extrêmement claire qui m’a permis de compléter ce que j’avais observé et appris lors de mon premier contact avec Sass. Cette partie est vraiment intéressante puisque l’auteur ne se limite pas à expliciter la documentation officielle mais en profite pour évoquer les pièges à éviter, les dérives les plus courantes et — pour résumer — tout ce qui fait de Sass une arme à double-tranchants.

Le chapitre suivant aborde l’angle du développement dans Sass .^[1]

Les mains dans le cambouis

Découvrir un outil c’est bien joli, apprendre à l’utiliser c’est mieux ! L’auteur pose les bases d’un projet, et j’ai beaucoup apprécié dans cette partie **les exemples concrets évoqués qui simplifiaient certains points relativement compliqués .^[2]

La présentation de Compass est plutôt complète aussi, mais un peu moins aguicheuse : cela vient probablement du fait que je ne sois pas encore réellement convaincu par l’intérêt de ce framework. Le support navigateur très lourd, la multitude de mixins existants, la gestion des sprites en PNG seulement : tout ça rend Compass légèrement décevant à mes yeux. Ce n’est que partie remise, il est probable qu’une utilisation régulière lui rende justice :).

Une méthodologie mature

La partie la plus intéressante à mon avis est celle qui traite de la méthodologie :

la gestion des versions de Sass et Compass
le débogage
la collaboration

C’est là que l’expérience de l’auteur se fait réellement sentir. Il est néanmoins difficile de se projeter dans cette méthodologie — en tout cas, pour moi — car elle est extrêmement précise .^[3]

Des annexes pas si annexes que ça

Ces annexes sont presque indispensables :

maintenir un casseur de cache personnalisé,
partager des fichiers entre plusieurs projets,
survivre en ligne de commande…

Une portion cependant fait ressortir un tic de l’auteur : il fait de la bonne publicité pour Apple® :D.

Un livre à relire, plus tard

Beaucoup de choses n’ont pas pris de sens dans ma cervelle dérangée : une certaine confusion persiste, ce qui explique que ma note ne soit pas maximale .^[4]

J’ai l’impression que ce livre vise un public très spécifique : les pré-requis sont réels .^[5]

Je suis légèrement mitigé sur ma première lecture, mais je crois que lors de ma relecture cet ouvrage me deviendra indispensable. Il revêt d’ores et déjà le rôle d’ouvrage de référence dans ma bibliothèque et je compte bien l’ouvrir souvent !

Oui, quand nous manipulons des données, tripotons des variables et jouons avec des fonctions, nous faisons du développement ! ↩︎
Même si l’utilisation de Sass et Compass ne nécessite pas d’être ingénieur, il faut avouer que ça n’est pas spécialement intuitif non plus ! ↩︎
La collaboration n’est pas le fort de l’agence, puisque je travaille seul la plupart du temps. ↩︎
je pense qu’une utilisation plus régulière de Sass et Compass est nécessaire pour réellement saisir tout ce qui est dit dans cet ouvrage. ↩︎
Il faut être intégrateur de métier, et avec un peu de bouteille si possible. ↩︎

[caption] avec html5 et aria

Gaël Poupard — Tue, 12 Nov 2013 17:32:51 GMT

Pour commencer, il faut comprendre une problématique de base en terme d’accessibilité : la distinction entre les images décoratives et les images porteuses de sens. Pour comprendre cette distinction et son importance, je vous recommande vivement la lecture d’«Accessibilité web» par Armony Altinier. Comme souvent lorsque nous parlons d’accessibilité web, il s’agit de bon sens : une image porteuse de sens doit être restituée à tous les utilisateurs, tandis qu’une image décorative ne doit être montrée qu’aux utilisateurs disposant d’un affichage graphique complet.

Les limites de WordPress

Tout le monde n’est pas sensible à ces questions, même s’il le faudrait : WordPress ne fait pas exception. Il donne cependant la possibilité à ses utilisateurs de servir des images de façon tout à fait correcte, en proposant de base pour tous les fichiers la capacité d’adjoindre un texte alternatif — ce qui remplit le critère principal des bonnes pratiques d’OpQuast et permet de satisfaire la plupart des critères de niveau Bronze d’Accessiweb.

Pour autant WordPress ne va pas plus loin :

Dans le cas d’une image décorative, il l’ajoute dans une balise <img /> et conserve l’attribut alt vide s’il n’est pas renseigné. C’est une bonne façon de procéder, car l’image n’est pas vocalisée par un lecteur d’écran et n’a aucun poids sémantique.
Dans le cas d’une image qui véhicule une information ( ce que je suppose être le cas si la légende est renseignée ), il encadre cette image d’une <div> et y intègre la description dans un <p> ( cf : le code source du shortcode ). C’est problématique car il n’existe aucun lien sémantique entre l’image et sa description, et le balisage est neutre.

Certes, c’est du fignolage. Mais c’est à priori dans les détails que l’on améliore sensiblement la qualité d’un site web.

Les images porteuses de sens

Le cas des images véhiculant des informations demande donc quelques efforts : il faut intercepter le shortcode afin de le ré-interpréter avant qu’il ne soit renvoyé côté client. Voici ce à quoi j’ai pu aboutir :

  /* == @section Remplace le code généré par [caption] ==================== */
  /**
 * @note : Le contenu est filtré pour remplacer le html généré pour les caption par du html5 sémantique. Astuce trouvée sur Reverie.
 * @author : Zhen Huang
 * @see : https://themefortress.com/reverie/
 * @see : https://github.com/milohuang/reverie/blob/master/lib/clean.php#LC151
 * @note : On y ajoute les microdonnées qui vont bien.
 * @author : Joost Kiens ( @joostkiens )
 * @see : https://gist.github.com/JoostKiens/4477366
 * @note : Et j’y ajoute les roles et attributs Aria nécessaires
 * @see : https://www.kloh.ch/craw2013-html5-aria-et-accessibilite-web-479
 */
  add_filter( ’img_caption_shortcode’, ’ffeeeedd__caption’, 10, 3 );
  function ffeeeedd__caption( $output, $attr, $content ) {
  if ( is_feed() ) {
  return $output;
  }
  $defaults = array(
  ’id’ => ’’,
  ’align’ => ’alignnone’,
  ’width’ => ’’,
  ’caption’ => ’’
  );
  $attr = shortcode_atts( $defaults, $attr );
  if ( 1 > (int) $attr[’width’] || empty( $attr[’caption’] ) ) {
  return $content;
  }
  $content = str_replace( ’<img’, ’<img id="’ . $attr[’id’] . ’" itemprop="contentURL" aria-describedby="wp-caption--’ . $attr[’id’] . ’"’, $content );
  $attributes = ’ class="wp-caption inbl ’ . esc_attr( $attr[’align’] ) . ’"’;
  $output = ’<figure’ . $attributes .’ role="group" itemscope itemtype="https://schema.org/ImageObject">’;
  $output .= do_shortcode( $content );
  $output .= ’<figcaption class="wp-caption-text pt1 small" id="wp-caption--’ . $attr[’id’] . ’" itemprop="description">’ . $attr[’caption’] . ’</figcaption>’;
  $output .= ’</figure>’;
  return $output;
  }

L’intervention détaillée

La structure d’origine est conservée ; je détaille ce qui a été fait :

Une couche sémantique HTML5 est appliquée en lieu et place du balisage «neutre» précédent : figure et figcaption ;
Une couche ARIA améliore la compréhension de ce balisage parfois défaillant dans les technologies d’assistance, comme me l’a appris le compte-rendu d’un atelier de Jean-Pierre Vilain à la CRAW2013 rédigé par Luc. Dans notre cas, le role="group".^[1]

Et finalement une dernière couche est ajoutée : les micro-données.^[2]

Ce code n’est probablement pas parfait, car je ne l’ai pas testé avec un lecteur d’écran : il va falloir que je le fasse. Mais je pense que c’est un premier pas en avant vers une meilleure qualité des sites WordPress que je produis.

Les commentaires, conseils et indications supplémentaires seront grandement appréciés :) .

Mises à jour

Suite à un bref échange avec Johan Ramon, je dois préciser un point important : l’alternative textuelle de l’image doit également mentionner la légende attenante, pour les technologies d’assistance qui ne prendraient pas en compte l’attribut aria-describedby. Voici les ressources utiles

Discussion sur le critère 1.10 d’AccessiWeb 2.2
Support des attributs ARIA par les lecteurs d’écran

Comme souvent, cette dernière contrainte repose entièrement sur le contributeur qui doit être informé et éduqué à cette responsabilité.

En savoir plus sur le rôle «group» : https://developer.mozilla.org/en-US/docs/Accessibility/ARIA/ARIA_Techniques/Using_the_group_role ↩︎
Découvrir les micro-données pour enrichir les objets images : https://schema.org/ImageObject ↩︎

Karl Groves

Gaël Poupard — Sun, 10 Nov 2013 20:22:24 GMT

If it looks the same, it should act the same.

Guide pratique de choix typographique

Gaël Poupard — Sat, 09 Nov 2013 17:50:57 GMT

L’origine du livre est un constat simple de David Rault : ce livre manquait. Et après l’avoir lu, je dois avouer qu’aucun ouvrage que j’ai parcouru n’y ressemble.

Une histoire de familles

Ne s’adressant pas uniquement à des techniciens ou à des professionnels — mais plutôt à des étudiants en arts graphiques — ce livre commence par les fondations : la classification des caractères, et plus précisément la classification Vox-Atypi.

Une introduction riche nous dépeint les origines de cette classification, les différentes familles et leurs connotations génériques ainsi qu’un lexique plutôt complet. Bien qu’ayant lu un certain nombre de livres traitant du sujet (notamment «Le Livre en Lettres» de Stéphane Darricau ou encore «Comprendre la typographie» d’Ellen Lupton), la concision et la clarté de celui-ci m’ont beaucoup plu.

27 caractères scrutés

Un choix forcément partial mais néanmoins représentatif a été fait : vingt-sept caractères majeurs dans l’histoire de la typographie ont été sélectionnés et décortiqués pour en saisir les moindres nuances.

Un angle d’attaque judicieux puisqu’en quelques pages seulement, l’analyse d’un seul caractère permet à l’auteur de nous raconter un pan entier de cette histoire : comment son concepteur est devenu typographe, dans quel contexte historique mais également pourquoi ce caractère précis est devenu un classique.

Les anecdotes entrecoupées des Baskerville, Garamond et autre Trajan son réellement passionnantes 😀 .

Une qualification efficace

Hormis la qualité culturelle de cet ouvrage, l’objectif de l’auteur était clair : permettre à ses lecteurs de comprendre l’impact d’une typographie, et de la choisir à bon escient. Il y parvient d’une manière remarquablement simple, puisque chaque caractère étudié fait l’objet d’une qualification complète. Douceur, robustesse, raideur, chaleur, féminité, convivialité… Chaque caractère est profilé de la même façon qu’un article de blog est catégorisé.

La simplicité de ce livre se résume assez bien à la fin : deux diagrammes placent les vingt-sept caractères étudiés en fonction de leur connotation, et le résultat est évident.

Pour tous les curieux caractères

Vous l’aurez compris, la lecture de ce livre m’a beaucoup plue : moins pointu que les best-sellers du genre, il est agréable et convivial.

Je le recommande chaudement !

Étymologie du web

Gaël Poupard — Mon, 04 Nov 2013 18:32:27 GMT

Je m’étais déjà fait cette réflexion en lisant Webgrids, dans lequel Anne-Sophie Fradier m’apprenait l’origine du mot scroll, qui signifiait simplement l’action de dérouler un parchemin. Mais mes vacances à Jersey m’ont appris bien plus encore.

Le vocabulaire web

À l’instar de scroll, de nombreux termes proviennent du langage courant en anglais :

framework signifie «coffrage», dans la construction — ce que j’ai appris en visitant un mémorial sur la seconde guerre mondiale, dans lequel était expliqué le labeur des ouvriers qui bâtissaient des murs en bétons à l’aide de «wooden frameworks»;
web signifie une «toile» (sous-entendu : d’araignée) qui est probablement l’anecdote la plus célèbre du monde;
tag est un vieux mot pour «étiquette» (l’objet étiquette, mais aussi l’étiquette dans le sens comportemental : la bienséance);
etc…

Cette liste pourrait continuer très longtemps : j’ai réalisé que — probablement dans un souci de compréhensibilité — les éléments HTML sont tous des représentations d’éléments existants dans le monde réel. C’est ce que nous appelons la sémantique, mais il faut noter qu’aucun terme n’a été créé spécifiquement pour le web : ils ne sont que des métaphores.

Les éléments HTML

On retrouve cette inspiration dans les balises classiques. La plupart tirent leur origine de l’imprimerie traditionnelle et de la mise en page, mais certaines sont plus amusantes :

Les boutons radio inspirés des radios et autoradios;
L’élément canvas dont l’origine vient de la tapisserie et de la broderie, ce qui est plutôt rigolo.

Bien qu’amusant, ce sont des choses relativement connues (et évidentes dans l’univers anglophone) mais que j’ai réalisées petit à petit, au fil de ma progression et de mes pérégrinations professionnelles.

Mais il reste un domaine concret moins évident à appréhender et tout aussi inspiré du monde physique.

Les interactions

Troublante ressemblance avec le verrou de l’iPhone

Vous allez rire, mais c’est en allant aux toilettes dans le camping qui m’hébergeait que la révélation a eu lieu : pour fermer la porte, une simple glissière légendée «Slide». Est-ce que ça vous rappelle quelque chose :D ? J’en ai fait un croquis rapide, en guise d’illustration.

J’ai alors réalisé que cette interaction qui nous a semblé innovante — à nous autres Français — est en fait une interaction tout à fait basique dans le monde anglo-saxon – et c’est de là qu’elle tire son affordance .^[1]

D’où ma réflexion : le web est issu du monde anglo-saxon, et la majorité de son écosystème a du sens — pour un anglophone ou quelqu’un baignant dans la culture anglo-saxonne.

Une transposition culturelle ?

Je n’ai pas de conclusion à apporter mais plutôt une suggestion d’ouverture. L’interaction pour déverrouiller un smartphone Apple n’a pas beaucoup de sens pour nous : peut-être qu’une interaction simulant le geste d’utiliser une clef pour fermer une porte à double-tour serait plus évocateur ? Poser deux doigts et dessiner un cercle avec, deux ou trois fois d’affilée : c’est le geste que nous faisons lorsque nous ouvrons une porte. Ainsi au-delà de l’étymologie physique, la sémantique de l’affordance serait un outil vraiment puissant .^[2]

**Ça n’est pas nécessairement une bonne idée mais l’importance du contexte dans l’efficacité d’une interface (et à fortiori d’une expérience utilisateur) n’est plus à démontrer : adapter aussi les interactions au contexte culturel est probablement une question à se poser dans certains cas .^[3]

Sa capacité à suggérer son utilisation. ↩︎
Cet article rejoint une réflexion antérieure que j’avais intitulée la sémantique de l’interaction : c’est donc un sujet qui m’interroge et me fait avancer. URL de l’article : https://www.ffoodd.fr/semantique-de-l-interaction/ ↩︎
Il est possible que ce sujet ait été théorisé par le passé, auquel cas donnez-moi de lecture via les commentaires :). ↩︎

La stratégie de contenu en pratique

Gaël Poupard — Tue, 22 Oct 2013 14:30:49 GMT

Un ouvrage exhaustif

Ce livre ne s’adresse pas seulement aux professionnels de la publication en ligne mais plutôt à tous les profils susceptibles d’intervenir sur le contenu — d’une manière ou d’une autre. Ça comprend les commerciaux, chefs de projets, concepteurs, ergonomes, graphistes, intégrateurs, et même les développeurs. Nous sommes tous garants d’un niveau de qualité ; et bien que nous ne puissions pas tous travailler la stratégie à proprement parler, gérer la façon de contribuer et l’affichage a un impact fort sur la gestion de contenu — et fait partie intégrante de la stratégie de contenu.

L’ouvrage traite alors exhaustivement tous les outils intéressants pour la stratégie de contenu, sans préciser le profil type d’utilisateur. Chacun se reconnaîtra : le référencement ou l’audit d’accessibilité par exemple sont rarement dévolus au commercial 🙂 .

Des outils analysés

Un point extrêmement appréciable est la présentation en fiches : chaque outil est exposé, expliqué puis mesuré. Une synthèse efficace conclue chaque fiche, constituée des avantages et inconvénients de l’outil ainsi que de l’avis des auteurs.

Aucune discrimination n’agit sur l’ordre ou le degré d’importance des outils : tous sont exposés de façon équitable. Ça peut être gênant pour quelqu’un qui cherche des indications précises, mais dans l’ensemble j’ai trouvé ça agréable : que vous ayez à gérer une stratégie de petite ampleur ou d’échelle industrielle, vous trouverez tout ce dont vous avez besoin. Et dans tous les cas, vous acquérez une culture générale dans le domaine.

Un véritable guide

Vous l’aurez compris, cet ouvrage est complet et concis. Son système de fiche permet de naviguer dans le livre selon ses centres d’intérêts, et l’érige également en guide pratique : une nouvelle demande concernant les contenus vous rend perplexe ? Jetez un œil à ce livre.

Liens d’évitement persistants

Gaël Poupard — Wed, 16 Oct 2013 17:56:40 GMT

Parmi ces techniques, certaines m’étaient inconnues : une ignorance qui ne nuisait pas directement à l’accessibilité mais bel et bien au confort d’utilisation du site pour les personnes concernées. Voici donc deux techniques que j’ai mises en place suite à cette lecture passionnante.

Les liens similaires

Il devient rapidement ennuyeux de parcourir une liste de liens (avec un lecteur d’écrans et/ou en tabulant) lorsque plusieurs liens consécutifs ont la même destination. Malheureusement, c’est le cas très souvent sur WordPress dans les boucles d’articles.

Et bien voici une bonne nouvelle : il est très simple de corriger ça, de façon totalement transparente pour tout le monde :

tabindex à -1 : pour la navigation au clavier, cet attribut permet de retirer un lien tabulable de l’index de tabulation. En l’appliquant judicieusement dans votre liste d’articles, vous ne laissez ainsi qu’un seul lien – et arrêtez de polluer la navigation au clavier.
aria-hidden à true : cet attribut permet de taire un élément dans les lecteurs d’écrans. La logique est la même que précédemment, à ceci près qu’on prendra soin de laisser le lien dont la vocalisation sera la plus pertinente : dans le cas d’une boucle WordPress, le lien présent dans les titres est idéal.

En appliquant cette technique correctement, on divise par deux ou trois le nombre de liens à parcourir dans une liste d’articles. Vos utilisateurs vous remercieront 🙂 .

Les liens d’évitement

Je ne reviendrais pas sur les bases de cette technique, qui est plus que documentée sur le web.^[1]

La persistance des liens d’évitement après leur première prise de focus
La mise en avant visuelle de la zone ciblée par le lien d’évitement

Concernant le second point, je ne l’ai pas encore implémenté sur ffoodd.fr pour la seule raison que je dois trouver un signifiant visuel cohérent avec mon design, mais ça ne saurait tarder 🙂 .

Cependant la persistance des liens m’a particulièrement intéressé, car c’est un point que je trouve réellement bénéfique pour le confort d’utilisation. Même si je ne me sers de la tabulation que pour tester mes intégrations, il m’a toujours semblé désagréable de « perdre » ces liens.

La persistance des liens d’évitement

En recherchant plus d’informations sur cette technique, je suis tombé sur le blog de la société Atalan pour laquelle travaille Johan – et sur un article dédié au sujet. Des ressources très intéressantes sont données, cependant toutes sont basées sur jQuery pour ajouter une classe aux liens après leur première prise de focus. Dommage, je n’utilise pas jQuery sur ffoodd.fr.

Voici donc le bout de code correspondant, en vanilla javascript :


/* Lien d’évitement > Persistance de l’affichage
 * @see : https://blog.atalan.fr/des-liens-devitement-astucieux/
*/
[].forEach.call(document.querySelectorAll(".skip"), function(el) {
  el.addEventListener("focus", function() {
  el.classList.add("show");
  });
});

Et voilà ! Pour faire simple, je cible les liens disposant de la classe « skip » pour leur ajouter la classe « show » au focus. Et le CSS fait le reste.

À noter que « dans certains cas rares » Chrome et IE ne transportent pas le focus sur la cible du lien d’évitement lorsqu’il a été activé. Un petit script vient facilement s’assurer que le focus est bien transporté :


/* Correction du bug des ancres sous Chrome
 * @see : https://www.nczonline.net/blog/2013/01/15/fixing-skip-to-content-links/
 * @see : https://blog.atalan.fr/des-liens-devitement-astucieux/
*/
window.addEventListener("hashchange", function(event) {
  var element = document.getElementById(location.hash.substring(1));
  if (element) {
    if (!/^(?:a|select|input|button)$/i.test(element.tagName)) {
    element.tabIndex = -1;
    }
    element.focus();
  }
}, false);

La qualité de l’expérience

Ce sont certes des détails, mais ces détails améliorent le confort de navigation et rendent un site agréable : l’internaute appréciera cette expérience, et reviendra (pour peu que vos contenus soient à la hauteur).

Un article de Jean-Pierre Villain sur Alsacréations - il date de 2006 et est toujours (presque) d’actualités : https://www.alsacreations.com/tuto/lire/572-Les-liens-d-evitement.htm ↩︎

Navigation, Aria et WordPress

Gaël Poupard — Wed, 09 Oct 2013 15:31:19 GMT

Dans sa version basique, la navigation de WordPress n’a rien de particulier (si ce n’est la multitude de classes générées sur chaque élément 🙁 ). Or ARIA permet d’ajouter une couche sémantique non négligeable et relativement simple à mettre en place, améliorant ainsi l’accessibilité de la navigation.

Notre objectif

L’implémentation d’ARIA sur une navigation est simple ‐ bien qu’il soit assez compliqué d’en trouver une documentation ou un exemple concret. Voici le résultat attendu sur ffoodd (je vous épargne les classes et identifiants, pour cette fois 😉 ) :

<nav id="nav" role="navigation">
  <ul role="menubar">
  <li role="menuitem" aria-labelledby="ffoodd">
  <a href="https://www.ffoodd.fr" id="ffoodd">ffoodd</a>
  </li>
  <li role="menuitem" aria-labelledby="travaux">
  <a href="https://www.ffoodd.fr/travaux/" id="travaux">Travaux</a>
  </li>
  </ul> 
</nav>

Vous connaissiez sans doute déjà le rôle « navigation », qui identifie la zone majeure du contenu destinée à la navigation. Les autres rôle et attributs sont explicites, et on en saisit facilement l’intérêt sur cet extrait de code. Voyons maintenant comment obtenir ce résultat avec WordPress.

Ce sympathique walker se nomme Walker_Nav_Menu. Je l’avais rencontré la première fois en farfouillant dans le code de [Reverie](https://themefortress.com/reverie/ « Reverie .fr/blog/construire-walker-wordpress/ « Construire un walker WordPress (nouvelle fenêtre) » = un starter theme pour WordPress (nouvelle fenêtre) »), sans en saisir l’intérêt à l’époque. Puis mes compétences et réflexions évoluant avec le temps, lorsque je le recroisais sur le blog de Willy Bahuaud dans son article présentant les walkers, j’en saisis rapidement l’intérêt et me mit en tête de m’en servir sur mon thème ffeeeedd.

Je vous recommande chaudement de lire l’article de Willy sur le sujet, qui est une entrée en matière extrêmement intéressante.

Les mains dans le code

Voilà sans plus attendre le code obtenu après quelques recherche :

  /* == @section Amélioration de la navigation ==================== */
  /**
 * @note : Un walker nous permet de amnipuler le html généré pour la navigation afin d’y ajouter les roles aria qui vont bien.
 * @author : Gaël Poupard
 * @see : https://twitter.com/ffoodd_fr
 * @see : https://wabeo.fr/blog/construire-walker-wordpress/
 * @author : Willy Bahuaud
 * @see : https://core.trac.wordpress.org/browser/tags/3.6.1//wp-includes/nav-menu-template.php#L0
 */
  class ffeeeedd__walker extends Walker_Nav_Menu {
  function start_el( &$output, $item, $depth = 1, $args = array(), $id = 0 ) {
  $indent = ( $depth ) ? str_repeat( "\t", $depth ) : ’’;

  $class_names = $value = ’’;

  $classes = empty( $item->classes ) ? array() : (array) $item->classes;
  $classes[] = ’menu-item-’ . $item->ID;

  $class_names = join( ’ ’, apply_filters( ’nav_menu_css_class’, array_filter( $classes ), $item, $args ) );
  $class_names = $class_names ? ’ class="’ . esc_attr( $class_names ) . ’"’ : ’’;

  $id = apply_filters( ’nav_menu_item_id’, ’menu-item-’. $item->ID, $item, $args );
  $id = $id ? ’ id="’ . esc_attr( $id ) . ’"’ : ’’;

  $output .= $indent . ’<li’ . $id . $value . $class_names .’ role="menuitem" aria-labelledby="item-’ . sanitize_html_class( apply_filters( ’the_title’, $item->title, $item->ID ) ) . ’">’;

  $atts = array();
  $atts[’title’] = ! empty( $item->attr_title ) ? $item->attr_title : ’’;
  $atts[’target’] = ! empty( $item->target ) ? $item->target : ’’;
  $atts[’rel’] = ! empty( $item->xfn ) ? $item->xfn : ’’;
  $atts[’href’] = ! empty( $item->url ) ? $item->url : ’’;

  $atts = apply_filters( ’nav_menu_link_attributes’, $atts, $item, $args );

  $attributes = ’’;
  foreach ( $atts as $attr => $value ) {
    if ( ! empty( $value ) ) {
    $value = ( ’href’ === $attr ) ? esc_url( $value ) : esc_attr( $value );
    $attributes .= ’ ’ . $attr . ’="’ . $value . ’"’;
    }
  }

  $item_output = $args->before;
  $item_output .= ’<a’. $attributes .’ id="item-’ . sanitize_html_class( apply_filters( ’the_title’, $item->title, $item->ID ) ) . ’">’;
  $item_output .= $args->link_before . apply_filters( ’the_title’, $item->title, $item->ID ) . $args->link_after;
  $item_output .= ’</a>’;
  $item_output .= $args->after;

  $output .= apply_filters( ’walker_nav_menu_start_el’, $item_output, $item, $depth, $args );
  }
  }

Le walker manipule chaque niveau de rendu de la navigation, ce qui nous permet d’ajouter les rôles très facilement. La seule intervention astucieuse consiste à récupérer l’intitulé de l’item afin de l’utiliser comme label pour la navigation.

Et voilà ! Simple, non ?

Les évolutions à venir

Bien qu’intéressante, cette astuce n’est pas parfaite. En effet la spécification ARIA prévoit des états pour les éléments, afin d’expliciter les interactions.

Dans notre cas, il va falloir appliquer l’attribut booléen aria-selected sur les items de navigation, en passant sa valeur de true à false selon l’item actif.

Bien qu’ayant déjà appliqué ce comportement sur des boîtes à onglets notamment, j’aimerais parvenir à le faire sur ma navigation sans passer par du javascript. J’ai cherché des pistes pour utiliser le walker (qui à priori devrait être capable de repérer l’item actif) mais sans résultat pour le moment, donc n’hésitez pas à commenter l’article ou à me contacter par mail si vous avez la moindre piste à me suggérer (voire même la solution, hein :D).

De plus, un comportement (en javascript à priori) est également à prévoir pour les sous-menu, qui pourront s’avérer plus complexes à gérer ‐ bien qu’ARIA soit très complète sur ce sujet.

Expérience de Typecast

Gaël Poupard — Mon, 07 Oct 2013 18:18:18 GMT

Présentation

Typecast est ‐ comme son nom l’indique ‐ un outil (une application web, plus précisément) conçu pour caster les typographies. Je traduis sa présentation officielle :

Utilisez Typecast pour créer des designs visuels et sémantiques.
Vérifiez la lisibilité, le rendu et la beauté puis partagez un prototype fonctionnel de votre design.

De charmantes intentions !

Qui dit casting dit choix

L’outil propose un large choix de typographie, bien pratique pour le casting à venir. Vous pouvez parcourir plusieurs grandes fonderies disposant de plans de distribution adaptés au web :

Autant ne pas vous le cacher : quel plaisir de parcourir le catalogue de ces fonderies ! Le bas blesse légèrement malgré tout car aucune distinction n’est faite entre les typographies gratuites ou payantes, ce qui peut réserver des surprises 🙂

Prise en main intuitive

L’interface est extrêmement simple : le contenu et un bloc déplaçable pour ajuster les options, à la manière des principaux logiciels d’édition graphique. Vous pouvez filtrer les typographies par fonderie, sélectionner la graisse et le style, et modifier à peu près tous les styles existants pour la typographie en CSS.^[1]

Un format d’article standard est également fourni pour vous lancer dans le choix des typographies, mais vous pouvez bien entendu modifier ce format.

Un résultat utile et pratique

L’intérêt principal de cette application repose sur les diverses façons de partager ou publier le résultat obtenu :

générez une page HTML auto-hébergée afin de tester son rendu sur différents appareils et navigateurs, ou partagez simplement le lien pour montrer votre travail;
exportez le HTML/CSS afin de le travailler en local ou plus simplement le copier/coller dans votre prototype.^[2]

exportez la charte graphique de votre résultat en PNG : liste des typographies et graisses, couleurs, styles principaux…

Pour vous donner un aperçu du résultat, voici une portion de la charte obtenue lors de mon casting pour ffoodd :

Exemple de charte générée par Typecast

L’outil idéal ?

Vous l’aurez compris, j’ai été réellement convaincu — et satisfait — par cet outil. Cependant je ne me suis servi que de la version d’essai de 14 jours, gratuite. La version payante vous permet de gérer plusieurs projets, et il existe des partenariats avec certaines fonderies pour ajouter directement les typographies choisies à vos plans.

Bien que l’outil soit génial, je n’ai pas pris d’abonnement car c’était un one-shot pour la refonte de ffoodd. À titre personnel ce n’est pas intéressant car je ne m’en servirais pas; à titre professionnel, très peu de clients acceptent d’acheter une typographie et je dois très souvent jouer avec des typographies websafe — ce qui fait perdre tout son intérêt à Typecast.^[3]

Cela étant dit, je recommande chaudement cet outil, qui, du point de vue du designer, est réellement riche et permet de se focaliser sur l’essentiel avant de se lancer dans la production d’une maquette complète.

Certaines fonderies proposent des typographies OpenType : Typecast vous permet d’utiliser les options telles que les ligatures, visibles par exemples sur la Bello-Pro à l’oeuvre sur ce site. ↩︎
Attention cependant : je trouve que le code généré n’est pas du meilleur effet. Question de goût ? ↩︎
Exception : les Google Webfonts, gratuites et accessibles dans Typecast. Si vous avez l’habitude de vous en servir, la licence Typecast peut vous intéresser. ↩︎

Armony Altinier

Gaël Poupard — Fri, 04 Oct 2013 15:12:34 GMT

Est-ce que ça peut pénaliser quelqu’un ?

Accessibilité web

Gaël Poupard — Fri, 04 Oct 2013 14:42:39 GMT

Une fois passée l’appréhension due au format du livre et au thème ‐ qui a la réputation d’être lourd, cognitivement parlant ‐ on est pris dans l’engrenage : de la première à la dernière page, impossible de décrocher.

Instauration du contexte

Parmi les professionnels du web en France, le sujet semble avoir mauvaise haleine : hormis les entreprises spécialisées, les experts qualifiés et quelques pointures de la qualité web, le sujet semble tabou. L’image d’un domaine compliqué, difficile à mettre en place comme à apprendre et coûteux pour le client comme pour le prestataire lui colle aux basques.

Ce livre d’Armony Altinier et Dominique Burger commence donc sereinement par replacer l’accessibilité web dans un contexte historique, technologique et juridique : j’ai énormément appris ! Cette seule première partie vaut le détour, car ces informations rendent la question de l’accessibilité web naturelle, voire évidente. Mais attention : le livre n’est pas indigeste pour autant. Les auteurs tentent judicieusement d’impliquer la compréhension des lecteurs, en mettant en scène des événements qui peuvent arriver à tout le monde : un bras cassé ou une panne de souris, par exemple.

La partie historique est également enrichissante, notamment en ce qui concerne les deux référentiels Français : Accessiweb et RGAA. L’accessibilité est un sujet mouvant et bien que disposant de référentiels aux critères précis, ils ne sont pas pour autant tous pertinents. Tout est toujours une affaire de contexte.

Détail des thématiques Accessiweb

Armony Altinier et Dominique Burger choisissent de se baser sur Accessiweb, pour la simple et bonne raison que c’est un référentiel nettement moins figé que RGAA.

Après une introduction au référentiel, les thématiques sont développées comme suit :

Images, cadres et couleurs (thématiques AccessiWeb 1 à 3)
Multimédia (thématique AccessiWeb 4)
Tableaux (thématique AccessiWeb 5)
Liens et scripts (thématique AccessiWeb 6 et 7)
Eléments obligatoires, structuration de l’information et présentation de l’information (thématique AccessiWeb 8 à 10)
Formulaire, navigation et consultation (thématique AccessiWeb 11 à 13)

Une couche vient s’ajouter ensuite : HTML5 et ARIA.

Ces thématiques sont expliquées, clarifiées et détaillées : des cas concrets avec des vrais morceaux de code viennent illustrer les points les plus intéressants (le cas des tableaux complexes est un excellent exemple).

Un apprentissage permanent

Ce que je retiens de ce livre, c’est le crédo mentionné par les auteurs : la question à se poser lorsqu’on parle d’accessibilité est « est-ce que ça peut pénaliser quelqu’un ? ».^[1]

Partant de là, la leçon principale que j’en ai retenu vient tordre le coup à cette image de domaine figé réservé à des experts chevronnés. Non, l’accessibilité web n’est pas plus figée que les autres domaines du web, et non, ce n’est pas si complexe à mettre en oeuvre. Dans la plupart des sites que je réalise, les contenus sont purement textuels : pas de tableaux, pas d’iframe, pas de vidéos ou de sons, et très rarement des images porteuses de sens. Voilà qui élimine déjà beaucoup de problèmes.

Mais pour chaque création de site, et à chaque étape du processus, il faut se poser la question : cela risque-t’il de gêner quelqu’un ? Il est compliqué d’imaginer tous les cas de figure, mais se poser la question est comme poser la première pierre : on bâtit un édifice qui sera forcément plus robuste si l’on s’interroge en amont.

La démarche est bien de s’interroger : vous pouvez choisir de ne pas tenir compte de certaines remarques. Par exemple sur ce site, je justifie le texte courant, mais cela est considéré comme une mauvaise pratique et un risque pour l’accessibilité des contenus. ↩︎

P. Mendelson

Gaël Poupard — Thu, 03 Oct 2013 12:50:26 GMT

Il vaut mieux savoir tout chercher que chercher à tout savoir.

Atterrissage réussi

Gaël Poupard — Wed, 02 Oct 2013 14:33:43 GMT

La refonte : un travail de longue haleine

Je ne saurais vous dire depuis combien de mois je travaille sur cette refonte. Je crois d’ailleurs que ça a commencé par mon thème ffeeeedd et l’amélioration de mon processus de travail : beaucoup de découvertes, énormément de recherches, et au final une progression certaine.

Un seul constat : mon site était devenu obsolète : en deux ans, j’ai progressé tant en graphisme qu’en intégration – mais surtout en développement WordPress ainsi qu’en javascript. J’ai également appris beaucoup de choses concernant l’accessibilité, le html5, ARIA, les performances web, le responsive web design, la compatibilité navigateur.^[1]

La roue existe déjà

C’est un adage bien connu des professionnels du web. Je ne m’étendrais pas sur le processus de refonte graphique et technique – je trouve la série d’articles de Marie Guillaumet sur ce sujet absolument remarquables, et je vous invite à les lire.

Cet article ne précisera donc pas tout ce qui a été fait, mais je peux d’ores et déjà annoncer une série d’articles à venir sur les problématiques rencontrées et leurs résolutions respectives. De nombreuses références et ressources viendront appuyer et enrichir ces articles, comme à mon habitude.

Une ambition simple :

mettre à disposition les solutions trouvées, adaptées ou crées
les expliquer en détail et les documenter

Certaines auront peut-être du succès !

Objectif atteint

Je m’étais fixé comme objectif de mettre le site en ligne avant Paris Web 2013, car pour la première fois je vais pouvoir y assister (merci à kloh, le grand frère qui m’a aidé à acheter mes tickets).

J’y suis parvenu avec une semaine d’avance, et cela m’enchante ! Le travail n’est pas pour autant terminé, car j’ai encore sur le feu une présentation de mes travaux plus agréable à l’œil et plus flatteuse pour eux. Revenez voir de temps en temps 😉

À ce sujet : j’ai enfin abandonné le support d’IE7, et ce afin d’utiliser le plein potentiel des mises en page tabulaires en CSS 2.1. ↩︎

Stratégie de contenu mobile

Gaël Poupard — Fri, 23 Aug 2013 15:01:21 GMT

Les détails négatifs

Car il ne faut pas plus de quelques détails pour donner une impression négative :

Les explications se répètent de nombreuses fois, et parfois s’enchaînent simplement – donnant l’impression d’être légèrement attardé et d’avoir besoin de cette frustrante répétition;
Beaucoup d’allusions péjoratives sont faites aux CMS « populaires » – comparant WordPress à Tumblr, ignorant la capacité de WordPress à créer des types de contenus grâce aux custom post types, etc… – ce qui, pour un livre traitant de la gestion de contenu, s’avère douteux;
Le ton si délicieux des précédents ouvrages de la collection est absent : aucune touche d’humour, et des traces de mépris ou d’ignorance de l’écosystème du web;
Une traduction « amusante » mais déplaisante, qui ralentit la lecture : fourche pour fork, SGC pour CMS, etc…

Tout cela peut sembler anecdotique mais a réellement ralenti ma lecture de ce livre, me faisant tiquer sur des détails à priori anodin mais révélant un cruel manque de réalité. Comment accorder de la crédibilité à cette œuvre dans ces conditions ?

Quelques notions indispensables

Les explications sont cependant cohérentes et instructives, mais dépassent rarement le simple bon sens là ou l’on attend un partage d’expérience.

Voici ce que j’ai appris et retenu de cet ouvrage :

Scinder le contenu, encore et encore : plus le contenu sera segmenté, plus il sera facile de le répartir et de s’en servir à bon escient;
Le structurer et le caractériser sémantiquement – comme le font les micro-données par exemple;
L’idéal est un champ par information : auteur, date, titre, etc…;
L’extrait d’un article (dans une liste d’article) est un teasing : il doit inciter à lire l’article entier – et par conséquent être différent des premiers caractères de l’article lui-même ! Arrêtons donc de tronquer le contenu en guise d’introduction, car l’extrait à un rôle à part entière;
Disposer de plusieurs titres selon le contexte d’utilisation :
- dans le contenu lui-même, en en-tête de l’article;
- sous forme de lien;
- sur les réseaux sociaux;
- en résultat de recherche interne;
- orienté SEO.

Certains points semblent évidents, mais on les omet souvent. Cependant, la ou l’auteur prône l’utilisation de CMS maison ou très avancé, j’aimerais signaler que la plupart des conseils fournis dans ce livre sont réalisables très facilement dans WordPress, et que la plupart des CMS actuels permettent également ce type de fonctionnalité.

Une lecture intéressante mais dispensable

Certes, la lecture reste intéressante : la façon d’aborder les choses en elle-même est différente.

Cependant, force m’est de constater que si j’avais été confronté à ces problématiques, je serais probablement arrivé à ces mêmes résultats. Les autres livres que je lis ne me font pas cet effet et me donnent véritablement l’impression d’apprendre.

Dommage.

IE9 sur WP7 et @font-face : je t’aime, moi non plus.

Gaël Poupard — Wed, 24 Jul 2013 19:16:35 GMT

Cependant, je dois également avouer que certaines choses me surprendront toujours : c’est le cas du support de @font-face sur Windows Phone 7.

Un jour, j’ai fait un test

Raphaël Goetter a annoncé aujourd’hui la refonte de son site principal, goetter.fr, sur son blog. Étant donné que nous avions discuté quelques jours auparavant de ligatures sur Twitter, j’ai lâché un commentaire au sujet de cette nouveauté sur le site de M. Goetter. Cependant sa réponse m’a légèrement surpris, puisque je ne m’attendais pas à ce qu’il doive se séparer de cet ornement sur mobile – pour d’excellentes raisons au demeurant.

Pris de curiosité, j’ai alors décidé d’y jeter un œil sur mon smartphone : un Lumia 800 tournant sur Windows Phone 7.10, et Internet Explorer 9. Outre l’absence de la typographie «Calendas Plus», j’ai constaté que la typographie générée sur Icomoon pour gérer les icônes était également absente.

Je remonte ce problème ni une ni deux à l’auteur, qui est dans l’impossibilité de tester lui-même. Je décide donc de le faire, en commençant par regarder mon propre site – je ne disposais pas encore de ce téléphone lorsque cette version est apparue : sans appel, mon logo basé sur @font-face n’apparaît pas non plus.

Un doute m’habite

Dès lors je sens poindre l’éventualité de l’absence de support de @font-face… Je fais donc le tour de plusieurs sites réalisés au sein de l’agence 1-ter-net et utilisant @font-face. La encore, aucun doute possible : @font-face ne fonctionne sur aucun d’entre eux.

Au cas ou, j’emprunte le smartphone d’une collègue, lui aussi sur Windows Phone 7. C’est le drame.

Google m’a répondu !

Je vous laisse le soin de parcourir les résultats les plus intéressants :

Sans équivoque : IE9 sur WP7 supporte @font-face mais ne chargera pas de fichiers typographiques externes. Ça explique également le faux-positif de Modernizr concernant la détection de cette fonctionnalité.

Vous voilà prévenus : définir un fallback est un minimum pour se prémunir contre ce problème; cependant le cas des icon-fonts est plus ennuyeux puisqu’on s’appuie souvent sur des caractères unicodes indisponibles dans la plupart des typographies, et un remplacement d’images conditionnel semble compliqué…

Si quelqu’un connait un moyen de cibler uniquement IE9 sur Windows Phone 7, je suis preneur ! De plus, je n’ai aucun moyen de tester IE sur Windows Phone 8 pour le moment, je ne saurais donc préciser si ce problème existe toujours dans les versions les plus récentes.

Edit : La nuit portant conseil, l’astuce dans le cas d’une icon-font semble finalement «simple». Il s’agira de les baser sur des caractères unicodes ayant un intérêt ( par exemple, ☎ ). Cependant, cette astuce n’est possible que lorsqu’on a le choix des glyphes utilisés comme support – ce qui, je crois, est le cas dans IcoMoon – et de disposer d’un caractère unicode signifiant.

Pourquoi l’intégration web est le cœur d’un projet

Gaël Poupard — Thu, 04 Jul 2013 12:33:38 GMT

Je ne secouerais pas le marronnier des nouveautés en question, je suppose que tout le monde a déjà parcouru le champ de bogues.

Un certain nombre d’articles ont déjà été publiés sur le sujet, par d’excellents intégrateurs :

L’importance d’un intégrateur par @HTeumeuleu
De l’intégrateur au développeur front-end : un maillon essentiel de la qualité Web par Nicolas Hoffmann sur Openweb
Pourquoi un (bon) intégrateur est indispensable à tout projet web par @Darklg

Je tenais simplement à partager une vision simple sur ce nouvel état de fait : au-delà des compétences techniques requises, de l’évolution du web et de ce métier, il existe une raison extrêmement simple qui justifie l’importance de l’intégrateur web.

Il est au milieu de la chaîne de production.

Sans rire. Littéralement.

Conception > Graphisme > Intégration > Développement > Production

Comment donc un concepteur ou un développeur, aussi doués soient-ils, auraient une meilleure vision du projet ? L’intégrateur parle le langage de tous les autres postes, ce qui n’est forcément réciproque. De plus, la chaîne de production est de moins en moins linéaire – on évoque notamment le design dans le navigateur – et le seul poste à pouvoir naviguer et intervenir dans ce flux de travail mouvant, vous l’avez dans le mille : c’est l’intégrateur.

Le même constat m’amène à penser qu’à l’avenir, les chefs de projets dans les structures comme l’agence 1-ter-net – dans laquelle je travaille – seront issus de l’intégration.

À condition de retenir [cette leçon d’humilité](https://www.lesintegristes.net/2013/03/19/integration-web-humilite/ « « L’intégration web, cette leçon d’humilité » par Marie Guillaumet sur Les Intégristes (nouvelle fenêtre) »), et de faire du bon travail.

WordPress 3.5 est médiaphobe

Gaël Poupard — Wed, 16 Jan 2013 12:23:48 GMT

Sauf que

Dès ma première utilisation de cette nouvelle mouture je suis tombé sur un problème assez gênant : dans la fenêtre modale servant à insérer des médias depuis l’éditeur, l’ajout d’un fichier me retourne une erreur en indiquant

« Une erreur est survenue lors du téléchargement.
Veuillez réessayer plus tard. »

Malgré ça, ledit fichier a été ajouté à la bibliothèque des médias. De plus, impossible de parcourir la bibliothèque et d’insérer un fichier depuis cette même fenêtre modale ! Après une recherche rapide, il s’avère que je ne suis pas le premier à rencontrer ce problème.

Or ce bug – connu depuis la bêta – peut avoir diverses origines :

Le serveur utilise mod_pagespeed
Un plugin interfère avec les scripts de l’administration
Le thème retire la version de jQuery inclue, et en utilise une autre
Une erreur a pu se glisser dans certains fichiers, à vérifier via la console js du navigateur
Un mode DEBUG de WordPress « abusif »
La concaténation des fichiers de l’administration trop agressive ou mal effectuée

Miam ! Vous l’aurez compris, beaucoup de ces causes potentielles tournent autour des fichiers javascript ( et la technologie Ajax utilisée dans ce cas ). Une multitude de parades ont été proposées sur le web, fonctionnant dans certains cas :

Repasser au thème TwentyTwelve
Désactiver les plugins un par un
Désactiver mod_pagespeed ou un système de concaténation quelconque du js de l’administration

Ces solutions ont – dans beaucoup de cas – suffit à résoudre le bug, ou au moins à en identifier l’origine afin de le corriger. Pas dans mon cas.

.htaccess

Après diverses pérégrinations dans les tréfonds de WordPress, j’ai finalement trouvé la solution à mon cas : le .htaccess.

Pour une raison ou pour une autre, appliquer le .htaccess que j’ai l’habitude d’appliquer en production a suffit. C’est donc un patch insignifiant, sauf que WordPress ne dispose pas – et ne crée pas – de .htaccess par lui-même. C’est une habitude que j’ai acquise pour des questions d’environnement serveur, de performances, de qualité web et de types de fichiers à servir, mais qui n’est pas connue de tout le monde.

À titre personnel, le .htaccess de base dont je me sers est un amalgame :

du .htaccess disponible dans le html5 Boilerplate
du .htaccess dédié à WordPress proposé par seo-mix

Je suppose qu’il s’agit d’un entête http ou d’un type MIME incorrect qui nuit à la bonne compréhension du fichier par le serveur, sans toutefois en être sûr. Étant donné que j’avais jusqu’à présent l’habitude d’ajouter le .htaccess à la fin du développement, je me contenterais désormais de l’ajouter dès le début du projet.

De plus, il s’agit d’une bonne pratique nécessaire à la qualité d’un site web : il est donc indispensable de disposer d’un fichier .htaccess efficace.

À venir : ffeeeedd

Gaël Poupard — Tue, 08 Jan 2013 15:15:11 GMT

On a ainsi vu germer ces dernières années une multitude d’outils, proposés par des professionnels aguerris et basés sur leur expérience et leur envie de partager leurs connaissances. Certains sont l’œuvre d’un seul, d’autres le fruit d’une communauté de passionnés. On peut en citer quelques-uns :

HTML5 Boilerplate par Nicolas Gallagher, Hans Christian Reinl, Cãtãlin Mariş, Mathias Bynens, Paul Irish, & Divya Manian ( et une communauté gigantesque ).
Knacss par Raphaël Goetter
Starkers Par Viewport Industries
Reverie Par ThemeFortress et basé sur Foundation

J’ai parcouru, décortiqué et utilisé beaucoup d’outils de ce type. Mais un constat demeure : aucun n’a jamais été parfaitement accordé à mes besoins, et c’est tout à fait normal.

Ma nourriture

Tous ces outils m’ont beaucoup appris, tout comme les livres que j’ai lus et les communautés dont je fais partie. Certains d’entre eux font partie de mon quotidien mais il m’est naturellement venue l’envie de créer mon propre outil de travail, que je comprendrais jusqu’à la moelle et que je pourrais adapter à tous mes projets en un claquement de doigts.

Le socle général de mon travail d’inté-graphiste est WordPress – et pour les autres solutions techniques, Knacss m’a permis de gagner pas mal de temps depuis sa sortie. Je me suis donc mis en tête de créer un thème WordPress ajustable et extensible très facilement, dans l’optique de créer une base solide pour chaque site à construire dans le futur.

ffeeeedd

Mon projet est donc lancé. ffoodd – dont la signification est expliquée – fut la notion de base.

Ce projet s’appelle donc ffeeeedd et a pour objectif de nourrir chacun de mes projets à venir.

Outre le thème blanc et les fonctionnalités additionnelles, une structure très personnelle des css va être mise en place. Une version personnalisée de Knacss servira de fondation, et l’enjeu que je me fixe est de créer un « kit » pour toute les personnalisations visuelles. Chaque portion du thème, chaque module, chaque format de page et d’article sera conçu de manière à hériter tous les styles visuels du Kit.

L’emploi de Knacss et d’une démarche orientée objet devrait me permettre de concevoir une structure solide et complexe tout en conservant une souplesse dans la mise en forme et des performances tout à fait raisonnable.

Tout vient à point qui sait attendre

La première version me prend un temps considérable et n’est pas prête – même pour une utilisation expérimentale. Je ne perds pas de vue que ce projet me servira avant tout à titre personnel ( afin de de me faciliter la vie dans mes tâches quotidiennes ) mais également pour apprendre, chercher et accumuler de bons réflexes – qu’il s’agisse d’accessibilité, de performances, etc…

Un jour viendra ou j’ouvrirais ce travail aux critiques, afin d’améliorer autant que possible le produit final.

Mais pour le moment, c’est uniquement mon excuse pour n’avoir pas écrit plus en 2012 et une bonne résolution pour 2013 !

Le bien & le mal pour l’intégrateur web

Gaël Poupard — Tue, 13 Nov 2012 15:40:08 GMT

Il y a de bonnes & de mauvaises solutions

Une bonne idée le jour J peut être une mauvaise idée le D day. Au commencement de ffoodd, je voulais un fond simple mais avec un peu d’impact : j’ai donc choisi le motif très simple mais contrasté que vous avez sous les yeux. À l’époque, je rêvais de tester les dégradés radiaux en css – et j’étais persuadé de pouvoir réaliser mon motif à l’aide de cette technique. Ni une, ni deux : je le fais. Je tartine les préfixes navigateurs et la syntaxe non préfixée, et nous voilà partis. À bien y réfléchir, c’était ma première erreur.

Comme je suis méticuleux, je vérifie tout ça sur nos navigateurs adorés – et ô joie ! – Firefox freeze en voyant ça. Je me contente alors de retirer la ligne préfixée concernée, et tant pis pour lui : il aura un aplat. À bien y réfléchir, c’était le premier avertissement.

Pardonnez-moi mon père car j’ai péché

Firefox 16 est apparu, apportant des nouveautés dont : le support des dégradés sans préfixe. Firefox a donc compris ma déclaration background-image, et ô miracle ! Il freeze toujours, une vraie salade.

Je reprends alors mon code, et me demande : pourquoi diantre avoir utilisé un dégradé pour faire ça ?

Mauvais support navigateur
Problème de performance évident
Syntaxe compliquée et instable ( à l’époque )

En tant qu’intégrateur voulant atteindre un objectif, je n’ai pas fait le meilleur choix. J’ai donc repris le travail. J’ai supprimé ce dégradé, créé le motif en png-8 à 2 couleurs ( 64 octets ! ) et vu le poids, je l’ai même encodé en base64. Et voilà !

La morale

Désormais ce fond est :

Compatible tous navigateurs jusqu’à IE8
Trois fois plus légers
Beaucoup plus performant

Ça n’est certes pas grand chose, mais cette erreur de parcours témoigne de mon évolution dans ce métier. C’était une mauvaise idée d’appliquer ce motif en css pur, mais 18 mois plus tard, quand j’ai vu ce bout de code, j’ai su trouver la meilleure solution.

Je continue mon amélioration perpétuelle.

Webgrids

Gaël Poupard — Wed, 07 Nov 2012 19:00:55 GMT

L’adret

Ma formation en communication visuelle m’a enseigné les règles typographiques, de mise en page, l’histoire de l’imprimerie et les différents mouvements qui ont heurté l’histoire du graphisme et de l’impression.

L’ubac

Mon expérience professionnelle dans le web m’a éduqué aux contraintes spécifiques du support : affichage sur écran divers et variés, dans des navigateurs qui sont également pléthore.

Un livre très instructif

Dès la première page, la connaissance nous submerge :

Avant que le livre ne prenne la forme que nous lui connaissons aujourd’hui,on utilisait le rouleau ou volumen […]. Les scribes de l’époque alignaient des colonnes sur cette longue bande de papyrus que l’on déroulait d’un côté et enroulait de l’autre au fur et à mesure de la lecture. À bien y regarder, la pratique de la lecture propre à ce support que les anglophones appellent – accrochez-vous – scroll, en fait un cousin bien plus proche de la page web que ne le sera jamais votre livre de poche, descendant végétarien du codex en parchemin.

Et ce n’est qu’un extrait de la première page. Ce livre fourmille d’explications aussi simples que pointues pour comprendre et appréhender la mise en page sur le web. Un véritable retour aux fondamentaux – parfaitement documentés – qui devenait nécessaire. Je pense que cette lecture m’a fait progresser et c’est la meilleure raison qui soit pour faire l’éloge de ce livre plus qu’abordable.

Ce livre permet d’atteindre le sommet, ce point si compliqué à atteindre mais bel et bien le seul ou se rejoignent l’ubac et l’adret. Réconciliez le web et la mise en page avancée, lisez ce livre !

À noter : un autre excellent ouvrage est disponible dans la même collection aux Ateliers Perrousseaux : Typo & web. Je vous le recommande chaudement – et il fera peut-être l’objet d’un article similaire dans le futur.

expérience: inherit;

Gaël Poupard — Wed, 18 Jul 2012 17:32:46 GMT

Ceci n’est pas un article faisant l’éloge d’IE — ni un énième pamphlet dénonçant la huitième plaie d’Égypte — mais il illustre ce proverbe : « Il n’y a pas de mauvais outils ; que des mauvais ouvriers. »

La petite histoire

Mon cher stagiaire — comme tout le monde — pensait être un expert en recherche sur Google. Sa page ne s’affiche pas correctement sur IE uniquement, donc il cherche sur Google « Problème affichage Internet Explorer ». Logique ! C’est ainsi qu’un monde nouveau s’ouvre à lui : les hacks css. Adepte du Nutella, il m’en tartine donc une couche conséquente pour obtenir un affichage décent. Et Dieu sait que ça prend du temps…

L’affichage sur Chrome et Firefox était correct, aussi à aucun moment il n’a douté de ces deux-là. Or un bref coup d’œil sur son code source valait toutes les lectures foireuses sur comment hacker Internet Explorer : une balise <a> ouverte avant le doctype.

C’est alors que, comme Père Castor, j’ai raconté une histoire :

Il y a fort, fort longtemps, de nombreux grouillots du web se plaignaient du vieux roi Internet Explorer. Si souvent qu’ils décidèrent d’ignorer le vieux roi, qui faisait rien que les embêter. C’est alors qu’une bande de chevaliers errants ont arrêté d’errer : Chrome, Firefox, Opéra, Safari pour ne citer qu’eux. Ils ont dit : “ Ce roi déchu qui vous déçoit n’est pas assez bien pour vous. Viendez et nous vous guideront vers un royaume sans bug d’affichage. ” Alors les grouillots les ont suivis et ont commencé, lentement mais sûrement, à oublier le vieux roi.

Attention, péripétie :

Puis un jour, un péquin plus curieux que la moyenne a demandé aux preux chevaliers quel était leur secret pour un univers dénué d’erreur d’interprétation. Leur réponse fut éloquente : “ Nous savons votre ignorance, et avons décidé de ne pas vous éduquer afin que jamais vous ne sachiez vous plaindre. ”

Une pléthore d’écrits plaintifs et acerbes sur ce bon vieil IE ont été publiés. La plupart étaient justifiés. Étaient. Chaque problème a sa solution, et ces plaintes ont servis d’excuses à certains pour se résigner et arrêter de chercher la solution. Combien de fois ai-je pu dire et entendre « C’est la faute d’IE ». Et pourtant, ce n’est pas un mauvais bougre : il est aujourd’hui le seul navigateur à vous signaler que votre code source est absurde. Si ce stagiaire n’avait pas eu la présence d’esprit — et l’ordre intimé — de vérifier sur IE, il n’aurait jamais su l’abomination qu’il avait engendrée.

Un héritage à transmettre

J’estime avoir été bien éduqué grâce à des communautés comme Alsacréations, Openweb ou A List Apart, qui ne jurent que par les standards et la qualité web. Ce que je viens de vivre avec ce stagiaire m’a furieusement rappelé la tempête qui a balayé le monde du web ces derniers mois, lorsque Firefox et Opéra annoncèrent avec une mine dépitée le support du préfixe vendeur -webkit- :

Tous les navigateurs veulent implémenter le préfixe -webkit- chez @HTeuMeuLeu ;
Call for action: the open web needs you now par Daniel Glazman ;
Bonnes pratiques CSS : le Web ouvert a besoin de vous par fvsch sur Alsacréations ;
Vendor prefixes, the CSS WG and me par Lea Verou.

La même erreur semble se répéter, simplement parce que les nouveaux arrivants — dont je fais partie — n’ont pas appris leur leçon d’histoire. Nous devons continuer à apprendre et enseigner : les bonnes pratiques ne vont pas de soi, elles s’apprennent et se découvrent au détour d’un blog. Rédiger un code source valide et réaliser une intégration de qualité en font partie et ne sont que les premières étapes.

Je pratique l’amélioration perpétuelle —pas progressive, perpétuelle.

Les sprites en réserve

Gaël Poupard — Thu, 21 Jun 2012 12:48:38 GMT

L’utilisation des sprites est connue de – presque – tous. Et dans le cas ou vous feriez partie du presque, voici un très bon article en français sur le sujet. Ma réflexion aujourd’hui ne portera donc pas sur l’intérêt des sprites, mais sur une façon de pousser plus loin la quête du moindre octet.

La Genèse

Ce jour-là, je me suis heurté au problème suivant : une vaste iconographie en aplat coloré, dont chaque élément disposait de trois variations colorées. Pour des questions de performances, il était nécessaire d’utiliser un sprite ; et la ou ça se complique, c’est qu’il était également question d’accessibilité.

Mon premier écueil : la performance. Afin d’intégrer les variations colorées, mon premier sprite contenait trois fois chaque icône. Pas très efficace…

Et la lumière fut

C’est alors que j’ai réalisé : ces icônes étaient systématiquement sur un fond blanc. Eurêka.

En précisant un peu mes recherches, je suis tombé sur “Transparent CSS Sprites” par Trevor Morris. L’idée est simple : puisque la seule variation est la couleur de l’icône elle-même, il suffit de créer ce sprite en réservant la forme des icônes, ou plus simplement : en négatif. Voila un exemple plus concret :

Alors, heureux ?

Tout est alors plus simple. Survolez cette image afin de vous en rendre compte, et observez-la dans votre outil de dev ou dans un nouvel onglet. Il suffit d’appliquer un background-color à cette image et de le changer au :hover afin d’obtenir le même résultat qu’un déplacement du sprite. Le code – allégé en matière grasse :

img { background: #269; transition: all .3s linear; } img:hover { background: #045175; }

Cette solution présente de multiples avantages :

une image en deux couleurs est plus légère. On peut l’optimiser en png-8 et 2 couleurs, voire en .gif. ( Attention cependant aux transparences relatives ).
la simplicité des interactions : background suffit. Une seule et même position pour chaque pictogramme !
chaque icône n’est présente qu’une seule fois !

Performance :

Mon second écueil : l’accessibilité.

Qui dit sprite dit sprite

Effectivement, il reste nécessaire de “recadrer” ce sprite. Usuellement, on le fait via css en appelant le sprite dans une background-image. Le hic : sans texte d’accompagnement, ce n’est vraiment, vraiment pas accessible. La seule solution : une balise < img / >.

On peut le faire de façon très simple : un parent conteneur aux dimensions fixes et un overflow hidden. Il ne reste plus qu’à déplacer l’image au sein de ce parent grâce à d’une position relative :

Le-super-sprite-de-la-mort-qui-tue

Rien de plus simple !
Accessibilité :

Pour conclure, la solution qui émerge est :

utiliser un parent conteneur auquel on confère des dimensions et un overflow:hidden
appeler le sprite dans une balise < img / >, au sein de ce conteneur
lui attribuer une classe pour définir l’icône précise – à laquelle correspondra une position.

Cette technique repose sur certains pré-requis :

des pictogrammes en aplats ou en dégradés – gérables avec background-color et background-image ;
un contexte visuel uniforme – ce superbe bleu uni dans mon exemple ;
la possibilité d’ajouter un conteneur pour gérer l’overflow et le positionnement relatif.

À titre personnel, je n’ai utilisé cette technique que sur un projet, particulièrement contraignant en terme de performances et d’accessibilité – mais je compte l’étendre à d’autres projets. Correctement utilisée, elle peut permettre une optimisation massive d’une iconographie riche – mais simple.

Vitesse & Précipitation

Gaël Poupard — Fri, 18 May 2012 17:02:06 GMT

Les transitions représentent une formidable avancée en matière de CSS, dans le but de s’affranchir du javascript pour les interactions simples. Je ne vais pas vous faire l’offense de vous présenter les transitions CSS, mais avant d’évoquer le sujet principal, j’aimerais faire une piqûre de rappel sur les origines des transitions.

Au commencement

Dans une époque ( pas si ) reculée, javascript était indispensable dès lors qu’on envisageait une interaction. Dan Cederholm s’en souvient dans son livre « CSS3 FOR WEBDESIGNERS » disponible en Français aux éditions Eyrolles.

It was 1997 and I was sitting in a terribly run-down apartment in beautiful Allston, Massachusetts. A typical late night of viewing source and teaching myself HTML followed a day of packing CDs at a local record label for peanuts (hence the run-down apartment). I’m sure you can relate.

One triumphant night, I pumped my fist in sweet victory. I’d just successfully coded my first JavaScript image rollover. Remember those?

I still remember the amazement of seeing a crudely designed button graphic I’d cobbled together “swap” to a different one when hovered over by the mouse. I barely had a clue as to what I was doing at the time, but making something on the page successfully change, dynamically, was, well…magical.

Le :hover a été une première bénédiction – malgré ses différends avec IE7 – et on a enfin pu se passer de javascript pour les roll-over. Les transitions constituent une nouvelle étape dans l’évolution des interactions, mais comme toute avancée il faut d’abord essuyer les plâtres.

Sans transition, le problème :

Si l’utilisation des transitions est claire et limpide, leur présence au sein du CSS implique une nouvelle dimension : le temps. Hors vous n’êtes pas sans savoir qu’une page web, ça met du temps à se charger. Pas beaucoup certes, mais suffisamment pour que le chargement soit perceptible à l’œil nu.

Hors comme le décrit Chris Coyier dans son article, lorsqu’une page se charge elle se dessine progressivement. Certains éléments sont déplacés via CSS – à l’aide de position, float ou margin pour ne citer qu’eux. Concrètement, votre navigateur place d’abord ces éléments dans le flux, puis les déplace à l’endroit spécifié en CSS ; c’est la que le bas blesse, puisque si ces éléments sont dotés de transition, on les voit se positionner.

Ces pauvres navigateurs n’y peuvent rien. Il leur faudrait prioriser l’application des CSS par couches : grille de positionnement, aspect visuel, puis dimension temporelle… Pas besoin d’être expert pour comprendre la difficulté. Mais en l’état, il y a confusion entre vitesse et précipitation.

Temporisation

L’article « Transitions only after page load » sur Css-Tricks inclut la solution proposée par Chris Coyier, très simple : une classe preload annule les transitions, et lorsque la page est chargée on la retire via Jquery. C’est extrêmement futé ! Mais elle implique de charger Jquery et ça, c’est dommage.

J’ai donc entrepris d’effectuer la même action, mais en javascript pur. Quelques interférences font varier le fonctionnement, comme par exemple l’impossibilité ( à ma connaissance ) de cibler une valeur dans un attribut. Or mon attribut « class » m’est utile : j’ai donc préféré utiliser un id. La syntaxe javascript, insérée juste avant la fermeture du body, est la suivante :

// <![CDATA[ function init() { « use strict »; document.getElementById(« preload »).removeAttribute(« id »); } window.onload = init; // ]]>

Et c’est tout ! Pas besoin de librairie ou framework : juste 5 lignes à la fin du corps du document, et le tour est joué.

Contrepartie

J’ai remarqué un problème de compatibilité avec IE8 et Safari, tandis que les autres navigateurs appliquent parfaitement ce code. Ce n’est qu’un demi-problème puisque de toute façon, IE8 ne comprend pas les transitions. C’est un peu plus gênant pour Safari, mais je n’ai pas encore trouvé l’astuce : si quelqu’un en connaît une ou en trouve une, je suis preneur !!

La schizophrénie sémantique

Gaël Poupard — Fri, 11 May 2012 19:19:25 GMT

Comme beaucoup d’intégrateurs, je me suis heurté à la schizophrénie sémantique du logo. Vous rêvez de l’inclure dans un h1 plein de bon texte pour le SEO, mais m**d* ! Votre logo est une image.

Que dois-je faire, Docteur ?

De nombreux remèdes ont vu le jour pour combattre ce symptôme, à tel point que l’excellent Chris Coyier en a érigé un mémorial.
De mon côté, j’ai beaucoup apprécié l’élégance et la légèreté de la proposition de Nicolas Gallagher, notamment utilisée dans le fameux HTML5 Boilerplate. Et c’est cette option que j’utilise et recommande.

Mais ça démange encore !

Il reste un symptôme gênant : l’image elle-même. On se retrouve avec un fichier à charger – et donc une requête HTTP supplémentaire – et qui nécessitera de refaire l’image en cas de modification. Ennuyeux. Mais deux techniques supplémentaires viennent à notre rescousse : @font-face et base64.

@font-face

Une astuce relativement simple a vu le jour récemment, qui permet d’incorporer des images dans un seul fichier et pouvoir les styler via CSS : les icon-fonts. Cette technique est plébiscitée en ce moment, et j’ai donc eu tout le loisir de me documenter :

Icon Fonts are Awesome de Chris Coyier
Icon Fonts de Trent Walton
Displaying Icons with Fonts and Data- Attributes de John Hicks
ICÔNES “@FONT-FACE” ET ACCESSIBILITÉ par Raphaël Goetter

Certains points sont abordés, notamment pourquoi le SVG ne suffit pas actuellement ( indice : IE8 ) mais aussi la question de l’accessibilité. J’ai d’abord été attiré par l’implémentation de Trent Walton de son logo. Mais dans une correction de son billet, Raphaël Goetter a ajouté une proposition de Keyamoon pour son outil IcoMoon. Cette solution est particulièrement propre car il s’agit simplement d’ajouter un attribut à la balise visée. J’adopte !

À noter cependant : pour inclure une image dans une typographie, il est nécessaire de disposer d’un outil efficace – et ça n’est pas si simple. Il existe un tutoriel intéressant pour y parvenir, ou encore le site Fontstruct qui vous permet de dessiner directement vos caractères.

Je tiens à remercier Damien Collot pour l’aide qu’il m’a apporté sur le sujet.

Base64

Au fil de mes pérégrinations, j’ai un jour remarqué cette option sur le générateur de kits @font-face de font-squirrel : encoder en Base64. Quelques rapides recherches – et cet excellent article sur Alsacréations – m’ont appris qu’encoder un petit fichier en Base64 permettait d’économiser une requête HTTP : Eurêka !

Résultat

Ne cherchez plus, c’est la technique que j’ai utilisée sur le logo de ce site. En HTML cela donne simplement :


<h1>
  <a data-icon="a">Gaël Poupard</a>
</h1>

et en css :


@font-face {
  font-family: ’logo’;
  src: url(’font/logo.eot’);
  src: local(’?’), url(data:font/woff;charset=utf-8;base64,...;
  font-weight: normal;
  font-style: normal;
}
h1 a {
  font: 0/0 a;
  text-decoration: none;
}
h1 a:before {
  content: attr(data-icon);
  font: 200px/250px ’logo’;
  text-decoration: none;
}

Et c’est tout ! Le résultat est particulièrement propre et simple. Il nécessite un travail préparatoire assez long, mais c’est une mécanique intéressante à connaître.

Conclusion

Trois techniques relativement avancées permettent d’obtenir cet excellent résultat. Le logo est :

encodé en Base64 : pas de requête HTTP
appelé via @font-face : maniable en CSS
inclus dans un h1 : sémantiquement intéressant
dispose d’un texte de remplacement pertinent : optimisé pour le référencement

Le principal inconvénient est le support d’IE8 : il ne reconnaît que les fichiers .eot dans @font-face, ce qui nous force à ajouter un fichier .eot difficile à convertir en Base64. Mais si vous pouvez m’y aider, je suis tout ouï !

Que se passerait-il ?

Gaël Poupard — Thu, 01 Sep 2011 18:21:45 GMT

Qu’adviendrait-il du web si chaque personne impliquée dans la création de sites internet demandait à tous ses contacts de mettre à jour son navigateur ?

Léa Verou a publié un message intéréssant ici, il y a déjà quelques mois. Il reflète bien le dédain frappant les « techies » à l’approche d’un client qui navigue sur IE8 : j’ai moi-même souvent pesté contre ces idiots incapables de mettre leur navigateur à jour gens. Le message de Léa Verou m’a appris qu’ils ne pêchent que par innocence : la plupart des gens sont certainement prêts à faire leur MAJ si on leur apprend qu’ils le peuvent.

Imaginez la conquête inouïe lorsque chaque personne – graphiste, intégrateur, développeur, référenceur, chef de projet, stagiaire, administrateur réseaux, consultant, patron… – aura demandé à travers l’ensemble de ses réseaux sociaux – mails, facebook, twitter, viadéo… – à toutes ses connaissances de mettre son navigateur favori à jour ?

Personnellement, j’ai fait le calcul : je peux faire cette demande à 493 personnes distinctes. Si chacune des neuf personnes de mon agence atteint ce même chiffre; nous serons déjà à 4437 personnes.

Ne pensez-vous pas que ça puisse suffire à changer les statistiques ?

Sémantique de l’interaction

Gaël Poupard — Sat, 05 Mar 2011 12:52:36 GMT

Saviez-vous que le langage entre êtres humains dépend à 80% des expressions physiques – même infimes ? Il en va de même pour les sites internet. Un internaute ressent – et comprend – un site grâce à son comportement : mouvements, animations, changements de couleurs, etc…

Les sites ont des sentiments, eux aussi

Et ils s’expriment afin de vous les transmettre : un décalage léger au survol, un changement subtil de couleur et une sensation de souffle vous parvient. Le site respire, s’agite, réagit. Il peut être d’une douceur surprenante comme d’une agressivité détonante, et rien ne l’empêche d’être incohérent – voire complétement fou. Ces caractéristiques, qu’elles soient maîtrisées ou non, ont un impact sur l’utilisation du site : les sensations varient, et par conséquent le confort de navigation, l’impression donnée, l’affection éprouvée par l’internaute varient eux aussi.

Mais soyez prudents : cela peut rendre votre site extrêmement attractif ou définitivement désagréable. Là encore, le même mécanisme opère – que l’on parle d’êtres humains ou de site : la première impression est déterminante.

Au-delà de la technique

Il vous incombe de penser à cet aspect du site. D’après une ligne directrice ( le plus souvent décidée dans un brief créatif ), vous devez pouvoir déterminer ce qu’exprimera le site. Doit-il être sympathique, serein, énergique…?

Vous disposez alors de tout un panel de techniques css afin d’aboutir au résultat escompté, en veillant à ne pas produire de contresens. Vous pouvez vous pencher sur les transitions, les transformations, les animations ou encore les changements de couleurs pour arriver à vos fins. Les plus utiles seront malgré tout les pseudo-classes :hover et :focus.

Le :hover pour la suggestion

Prenons l’exemple d’un accordéon.

Il est de bon ton d’indiquer visuellement l’existence de l’accordéon par une flèche vers le bas, ou encore un « + ». On ajoute en général au :hover un curseur pointeur, qui suggère l’interaction potentielle avec cet élément.

Ceci est le comportement classique : il induit pour l’internaute que s’il clique à cet endroit, quelque chose se passera. Pourquoi ne pas pousser un peu plus loin cette suggestion ?

Suspense !! Que va-t’il se passer si je clique ?

Dans cet exemple, on suggère effectivement l’interaction mais on dévoile également l’étape suivante. Dévoiler pour attirer l’action : il s’agit du mécanisme de la séduction.

Le :focus pour la signalisation

L’intérêt majeur du :focus concerne les éléments de formulaires : il permet d’indiquer quel est le champ sélectionné ( à savoir : celui qui se remplira si on pianote sur son clavier, même debout ). C’est peut-être un détail pour vous, mais c’est un facteur déterminant lors de la saisie d’un formulaire. Et sémantiquement parlant, cela signifie que le site est attentif à vous et à ce que vous souhaitez.

Le comportement basique des navigateurs basés sur Webkit est d’appliquer une ombre portée lors du :focus. Il s’agit d’un minimum syndical – dont le seul but est la signalisation de l’état – et n’a aucune prétention de communication. Malheureusement une partie sémantique est comprise dans les css, dont le choix des intitulés des pseudo-classes. Focus signifie, dans la langue de Shakespeare, concentration, mise au point. Hors appliquer une ombre portée est l’exacte inverse : cela rend la forme diffuse.

Voila ce que donnerait le comportement inverse :

une ombre portée qui s’intensifie au :hover, et disparait au :focus. Saupoudrez-y un peu de transition, et ce champ qui réagit à votre passage semble réellement faire une mise au point lorsque vous le sélectionnez. L’ombre est aspirée de manière fluide, et ce champ grossier devient organique, vivant. Il vous écoute.

Toujours plus loin

Au-delà de la métaphore du vivant, ces interactions basiques définissent la personnalité d’un site : il convient alors de maîtriser ces aspects afin d’améliorer l’expérience utilisateur en véhiculant des sentiments. C’est que je tente humblement de faire sur ce site, en amenant un peu de fraîcheur et de surprise sur chaque page.

Cette problématique me donne matière à réflexion tous les jours, mais par bonheur certains grands designers m’inspirent régulièrement. Voici deux articles et un livre qui m’ont particulièrement intéressé sur le sujet :

Dessine-moi un bouton

Gaël Poupard — Sun, 31 Oct 2010 19:54:49 GMT

Les boutons sont des éléments capitaux du graphisme web : ils appellent, suggèrent et provoquent l’action. Autrefois, les liens hypertextes étaient l’emblème des interactions : aujourd’hui, ce sont les boutons.

Une espèce animale

Il en existe de toute sorte : des grands, des petits, des noirs, des jaunes, des visuels et des textuels… Chaque bouton que vous pouvez imaginer existe certainement déjà quelque part.

Pour caractériser un bouton, on dispose de multiples critères : sa palette de couleur, sa forme, son volume, sa réaction au survol, son contenu, sa cible… Et comme nous, il a des mensurations : sa taille et son poids. On pourrait s’amuser à rédiger un bestiaire des boutons, les classer par espèces et déterminer si certaines sont en voie d’extinction ou d’expansion – mais ce sera pour un autre jour.

L’importance de l’environnement

L’impact – et donc l’intérêt – d’un bouton dépend autant de lui que de son environnement. Ce dernier détermine l’espace disponible, la liberté de mouvements – mais c’est également de lui dont dépend le caractère du bouton : s’il est discret ou exubérant, calme ou agité, agressif ou doux comme un agneau…

Le sens de la vie

Pour certains, ce sera 42 ; pour tous les autres, il faudra se définir un rôle afin de donner un sens à sa vie. Les boutons ont également une raison d’être là – et c’est vous, son créateur, qui devez la lui fournir. Quelle est sa raison d’être ?

Ne vous y trompez pas : pour ce bouton qui vient de naître, vous êtes Dieu le père. Vous venez de le créer, et vous allez décider de qui il sera : un séducteur, un commercial, un évangéliste, un élu, un fonctionnaire…

La guerre des boutons

Un bouton doit être une solution, pas un problème : s’il n’est pas utilisé avec modération il perd sa valeur d’appel à action. Car s’il y a de l’action partout, vous faites un feu d’artifice, pas un site web.

Un site internet est un véritable microcosme, et la plupart des lois de la nature y sont applicables. Y compris l’évolution.

Dessine-moi un bouton

Gaël Poupard — Sun, 31 Oct 2010 19:54:49 GMT

Une espèce animale

Il en existe de toute sorte : des grands, des petits, des noirs, des jaunes, des visuels et des textuels… Chaque bouton que vous pouvez imaginer existe certainement déjà quelque part.

L’importance de l’environnement

Le sens de la vie

La guerre des boutons

Un site internet est un véritable microcosme, et la plupart des lois de la nature y sont applicables. Y compris l’évolution.

La vie en #ffoodd

Masquage accessible de pointe

Un cas légendaire

En cas de débordement

La totale

25e jour de web

Le calendrier

Les Blobs

Les boules de Noël

Les animations

Les boules de Noël en CSS

Motion path

Retour aux transformations

L’entête

Les animations SVG

Désactiver les animations

Mais… WebKit

CSS dans SVG dans CSS

L’origine des animations CSS dans un SVG

Oui, mais…

Plot twist : les performances

Au-delà des préférences

Un bouton pour les interrompre toutes

Une pincée de JavaScript

Un état personnalisé en CSS

Bilan

Les astuces derrière « l’Invasion du HTML mutant »

La mécanique du jeu

Les particularités de <dialog>

Ouvrir la fenêtre

Sans JavaScript externe

Aparté : la projection des identifiants HTML en objets globaux

Accessibilité

L’arrière-plan

Les dimensions

Fermer la fenêtre

Les émojis

Les personnages

La personnalisation

Les décors

Les navigateurs

WebKit

La coloration syntaxique sans JS

Les Space Invaders

Les compteurs

WebKit (encore)

Les couleurs

Les Web Components

Conclusion

Note

Mon épopée au devQuest

Le folklore du devQuest

Les récits de la tradition orale

Level up ta conf

Arrêtons de (dé)tester nos applications

Ne jouez plus solo

Chrome Devtools from zero to hero

Dédramatisons l’accessibilité

La récompense de la quête

HTML comme fondation

details et summary comme base pour le motif de conception disclosure

output comme une live region

Une live region particulière : le toast !

Une boîte de dialog

Conclusion

L’état des champs

Le souci

L’état indéterminé

Le brouillon du module 4 des sélecteurs

Un contournement possible

Remarques post-publication

Pourquoi pas :not()

Au final

Un précédent

Calculez

Les décimales arbitraires

La précision

Les arrondis et la troncature

La fonction calc

Compatibilité

25^e jour de web

Les particularités de `<dialog>`

`details` et `summary` comme base pour le motif de conception disclosure

`output` comme une live region

Une boîte de `dialog`

Pourquoi pas `:not()`