Más sobre visibilidad de contenido | Programar Plus

En agosto de 2020, cuando el content-visiblity La propiedad en CSS llegó a los navegadores Chrome, Una Kravets y Vladimir Levin escribieron sobre ella y la cubrimos. La parte más extraña es que para obtener el valor de rendimiento de él, lo empareja con contain-intrinsic-size en estos grandes trozos de la página donde inserta alguna suposición arbitraria en una altura. Escribí:

Esa parte me parece muy extraña. ¿Solo adivina la altura? ¿Y si me equivoco? ¿Puedo dañar el rendimiento? ¿Puedo (o debería) cambiar ese valor en diferentes ventanas gráficas si la diferencia de altura entre las pantallas pequeñas y grandes es drástica?

Jake Archibald y Das Surma acaban de hacer un video sobre todo esto y ayudó a aclararlo un poco. Puede ver alrededor de las 7:30 en lo confuso que es. Jake usó esta enorme página de especificaciones HTML como demostración e hizo <section> envoltorios alrededor de grandes trozos de HTML y se aplicaron:

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 */
}

Aparentemente, 5000px no es la altura del elemento, es el tamaño del contenido de ese elemento. Supongo que eso importa porque empujará ese elemento padre más alto en ese número, a menos que el elemento padre anule eso con una altura propia. La magia proviene del hecho de que el navegador solo pintará¹ la primera sección (donde es muy probable que la ventana gráfica no tenga más de 5000px de alto) y pospondrá la pintura en el resto. A Sorta le gusta la carga diferida, pero todo en lugar de solo los medios. Asume que la siguiente sección tiene 5000px de alto, pero una vez que la parte superior se vuelve visible, realmente se pintará y se sabrá la altura correcta. Entonces, asumiendo que su página es solo grandes bloques uno encima del otro, usar un número extremadamente grande debería funcionar bien allí. Buena suerte si su sitio es más complicado que eso, supongo.

Es un buen video y deberías verlo:

Esta es otra cosa en la que debe informar al navegador sobre su sitio para que pueda Do Performance Good ™. Es información que puede descubrir por sí misma, pero no hasta que haya hecho cosas que tengan un costo de rendimiento. Por lo tanto, debe decirlo desde el principio, lo que le permite evitar hacer ciertos tipos de trabajo. Con imágenes receptivas, si le damos a las imágenes un srcset atributo con imágenes y decirle al navegador de antemano qué tan grandes son, incluyendo un sizes atributo con información sobre cómo se comporta nuestro CSS, puede hacer cálculos con anticipación que solo descargan la mejor imagen posible. Asimismo, con el will-change en CSS, podemos decirle al navegador cuándo vamos a realizar un movimiento con anticipación para que pueda realizar una optimización previa para eso de una manera que no podría de otra manera. Es comprensible, pero un poco aburrido. Es como si necesitáramos un stuff-you-need-to-know.manifest para proporcionar a los navegadores antes de que haga cualquier otra cosa, ¡solo que sería una solicitud adicional!

Las implicaciones de accesibilidad también son importantes. Steve Faulkner hizo una prueba aplicando content-visibility: auto a imágenes y párrafos:

El contenido está oculto visualmente, pero tanto en JAWS como en NVDA lo oculto <img> se anuncia pero el contenido de la <p> elemento no lo es. Esto tiene que ver con la forma en que img y el p El contenido del elemento se representa en el árbol de accesibilidad del navegador: img está expuesto en el árbol de accesibilidad con el alt texto como nombre accesible. El contenido de la p elemento no está presente en el árbol de accesibilidad.

Señala que el contenido oculto de esta manera no debería estar disponible para los lectores de pantalla, según las especificaciones. Podía verlo ir de cualquier manera, como esconderlo todo como si fuera display: none, lo que significa que ninguno de ellos está en el árbol de accesibilidad. O déjelo todo en el árbol de accesibilidad. En este momento es un tweener en el que puede ver un montón de imágenes perdidas en el árbol de accesibilidad sin ningún otro contexto que no sea su alt texto. Este es un ejemplo interesante de nueva tecnología que sale con más asperezas de las que le gustaría ver.

Hablando de alt texto, todos sabemos que no deben estar vacíos cuando representan contenido importante que debe describirse a alguien que no puede verlos. Deben ser como párrafos, dice Dave:

Finalmente hice la más simple de todas las conexiones: alt el texto es como un párrafo. Imágenes de palabras. Básico lo sé, pero me ayuda a contextualizar cómo escribir bien. alt texto, así como el orden de origen de mi código.

¡No quiero ser demasiado negativo aquí! Las ganancias de rendimiento al configurar una página de desplazamiento largo con content-visibility es enorme y eso es increíble. Ser capaz de informar al navegador sobre lo que está bien no pintar en dos líneas de código es bastante bueno.

  1. Sigo diciendo “pintar”, pero no estoy seguro de si ese es realmente el término correcto o si significa algo más específico. La especificación dice cosas como “permitir que los agentes de usuario omitan potencialmente grandes franjas de trabajo de maquetación y renderizado hasta que sea necesario ”(énfasis mío).
(Visited 2 times, 1 visits today)