Más sobre visibilidad del contenido

En agosto de 2020, cuando la content-visiblitypropiedad 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, lo emparejas con contain-intrinsic-sizeestas grandes partes de la página donde insertas algunas conjeturas arbitrarias en una altura. Escribí:

Esa parte me parece súper rara. ¿Adivina simplemente a qué altura? ¿Qué pasa si me equivoco? ¿Puedo perjudicar el rendimiento? ¿Puedo (o debería) cambiar ese valor en diferentes ventanas gráficas si la diferencia de altura entre pantallas pequeñas y grandes es drástica?

Jake Archibald y Das Surma acaban de hacer un vídeo sobre todo esto y ayudó a aclararlo un poco. Puedes ver alrededor de las 7:30 lo confuso que es. Jake usó esta enorme página de especificaciones HTML como demostración, creó sectionenvoltorios alrededor de grandes fragmentos de HTML y aplicó:

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 aumentará ese elemento principal en ese número, a menos que el elemento principal lo anule 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 5000 px de alto) y pospondrá la pintura en el resto. Algo así como carga diferida, pero todo en lugar de solo medios. Se supone que la siguiente sección tiene 5000 px de alto, pero una vez que la parte superior se vuelve visible, en realidad se pintará y se conocerá la altura correcta. Entonces, suponiendo que su página sean 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 vídeo y deberías verlo:

Esta es otra cosa en la que tienes que informar al navegador sobre tu sitio para que pueda realizar Do Performance Good™. Es información que puede descifrar por sí mismo, pero no hasta que haya hecho cosas que tengan un costo de rendimiento. Por lo tanto, hay que decírselo desde el principio, permitiéndole evitar realizar ciertos tipos de trabajo. Con imágenes responsivas, si le damos a las imágenes un srcsetatributo con imágenes y le decimos al navegador de antemano qué tan grandes son, incluyendo un sizesatributo con información sobre cómo se comporta nuestro CSS, puede hacer cálculos con anticipación que solo descargan la mejor imagen posible. Del mismo modo, con la will-changepropiedad en CSS, podemos indicarle al navegador cuándo vamos a realizar un movimiento con anticipación para que pueda optimizarlo previamente de una manera que no podría hacerlo de otra manera. Es comprensible, pero un poco aburrido. Es como si necesitáramos un stuff-you-need-to-know.manifestarchivo para entregar a los navegadores antes de hacer cualquier otra cosa, ¡solo que eso sería una solicitud adicional!

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

El contenido está oculto visualmente, pero tanto en JAWS como en NVDA se anuncia lo oculto pero no imgel contenido del elemento. pEsto tiene que ver con cómo se representan el contenido del elemento imgy en el árbol de accesibilidad del navegador : Se expone en el árbol de accesibilidad con el texto como nombre accesible . El contenido del elemento no está presente en el árbol de accesibilidad.pimgaltp

Señala que el contenido oculto de esta manera no debería estar disponible para los lectores de pantalla, según la especificación. Pude verlo en cualquier dirección, como ocultarlo todo como si fuera display: none, lo que significa que nada está en el árbol de accesibilidad. O déjelo todo en el árbol de accesibilidad. En este momento es una interpolación en la que es posible que veas un montón de imágenes perdidas en el árbol de accesibilidad sin ningún otro contexto que no sea su alttexto. Este es un ejemplo interesante de nueva tecnología que aparece con más asperezas de las que le gustaría ver.

Hablando de alttexto, todos sabemos que no deberían estar vacíos cuando representan contenido importante que debe describirse a alguien que no puede verlo. Deberían ser como párrafos , dice Dave :

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

¡No quiero ser demasiado negativo aquí! Las ganancias de rendimiento al configurar una página de desplazamiento largo content-visibilityson enormes y eso es asombroso . Poder 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 a los agentes de usuario omitir potencialmente grandes extensiones de trabajo de diseño y renderizado hasta que sea necesario” (el énfasis es mío).