More on content-visibility

content-visibility attributes of CSS: Performance improvement and accessibility challenges

In August 2020, the content-visibility attribute of CSS began to be used in Chrome browsers, and Una Kravets and Vladimir Levin wrote an article about it. To fully utilize its performance advantages, it needs to be used in conjunction with contain-intrinsic-size property, which requires an estimate of the height of large chunks of content in the page. The strangest part of this is that you need to make an approximate guess about the height of these large chunks.

I've asked a question before: Just guess height? What happens if the guess is wrong? Will it affect performance? If there is a big difference between a large screen and a small screen, is this value (or should) be changed in a different viewport?

Jake Archibald and Das Surma recently made a video to clarify these issues. At about 7 minutes and 30 seconds of the video, you can see how confusing this is. Jake used a large HTML specification page as a demonstration and added a wrapper for large chunks of HTML content, and applied the following code:

 section {
  content-visibility: auto; /* Delay drawing*/
  contains-intrinsic-size: 1px 5000px; /* guess the content size, width doesn't matter*/
}

Obviously, 5000px is not the height of the element, but the size of the content of that element. This is important because it increases the height of the parent element to this value unless the parent element overrides it with its own height attribute. The magic of this is that the browser will only draw the first section (the viewport height is likely to be less than 5000px) and delay drawing of the rest. It's a bit like lazy loading, but it works on everything, not just the media. It assumes the next section has a height of 5000px, but once its top is visible, it is actually drawn and the correct height is determined. So if your page is just large blocks of content stacked together, using a very large number should work fine. If your website is more complicated than this, then be happy.

This is a great video you should check out: Video link

This is another example of what requires you to provide your browser with website information so that it can improve performance. The browser itself can find this information, but it can only be done after performing operations with performance costs. So you have to tell it in advance, thus avoiding some types of extra work. For responsive images, if we use the srcset attribute to provide images and tell the browser in advance their size, including a sizes attribute containing CSS behavior information, it can be calculated in advance and only the best images are downloaded. Similarly, for will-change property in CSS, we can tell the browser in advance that we will do the move so that it can be pre-optimized, otherwise it cannot do this. This is understandable, but a little boring. It's like we need a stuff-you-need-to-know.manifest file to be provided to it before the browser does anything else - but that would be an extra request!

Accessibility issues are also important. Steve Faulkner tested applying content-visibility: auto to images and paragraphs:

Content is visually hidden, but in JAWS and NVDA, hidden images are announced, but the content of the element is not announced. This is related to how the content of the image and paragraph elements are represented in the browser accessibility tree: the image is displayed in the accessibility tree with alt text as the accessibility name. The content of paragraph elements is not in the accessibility tree.

He noted that by the specification, content hidden in this way should not be provided to screen readers. I can understand both cases, such as hiding everything like display: none , which means nothing is in the accessibility tree. Or, keep everything in the accessibility tree. Now it's in an intermediate state, you might see a bunch of isolated images in the accessibility tree without any other context except their alt text. This is an interesting example of the new technology being introduced may be rougher than you would like to see.

Speaking of alt texts, we all know that they should not be empty when they represent important things that need to be described to people who cannot see them. Dave says they should be like paragraphs :

I finally made the simplest connection: the alt text is like a paragraph. Text pictures. I know this is basic, but it helps me understand how to write good alt text and the source order of my code.

I don't want to be too negative here! The performance gains for setting up long scrolling pages with content-visibility attributes are huge, which is great. It is good to be able to use two lines of code to tell the browser what can be not drawn.

1. I keep saying "draw" but I don't know if this is really the right term or if it means more specific. The specification mentions things like "allowing user agents to potentially omit a lot of layout and rendering work before they need it" (emphasizing mine).

The above is the detailed content of More on content-visibility. For more information, please follow other related articles on the PHP Chinese website!