- From: Tab Atkins Jr. via GitHub <noreply@w3.org>
- Date: Mon, 13 Oct 2025 20:39:20 +0000
- To: public-css-archive@w3.org
Re: `visibility: force-hidden` for implementing `position-visibility` behaviors The original intention of this was to make the change visible in the computed styles *somehow*, so transitions could key off of it. Downsides of the current approach are (a) `visibility` is inherited, so (as Emilio mentions in the OP), it causes a potentially *large* style update, and (b) you can't do anything useful *in CSS* with a transition here; all you can do is use a transition to delay the hiding, and then use a TransitionEvent to do something more (most likely, an opacity fade-in/out). What if we solve both those problems at once, and instead of using `visibility` at all, use `opacity` instead? Specifically: add a new `opacity: hidden` value, which acts like `opacity: 0` for all purposes (including transitions), but also makes the element transparent to pointer events (like `visibility:hidden` does) This kills a few birds with the one stone. `opacity` isn't inherited, so it's only a style change on the element itself. Children can't opt out of an opacity transition on an ancestor, like they can with `visibility`, so no problem there. Also, the most common transition an author would want to do (fading in/out) is now trivial - just set an `opacity 1s` transition. And they can still hook a TransitionEvent to do more complex stuff if they need to. /cc @progers, who was asking about this recently in internal chat, too -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12732#issuecomment-3398998810 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 13 October 2025 20:39:20 UTC