Skip to content

Instantly share code, notes, and snippets.

@paulirish

paulirish/containment-and-content-vis.md

Created March 27, 2024 17:42
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save paulirish/613cfe5a269ead0e27b1b33e950a342d to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save paulirish/613cfe5a269ead0e27b1b33e950a342d to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. paulirish revised this gist Mar 27, 2024. 1 changed file with 0 additions and 2 deletions.
    2 changes: 0 additions & 2 deletions containment-and-content-vis.md
    View file
    Original file line number Diff line number Diff line change
    @@ -11,8 +11,6 @@

    --------------------

    okay and below is my summary in [Reward `content-visibility` use in the dom-size audit · #14691](https://github.com/GoogleChrome/lighthouse/issues/14691)
    (i guess we'll treat that issue as source-of-truth)..

    ## `content-visibility` recap

  2. paulirish created this gist Mar 27, 2024.
    41 changes: 41 additions & 0 deletions containment-and-content-vis.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,41 @@
    ## containment recap

    - `none` (default)
    - `layout`, `paint`, `style` - the easy ones.
    - `content` === these three
    - bonus benefit of `contain: layout` -- any `pos:fixed` children will be relative to it.
    - `size` - harder. the element must define its own size, can't rely on laying out its children.
    - `strict` === `content + size`
    - `inline-size` - dunno? size but for display:inline-ish things?


    --------------------

    okay and below is my summary in [Reward `content-visibility` use in the dom-size audit · #14691](https://github.com/GoogleChrome/lighthouse/issues/14691)
    (i guess we'll treat that issue as source-of-truth)..

    ## `content-visibility` recap

    `content-visibility: auto` is like a `rendering=lazy` .. or it's like the `<script defer` of rendering.

    If you're familiar with css containment... `content-vis: auto` can be interpreted as `contain: content-for-inviewport-and-strict-when-outofviewport`.

    It implicitly applies `contain: content` but then as long as the elements contents are out of viewport (aka not visible) and not focused/selected, then it'll upgrade that to `contain: strict` (adding size containment). When the element is scrolled into viewport, the `contain: content` still applies. (Also other bonus: this stuff remains in A11y tree, unlike `vis:hidden` elements)

    #### How do we use it?
    Generally, we apply `content-vis:auto` to elements that hold much of the page's content and continue down the page in the non-visible area. That's when the perf benefit kicks in.

    Ask.. what are the DOM islands that hold the content. These islands must continue beyond the viewport for this to be useful. Articles, cards, etc are good targets to for `content-vis: auto`;

    #### Contain-intrinsic- sizes
    The `contain-instrinsic-(size/width/height/block-size/inline-size)` props are needed when **size** containment is on.
    They mostly assist for `content-vis: auto`, IMO. (Yes, it feels confusing that they aren't named `content-visibilility-intrinsic-size` but... feel free to think of it like that.) As elements off-screen get size containment. these properties often are used to define the height, so that the page scrollbar is reasonable and not jumpy.

    If these sizes are wrong, once the element is actually rendered, the browser will use the new/real sizes from then on out.

    In the spec, there's also `container-name` and `container-type`.. but they're for container queries.

    #### `content-vis: hidden`
    Using `content-visibility: hidden` is like `display:none` but.. stronger. Strict containment is applied but no painting and no ability receive clicks, etc. Used when you want to hide something (an offscreen nav or inactive app views), but want to reuse the cached rendering state when it reappears.