should toggle-visibility have contain:paint or at least its z-ordering effects (stacking context) all of the time?

[dbaron]

Right now toggle-visibility not being normal acts like content-visibility: auto is present only when the toggle is in the inactive state. This implies contain: paint, which has z-ordering effects, which means that an element with toggle-visibility != normal has a higher default z-order when its contents are hidden than when its contents are visible.

This seems like it might be undesirable.

Perhaps it would make sense to imply some of the containment, or at least the z-ordering effects of contain:paint (i.e., creating a stacking context), whenever toggle-visibility is not normal rather than only when the toggle is inactive.

[dbaron]

One possibility is that toggle-visibility != normal should work like content-visibility: auto, except connected to the toggle instead of connected to being on-screen. (Right now the spec says that it's only like content-visibility: auto when the toggle is in an inactive state.) This definition does seem to be easy to implement in an implementation that already implements content-visibility.

That said, it seems less necessary, and perhaps undesirable, to have all the containment effects when the toggle is active. However, I think the z-ordering effects are needed, and there may be other aspects of containment that I'm not thinking of that either are useful for the visible state or useful to switch states efficiently.

[dbaron]

That said, contain affects a lot of CSS properties, and having whether contain is present depend on toggle state means a ton of CSS property computed values would suddenly depend on toggle state, which is probably undesirable. So maybe it should just work like content-visibility: auto with all the containment effects.

[tabatkins]

Yeah, I think that's just badly written on my part. The intention is definitely what you suggested, where it acts like content-visiblity: auto but tied to toggle state instead.

[tabatkins]

(Like, I'm still not entirely certain I shouldn't just be using content-visibility with a new value.)

[dbaron]

"like a new value of content-visibility" was sort of how I was thinking about the implementation.

[dbaron]

(An interesting question for the case of keeping it a distinct property is what to do when both content-visibility and toggle-visibility have non-initial values. I'm inclined to follow content-visibility since most of its effects are stronger.)

[tabatkins]

Yeah, I think the behavior we want is that toggle-visibility can apply hidden-ness in addition to things like content-visibility.