Un événement à part 2022 Denver terminé hier. Et même si je n'ai pas pu participer aux trois jours cette fois, j'ai rattrapé l'action d'hier - et c'était impressionnants. Je ne suis pas très social ou extraverti, mais c'était la première conférence à laquelle j'assistais depuis au moins deux ans, et voir des gens en personne était incroyablement rafraîchissant.
J'ai pris des notes, bien sûr ! J'ai pensé que je les posterais ici parce que le partage est bienveillant. Du moins, c'est ce que mon fils de six ans m'a dit l'autre jour en me demandant une bouchée de mon dessert hier soir.
Je vais décomposer cela par orateur. Avertissement juste: Je suis tout au sujet des notes manuscrites et un type plutôt visuel, donc mes notes ont tendance à être moins… structurées que la plupart. Et ces notes sont juste des choses qui m'ont marqué. Ce n'est peut-être même pas l'idée principale du présentateur, mais ils ont retenu mon attention !
Chris Coyier : Les sites Web sont bons maintenant
Chris a déjà donné cette conférence (nous l'avons lié la semaine dernière), mais cette fois-ci, il l'a considérablement élargi, en particulier avec des détails sur unités relatives au conteneur qui, combiné avec clamp(), permettent une réactivité plus précise car les valeurs sont relatives au conteneur plutôt qu'à la fenêtre d'affichage. Donc, vous savez comment nous utilisons souvent la largeur de la fenêtre (vh) unités pour le type de fluide ?
font-size: clamp(1rem, 1rem + 2vw, 2rem);Eh bien, nous pouvons utiliser une unité relative de conteneur comme requête de conteneur inline-size (cqi) à la place, où 1cqi est égal à 1 % de la taille en ligne du conteneur (voici le projet de spécification à ce sujet):
font-size: clamp(1rem, 1rem + 1cqi, 2rem);Chris a également beaucoup parlé des avantages de performance de hébergement à la périphérie. Probablement pas de surprise car il est code écrit à propos de ça ici plus que quelques fois. Même en tant que quelqu'un qui avait déjà lu ces articles, je n'ai honnêtement pas réalisé le concept complet de l'informatique à la périphérie.
L'idée est d'une simplicité trompeuse : les CDN mondiaux peuvent servir actif rapidement car ils les hébergent géographiquement proches de l'utilisateur. C'est une pratique assez courante pour servir des images raster. Mais il s'est étendu aux fichiers statiques, tels que les mêmes fichiers HTML, CSS et JavaScript qui alimentent un site - construisez-les à l'avance et servez les fichiers déjà compilés et optimisés à partir du CDN mondial rapide. C'est tout le concept Jamstack !
Mais que se passe-t-il si vous avez toujours besoin d'une réponse du serveur ? Ce n'est pas très tranchant, n'est-ce pas ? Eh bien, nous avons maintenant des gestionnaires capables de s'exécuter sur une seule URL pour récupérer des données à l'avance et les injecter avant le rendu - directement à partir du CDN. Bien sûr, il y a du travail supplémentaire en arrière-plan. Pourtant, le fait que nous puissions récupérer dynamiquement des données, les injecter, les pré-construire, les servir de manière statique à la demande, et le faire fonctionner géographiquement plus près de l'utilisateur rend cela extrêmement rapide.
Tolu Adegbite : comment gagner à l'ARIA et influencer l'accessibilité du Web
Bon sang, c'était une excellente présentation ! Tolu Adegbite m'a tellement appris sur WAI-ARIA que j'ai eu du mal à noter tous les joyaux qu'elle partageait - les rôles ! États! Étiquetage ! Descriptifs ! Tout était extraordinairement bien couvert, et des choses sur lesquelles je sais que je reviendrai encore et encore.
Mais une chose spécifique qui a attiré mon attention est l'accessibilité du SVG en ligne. Même si SVG est lié à d'autres types d'actifs de conception, le fait qu'il s'agisse d'un balisage en fin de compte le distingue car il n'est pas toujours identifié comme une image.
La technologie d'assistance est plus susceptible de lire le SVG en ligne comme une image en lui attribuant un rôle et une étiquette accessibles appropriés :
Miriam Suzanne : Couches en cascade de !mportance
Hé, un autre ancien de CSS-Tricks ! Miriam a consacré beaucoup de temps et d'efforts à la Spécification des couches en cascade. Elle a également écrit un grand guide à leur sujet ici à CSS-Tricks et en a parlé à An Event Apart.
Ce qui m'a le plus marqué, c'est l'ampleur d'un changement mental. Le concept n'est pas compliqué en soi. Déclarer @layer en haut du document CSS, répertoriez les calques par ordre de spécificité, puis écrivez des styles dans ces calques. Mais pour un vieux dinosaure comme moi qui écrit du CSS depuis un certain temps, je vais devoir m'habituer au fait que Cascade Layers permet à un simple sélecteur de classe de battre quelque chose qui exerce généralement une plus grande spécificité, comme une pièce d'identité.
🤯
Miriam a également rappelé à la salle que les couches en cascade ne sont qu'un des outils que nous avons dans notre boîte à outils de gestion de la spécificité, en plus des sélecteurs qui affectent la spécificité (par exemple, :is(), :where()et :has()).
Oh, et c'est une friandise intéressante. Alors que Miriam parcourait l'histoire de la spécificité dans CSS, elle a rappelé que !important a été initialement conçu comme un outil permettant aux utilisateurs de remplacer les styles d'agent utilisateur et d'auteur. Mais quelque part sur la ligne, nous l'avons adopté pour forcer les styles d'auteur au sommet. Les couches en cascade aident à supprimer les excuse besoin d'utiliser !important parce qu'ils nous donnent le pouvoir de "hiérarchiser les calques ainsi que le protéger l'héritage. »
C'est joliment dit, Myriam !
Dave Rupert : débloquer votre backlog d'accessibilité
Imaginez que vous vous réveilliez un jour avec des centaines de notifications GitHub concernant des problèmes signalés sur votre site. Où commencez-vous même? Peut-être fermer votre ordinateur portable et obtenir un canal radiculaire à la place ? C'est arrivé à Dave ! Un audit d'accessibilité automatisé a renvoyé une énorme pile d'erreurs et les a assignées comme tickets pour que Dave les corrige.
Mais il a remarqué une tendance après avoir pris une feuille de calcul Excel de ces problèmes, les déplaçant vers Notion pour une meilleure vue, masquant les colonnes inutiles, catégorisant tout et affichant les résultats dans des groupes logiques. La plupart des problèmes signalés étaient le même problème répété sur plusieurs pages. Ce n'est pas parce qu'un test automatisé renvoie une poignée d'erreurs qu'elles sont toutes uniques. Cela a réduit une bonne partie des billets.
Il a ensuite montré comment – avec relativement peu d'efforts – l'arriéré de problèmes avait diminué de près de 50 %.
Il y a beaucoup à glaner là-bas, notamment en ce qui concerne la façon dont nous traitons et organisons notre travail. La plus grande leçon pour moi, c'est quand Dave a dit que nous devions mettre l'accent sur les individus et les interactions plutôt que sur les processus et les outils. Des outils comme celui qui analyse les erreurs d'accessibilité sont utiles, mais ils ne racontent peut-être pas toute l'histoire. Plutôt que de les prendre au mot, cela vaut la peine de poser des questions et d'obtenir plus de contexte avant de plonger dans le désordre.
En prime, la réorganisation des problèmes dans Notion a permis à Dave de regrouper les problèmes d'une manière qui montre clairement les déficiences contre lesquelles son produit discriminait activement, lui donnant une plus grande empathie pour ces ratés et comment les hiérarchiser.
Une autre session virtuelle de Hui Jing Chen a couronné la journée, mais j'avoue que j'en ai manqué environ la moitié parce que j'avais une conversation dans le couloir. La conversation en valait la peine, même si je suis déçu d'avoir raté la présentation. Je regarderai la vidéo quand elle sera publiée !
