Catégories
Astuces et Design

En savoir plus sur la visibilité du contenu | Astuces CSS

De retour en août 2020, lorsque le content-visiblity La propriété CSS s'est infiltrée dans les navigateurs Chrome, Una Kravets et Vladimir Levin en ont parlé et nous l'avons couvert. La partie la plus étrange est que pour en tirer la valeur de performance, vous l'associez à contain-intrinsic-size sur ces gros morceaux de la page où vous insérez une estimation arbitraire à une hauteur. J'ai écrit:

Cette partie semble super bizarre pour moi. Devinez juste à une hauteur? Et si je me trompe? Puis-je nuire à la performance? Puis-je (ou devrais-je) modifier cette valeur dans différentes fenêtres si la différence de hauteur entre les petits et les grands écrans est drastique?

Jake Archibald et Das Surma viennent de faire une vidéo sur tout cela et cela a aidé à clarifier un peu cela. Vous pouvez voir à environ 7h30 à quel point c'est déroutant. Jake a utilisé cette énorme page de spécifications HTML comme démo et a fait

wrappers autour de gros morceaux de HTML, et appliqués:

section {
  content-visibility: auto; /* this is the thing that delays painting */
  contain-intrinsic-size: 1px 5000px; /* this is the guess at the height of the content, and also saying width doesn't matter */
}

Apparemment, 5 000 pixels n’est pas la hauteur de l’élément, c’est le taille du contenu de cet élément. Je suppose que cela compte parce que cela poussera cet élément parent plus haut de ce nombre, sauf si l'élément parent le remplace par une hauteur qui lui est propre. La magie vient du fait que le navigateur ne peindra que la première section (où il est très probable que la fenêtre ne dépasse pas 5000 px de haut) et reporte la peinture sur le reste. Sorta comme le chargement paresseux, mais tout plutôt que les seuls médias. Cela suppose que la section suivante mesure 5000 px de haut, mais une fois que le haut de celle-ci devient visible, elle sera réellement peinte et la hauteur correcte sera connue. Donc, en supposant que votre page ne soit que de gros blocs de cul les uns sur les autres, utiliser un nombre extrêmement grand devrait bien fonctionner. Bonne chance si votre site est plus compliqué que ça, je suppose.

C’est une bonne vidéo et vous devriez la regarder:

C'est encore une autre chose où vous devez informer le navigateur de votre site afin qu'il puisse faire une bonne performance ™. C'est de l'information qu'il pouvez comprendre par lui-même, mais pas avant d'avoir fait des choses qui ont un coût de performance. Il faut donc le dire à l'avance, lui permettant d'éviter de faire certains types de travail. Avec des images responsives, si nous donnons aux images un srcset attribut avec des images et dites au navigateur à l'avance leur taille, y compris un sizes attribut avec des informations sur le comportement de notre CSS, il peut faire des calculs à l'avance qui ne téléchargent que la meilleure image possible. De même, avec le will-change propriété en CSS, nous pouvons dire au navigateur quand nous allons faire un mouvement à l'avance afin qu'il puisse pré-optimiser pour cela d'une manière qu'il ne pourrait pas autrement. C’est compréhensible, mais un peu ennuyeux. C’est comme si nous avions besoin d’un stuff-you-need-to-know.manifest fichier à donner aux navigateurs avant de faire quoi que ce soit d'autre – seulement ce serait une demande supplémentaire!

Les implications en matière d'accessibilité sont également importantes. Steve Faulkner a fait un test d'application content-visibility: auto aux images et aux paragraphes:

Le contenu est visuellement masqué, mais dans JAWS et NVDA, le caché est annoncé mais le contenu du

élément ne l'est pas. Cela a à voir avec la façon dont le img et le p le contenu de l'élément est représenté dans l'arborescence d'accessibilité du navigateur: img est exposé dans l'arborescence d'accessibilité avec le alt texte comme nom accessible. Le contenu du p l'élément n'est pas présent dans l'arborescence d'accessibilité.

Il note que le contenu masqué de cette manière ne devrait pas être disponible pour les lecteurs d'écran, selon les spécifications. Je pouvais le voir aller dans les deux sens, comme cacher tout comme si c'était display: none, ce qui signifie que rien de tout cela n'est dans l'arborescence d'accessibilité. Ou laissez tout cela dans l'arborescence d'accessibilité. En ce moment, c'est un tweener où vous pouvez voir un tas d'images errantes dans l'arborescence d'accessibilité sans autre contexte que leur alt texte. Ceci est un exemple intéressant de nouvelle technologie qui sort avec plus d'aspects rugueux que vous aimeriez voir.

En parlant de alt texte, nous savons tous que ceux-ci ne doivent pas être vides lorsqu'ils représentent un contenu important qui doit être décrit à quelqu'un qui ne peut pas les voir. Ils devraient être comme des paragraphes, dit Dave:

J'ai finalement fait la plus simple de toutes les connexions: alt le texte est comme un paragraphe. Images de mots. Basique, je sais, mais cela m'aide à contextualiser comment écrire bien alt texte ainsi que l'ordre des sources de mon code.

Je ne veux pas être trop négatif ici! Les gains de performances pour la configuration d'une page à défilement long avec content-visibility est énorme et c'est impressionnant. Être en mesure d'informer le navigateur de ce qui est OK ne pas peindre en deux lignes de code est plutôt sympa.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *