The scroll bar jumping around like that does feel really jarring on desktop, especially on windows where the scrollbar is often visible. I can't help feel it would also be incredibly easy to lose your place if trying to scrub through a document to find something. There is obviously performance gains to be made here for large documents, so there is a good chance this trade-off is worth it, but I don't consider this "no big deal". Perhaps another enhancement to this that helps mitigate the issues (depending on the size of the document), is to remove these css properties on desktop with javascript after the page has fully loaded, or even incrementally on requestIdleCallback for really large documents. That way, you still get the benefit a first initial paint, but once that is done it finishes laying out the rest of the page so it's ready.
@@jakearchibald I guess for particularly large documents that resize performance is an issue, you could always add some sort of "onresize" event listener that re-adds the class that has these properties on it, and then debounce the removal of that class again after 1 second or however long is deemed suitable? I wouldn't be as concerned about the scroll bar changing during resize, as that happens anyways, and you aren't actively using it if you are resizing the window.
@spYro I think we're pretty much talking about the exact same solution here, just instead of the browser natively handling this for you, using javascript to remove the CSS that they are talking about in the video. For potential drawbacks, see the comment above by Jake. :)
Yeah it's a dealbreaker for me. A scrollbar is a user's only way to understand where they are in the document. Messing with that should always be a big "no-no".
We do it to help sync the audio for our editor Lukas. Although a few days ago he said "btw I don't use the clapping to sync the audio, but I didn't want to tell you because I've been enjoying the clapping so much"
We ship this in our app, specifically for a font dropdown menu that has to render several dozen different fonts. Setting content-visibility: auto to each menu item completely eliminated the occasional hang when showing the menu for the first time.
This is pretty cool, sounds like it could make a substantial difference to our webapp. Question - if a box has been in the view at some point, and thus has been fully laid out, will it retain its layout once it is out of view, e.g. for the purposes of the scrollbar. (obviously assuming its layout it not changed in any way)
oO does it also unlayout if the content is out of view ? - i mean it just means it odenst do the layout until its in view it doenst really guarantee that nothing breaks out of it right ? - like i could for example display a fixed header that is only visible when a certain section is in view or similar
We've discussed it briefly. Once the bug fixes to anchor linking hit stable, we'll look at it. Some folks are a little uncomfortable with the scrollbar thing, so they'll need convincing.
@@jakearchibald for the scroll bar thing maybe add a tween to the thumb position between the jumps or pause the thumb to let the scroll partition catch up. a UI designer can help resolve something like this. also if you do background layout you could have each section ready if someone scrolls. so if someone is reading from there to down everything could be laid out already. once a deferred section is laid out it does not need to be laid out again correct?
@@jakearchibald Or set the contain-intrinsic-sizes for each element using JS right at the start, using a lookup table for known calculated size estimates for each screen width.
@@jakearchibald I see this is still only supported in Chromium. I wonder if a “lazy” option would help encourage adoption elsewhere as a resolution to the scroll bar issue. Lazy could work just like auto, but would start laying out subsequent blocks in a lazy manner (i.e. when the main thread is not busy). This would result in most of the scroll bar changes occurring when the user is not scrolling. Similarly to page load, on viewport size changes, the browser would discard all of the blocks except the visible one, then slowly start building the surrounding blocks when the main thread is not busy. I think there are also some browser assumptions that could be made on resize to help reduce the scroll bar shift as well. The area (width*height) of a text area could be assumed to be constant. And the aspect ratio of all images could be assumed to be constant. So any blocks that have already have been laid out, the browser could guess what the new height is, overriding the css guess (assuming there isn’t a css media property that adjusts the intrinsic size for different widths).
I applied this on my feed. It works and the feed posts are fast now. However, this is causing screen flickering on my linux Chromium based browser. Tested it in 2 different linux laptops. It works fine on my mac.
I just tried it, and it did nothing for my load speed... jake is kinda weird at explaining things, he's funny, but he's not explaining to someone like me, so, am I supposed to put this on all elements, or only top level elements?
@@jakearchibald I just started automagically injecting contain:layout (I use floats) and contain:content through templates for large static pages. Have I been wasting my time? (No, I haven't found a good simple way to actually measure any effect of this blind 'optimisation' yet, shame on me.)
parent element set content-visibility auto，child element set position fixed， it renders a bit strange, the child element is not positioned relative to the initial containing block established by the viewport.
Jumpy scrollbar could be mitigated, but on any page with ads can lead to accidental click-throughs. Likely that won't bother Google though as they get paid via ads...
The W3C should really reach out to allow the dev community to vote and express feelings about the spec syntax before it ships. Jake and Surma are sitting here agreeing that the spec syntax for these new CSS rules is utterly confusing and confounding.
when i applied content-visibility:auto to all the sections in the container but the some content in the section like tooltip which have position:absolute is not visible completely.
Good timing, thanks for the video! I was looking at the status of the wicg yesterday and saw it was abandoned, display locking spec was to replace it. Content Visibility will be useful for list, especially when the size of the content is fixed. Looking forward to try it out!
You could probably mitigate the scrollbar issue with some preprocessing. Load the page and get the actual heights of the hidden elements, pull those values out and set them as the intrinsic heights. Tools could do that for you as part of a build step and generate some sensible values for various browsers and screen dimensions. Should be far better than straight up guessing, and even less work once you've got the pipeline set up.
It's a build step similar to minification or SASS compiling, it has no runtime penalty. Imagine doing this by hand, but instead a build tool does it for you: 1. Load up the page without setting content-visibility or contain-intrinsic-size in your stylesheet. 2. Note down the height of all elements that you plan to add content-visibility to. 3. Complete your stylesheets by adding content-visibility to all of those elements, and set contain-intrinsic-size to the values you noted down. Of course it's still just a guess since the actual height will vary between browsers, screen sizes, and for highly dynamic content that can't be preprocessed, but that's not the point. The point is to get a decent estimate so there is less scroll bar jank.
To account for browser sizes, you could generate the intrinsic heights as fractions of the viewport width based on the size used in build time. Wouldn't still be accurate though because browser width could also affect the rendered height.
I have agreed with Surma => its magic => You should write the BOOK how without BLACK MAGIC You Hide the content by using style. The Jake T-shirt logo displays the timeline of how this process was made step by step. Scroll horizontal ??? hmmm does it work as well? Does it CRAWLER friendly and does it impact SEO and DA ?
this will be nice when i works correctly :) the demo doesn't work in chrome on windows if you use the scroll bar. this feature also breaks element.scrollTo() if the element is off the screen.
Have you tried in Canary? I filed some bugs about this, and many have been fixed. If not, can you file them at crbug.com? We're pretty keen to get this fully working.
I'm having a problem when using content-visibility with box-shadow, it's not rendering it at all. It does renders the box-shadow when using inset shadow, probably because the shadow is outside the component but that's always the case when using inset shadow. I thing chromium should change it.
Does this work with named anchors? What happens with the content that are "in between" the link and the anchor on click? Will that cause a sudden render that causes delay?
@@cwc2005 we discuss this exact thing in the episode. They work, but I found a bug when making the demo for this video. If you find linking bugs in Canary, please report them.
Can't you use contain-intrinsic-size with the vh and vw units? Why did you use an arbitrary `contain-intrinsic-size: 1px 5000px` for the HTML spec? Surely you'd want to pair `content-visibility: auto` with `contain-intrinsic-size: 100vw 100vh`
You can use those units, but remember you're setting the fallback size of the inner content, not the element size. Because of this 100vw is likely to land you with horizontal scrolling. 100vh is just as arbitrary, and less accurate in this case.
@@jakearchibald why would they be of the inner content and not the outer? Am I missing something? Why wouldn't you want to set the outer content intrinsic size?
Eg, the container element might be part of a flexbox/grid, so it's still being laid out by its parent, but how much space it takes up in the flexbox/grid is determined by its intrinsic content size, which you set with contain-intrinsic-size when the children of the element aren't being laid out.
For sound quality and isolation, I prefer my Shures, but the Jabras are just so much easier to take in & out that I don't really use the Shures anymore. Might be a different story if I was still commuting.
