[css-display-3] `display: unload` to observably unload element state

[dead-claudia]

The idea is this: it renders like display: none, but further unloads state to save on memory. I'm filing this here, but it also would require significant changes to the HTML spec.

• Images and iframes are unloaded. Transitioning back to any other display value causes fetches to happen anew like it was just added, firing an additional load event once (re)loaded.
• Animations are cut off by display: unload and reset upon display changing back to something other than unload.
• Inputs' state resets upon display changing to unload.
• Audio and video play state resets upon display changing to unload.
• Focus removal occurs upon display changing to unload in the same way they fire on element removal.
• Custom elements can observe changes via .attachedCallback() and .detachedCallback(). .connectedCallback() and .disconnectedCallback() would default to these if missing.
• Probably other stuff I may be missing.

The idea is to unload external state for things like inactive popovers, inactive tabs, and inactive routes (see WICG/declarative-partial-updates#14). It does not cause elements to be actually removed unless observing JS callbacks do so explicitly, but it has most of the observable side effects that element removal has.

[fantasai]

Hi @dead-claudia Can you explain more your motivation for this feature and examples of where and why you would use it?

[dead-claudia]

@fantasai The idea is that for routing (see that linked issue/repo), tabs, and such.

Pure CSS tabs have been a thing for a long time, using display: none to hide inactive tabs. And there are major limitations to this: while animation state resets, input state does not, and custom elements likewise don't receive any direct notification they're hidden. While this is usually acceptable (and even desired) with tabs, it would not be wanted with the HTML routing proposal, which fundamentally works very similarly.

There are times when you want input state and such to be retained, and so simply hacking display: none to do this is not a correct solution, even ignoring the obvious web compat concerns.