Plus sur la visibilité du contenu

Attributs content-visibility du CSS: Modifications des performances et défis de l'accessibilité

En août 2020, l'attribut content-visibility de CSS a commencé à être utilisé dans les navigateurs de Chrome, et Una Kravets et Vladimir Levin ont écrit un article à ce sujet. Pour utiliser pleinement ses avantages de performance, il doit être utilisé en conjonction avec contain-intrinsic-size , qui nécessite une estimation de la hauteur de gros morceaux de contenu dans la page. La partie la plus étrange est que vous devez faire une supposition approximative de la hauteur de ces gros morceaux.

J'ai déjà posé une question: devinez la hauteur? Que se passe-t-il si la supposition est mauvaise? Cela affectera-t-il les performances? S'il y a une grande différence entre un grand écran et un petit écran, cette valeur (ou devrait-elle) être modifiée dans une fenêtre différente?

Jake Archibald et Das Surma ont récemment réalisé une vidéo pour clarifier ces problèmes. À environ 7 minutes et 30 secondes de la vidéo, vous pouvez voir à quel point cela est confus. Jake a utilisé une grande page de spécification HTML comme démonstration et a ajouté un wrapper pour de gros morceaux de contenu HTML, et a appliqué le code suivant:

 section {
  Contenu-visibilité: Auto; / * Dessin de retard * /
  Contient la taille de la taille de l'effort: 1px 5000px; / * devinez la taille du contenu, la largeur n'a pas d'importance * /
}

De toute évidence, 5000px n'est pas la hauteur de l'élément, mais la taille du contenu de cet élément. Ceci est important car il augmente la hauteur de l'élément parent à cette valeur, sauf si l'élément parent le remplace avec son propre attribut de hauteur. La magie de ceci est que le navigateur ne tirera que la première section (la hauteur de la fenêtre est susceptible d'être inférieure à 5000px) et le dessin de retard du reste. C'est un peu comme un chargement paresseux, mais cela fonctionne sur tout, pas seulement sur les médias. Il suppose que la section suivante a une hauteur de 5000px, mais une fois que son haut est visible, il est réellement dessiné et la hauteur correcte est déterminée. Donc, si votre page n'est que de grands blocs de contenu empilés, l'utilisation d'un très grand nombre devrait bien fonctionner. Si votre site Web est plus compliqué que cela, soyez heureux.

Ceci est une excellente vidéo que vous devriez consulter: lien vidéo

Ceci est un autre exemple de ce qui vous oblige à fournir aux informations du site Web à votre navigateur afin qu'il puisse améliorer les performances. Le navigateur lui-même peut trouver ces informations, mais cela ne peut être fait qu'après avoir effectué des opérations avec des coûts de performance. Vous devez donc le dire à l'avance, évitant ainsi certains types de travail supplémentaire. Pour les images réactives, si nous utilisons l'attribut srcset pour fournir des images et dire au navigateur à l'avance leur taille, y compris un attribut sizes contenant des informations sur le comportement CSS, il peut être calculé à l'avance et seules les meilleures images sont téléchargées. De même, pour will-change dans CSS, nous pouvons dire au navigateur à l'avance que nous ferons le déménagement afin qu'il puisse être pré-optimisé, sinon il ne peut pas le faire. C'est compréhensible, mais un peu ennuyeux. C'est comme si nous avions besoin d'un fichier stuff-you-need-to-know.manifest à lui être fourni avant que le navigateur ne fasse autre chose - mais ce serait une demande supplémentaire!

Les problèmes d'accessibilité sont également importants. Steve Faulkner a testé en appliquant content-visibility: auto aux images et paragraphes:

Le contenu est visuellement caché, mais dans Jaws et NVDA, des images cachées sont annoncées, mais le contenu de l'élément n'est pas annoncé. Ceci est lié à la façon dont le contenu des éléments d'image et de paragraphe est représenté dans l'arborescence d'accessibilité du navigateur: l'image s'affiche dans l'arborescence d'accessibilité avec le texte ALT comme nom d'accessibilité. Le contenu des éléments de paragraphe n'est pas dans l'arbre d'accessibilité.

Il a noté que par les spécifications, le contenu caché de cette manière ne devrait pas être fourni pour filtrer les lecteurs. Je peux comprendre les deux cas, comme cacher tout comme display: none , ce qui signifie que rien n'est dans l'arborescence d'accessibilité. Ou, gardez tout dans l'arbre d'accessibilité. Maintenant, il est dans un état intermédiaire, vous pourriez voir un tas d'images isolées dans l'arborescence d'accessibilité sans autre contexte à l'exception de leur texte alt. Ceci est un exemple intéressant de la nouvelle technologie introduite peut être plus rugueuse que vous ne voudriez voir.

En parlant de textes ALT, nous savons tous qu'ils ne devraient pas être vides lorsqu'ils représentent des choses importantes qui doivent être décrites aux personnes qui ne peuvent pas les voir. Dave dit qu'ils devraient être comme des paragraphes :

J'ai finalement établi la connexion la plus simple: le texte alt est comme un paragraphe. Images de texte. Je sais que c'est basique, mais cela m'aide à comprendre comment écrire un bon texte alt et l'ordre source de mon code.

Je ne veux pas être trop négatif ici! Les gains de performances pour mettre en place de longues pages de défilement avec des attributs content-visibility sont énormes, ce qui est génial. Il est bon de pouvoir utiliser deux lignes de code pour dire au navigateur ce qui ne peut pas être dessiné.

1. Je continue de dire "dessiner" mais je ne sais pas si c'est vraiment le bon terme ou si cela signifie plus spécifique. La spécification mentionne des choses comme "Permettre aux agents des utilisateurs d'omettre potentiellement beaucoup de travail et de travail avant qu'ils n'en aient besoin" (mettant l'accent sur le mien).

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!