{"id":342681,"date":"2021-06-21T12:36:30","date_gmt":"2021-06-21T19:36:30","guid":{"rendered":"https:\/\/css-tricks.com\/?page_id=342681"},"modified":"2021-07-01T08:36:40","modified_gmt":"2021-07-01T15:36:40","slug":"content-visibility","status":"publish","type":"page","link":"https:\/\/css-tricks.com\/almanac\/properties\/c\/content-visibility\/","title":{"rendered":"content-visibility"},"content":{"rendered":"\n
The The main point of using The I mentioned above it\u2019s sort of similar to When the rule is removed, the browser has to render the element and its contents. With The note in the spec is clear on the accessibility of the The skipped contents<\/a> must not be accessible to user-agent features, such as find-in-page, tab-order navigation, etc., nor be selectable or focusable.<\/p><\/blockquote>\n\n\n You could think of this sort of like lazy loading<\/strong> for entire parts of the DOM.<\/p>\n\n\n\n If an element is below the fold, and has the Careful when using Conversely, the However, Unlike In addition, off-screen elements that have been hidden with CSS (e.g. You can imagine if large chunks of a web page are not rendered, the length of a scrollbar might indicate the page has much less content on it than it actually does. Alex Russell talks about (and has) solutions for this in his \u201ccontent-visiblity Without Jittery Scrollbars<\/a>\u201d post.<\/p>\n\n\n Again, this property is all about buying performance. The results can be significant. See this video with Jake Archibald and Surma where they implement it and see big changes:<\/p>\n\n\n\ncontent-visibility<\/code> property in CSS indicates to the browser whether or not an element\u2019s contents should be rendered at initial load time. So, as the browser starts loading content and is playing it on the screen, this property allows us to step in and tell the browser not<\/em> to load the contents of an element until it\u2019s needed. Think of it sort of<\/em> like lazy loading in the sense that an off-screen element\u2019s children are not rendered until they enter the viewport.<\/p>\n\n\n\n
.element {\n content-visibility: hidden;\n}<\/code><\/pre>\n\n\n\n
content-visibility<\/code> is performance. It can help to speed up page load because the browser is able to defer rendering elements that are not in the user\u2019s viewport until the user scrolls to them. The results can be dramatic. Here are the results of a performance test<\/a> that Una Kravets and Vladimir Levin put together showing the difference that
content-visibility<\/code> can make on a typical webpage.<\/p>\n\n\n\n
Syntax<\/h3>\n\n\n
content-visibility: [visible | auto | hidden];<\/code><\/pre>\n\n\n\n
visible<\/code><\/li>
Values<\/h3>\n\n\n
content-visibility<\/code> property accepts one of three values:<\/p>\n\n\n\n
hidden<\/code>: The element bypasses its contents (kind of similar to applying
display: none;<\/code> to the contents).<\/li>
visible<\/code>: There is no effect and the element is rendered as normal.<\/li>
auto<\/code>: The element has layout, style, and paint containment. The browser gets to determine if this content is relevant to the user and, if it isn\u2019t, then the browser will skip it. At the same time, the element is still focusable, selectable and accessible to things like tabbing and in-page search.<\/li><\/ul>\n\n\n
content-visibility: hidden;<\/code><\/h3>\n\n\n
display: none;<\/code> because the element is not painted to the page at all.<\/p>\n\n\n\n
content-visibility: hidden;<\/code>, however, the element is hidden, but its rendered state is cached<\/strong>. So when the rule is removed, the browser does not have to render the element from scratch. So you might use this on something that is hidden by default, but there is a high chance that you\u2019ll show it at some point in the lifecycle of the page (e.g. a commonly used modal). That way, the element loads much faster on subsequent visits when it does render.<\/p>\n\n\n\n
hidden<\/code> value:<\/p>\n\n\n\n
content-visibility: auto;<\/code><\/h3>\n\n\n
content-visibility: auto;<\/code> rule, the browser does not consider any of its contents. Hence, rendering for that element is skipped. As the user scrolls to the element, the browser paints its contents and the rendering is done soon enough for the user. The heuristics on when the browser decides to render are unclear and likely left up to the browser to decide.<\/p>\n\n\n
Accessibility concerns<\/h4>\n\n\n
content-visibility: hidden<\/code>. That not only tells the browser to skip an element from rendering on initial page load, but also removes the element from being read by assistive technology, like screen readers.<\/p>\n\n\n\n
auto<\/code> keyword tells the browser that an element\u2019s content isn\u2019t needed on initial page load as long as it\u2019s off screen. In other words, that element is skipped, just like it is when we use the
hidden<\/code> keyword.<\/p>\n\n\n\n
auto<\/code> also indicated that the element should still be available to the user<\/strong> rather than completely ignoring the element in the DOM. What this means is that the element and its content should be focusable, selectable, tabbable, and searchable via the browser\u2019s find-in-page feature. Again, the spec is super clear on that point:<\/p>\n\n\n\n
hidden<\/code>, the skipped contents must still be available as normal to user-agent features such as find-in-page, tab order navigation, etc., and must be focusable and selectable as normal.<\/p><\/blockquote>\n\n\n\n
display: none;<\/code>), should have
aria-hidden=\"true\"<\/code> applied to them since the browser has not rendered them. This way, they are still present in the accessibility tree.<\/p>\n\n\n
UX concerns<\/h4>\n\n\n
Performance<\/h4>\n\n\n