[csswg-drafts] [css-display-4] Proposal: `display-visibility` property (#12046)

benface has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-display-4] Proposal: `display-visibility` property ==
This is complementary to, but also distinct from, the proposed `display-outside` and `display-inside` properties in #4729.

It would be great to have a separate property to control whether an element is completely hidden, i.e. not only visually but also in terms of layout (unlike `visibility: hidden`) and from the accessibility tree (unlike `opacity: 0`).

I propose reusing the same options as for the `visibility` property (except `collapse`):

```css
display-visibility: visible;
display-visibility: hidden;
```

### Why?

Simply put, to allow "undoing" hiding an element without having to _know_ what the original `display` (both `outside` and `inside`) was set to. This is very common in design systems / component libraries.

Take the following example JSX + Tailwind code:

```jsx
<MyComponent className="sm:hidden lg:block" />
```

For whatever reason, we want to hide this component between the `sm` and `lg` breakpoints, but to do so (at least without introducing a custom variant, which would make the code harder to understand), we have to break the style encapsulation of `MyComponent` by assuming that its root element has `display: block` by default, which may be completely wrong. Of course we can verify that, but we shouldn't have to know; it's an internal implementation detail. Which means that it could change in the future, for instance to `display: flex`, which would potentially cause a bug if our `lg:block` overrides that declaration.

By introducing `display-visibility`, the `hidden` class could set `display-visibility: hidden` instead of `display: none`, and we could add a `not-hidden` class that sets `display-visibility: visible` (Tailwind already has a `visible` class that sets the `visibility` property, but not our problem here). That way, we wouldn't break the style encapsulation and risk future updates of `MyComponent` breaking our code (unless it sets `display-visibility` itself with higher specificity than our classes, but it wouldn't have any reason to do so).

Hopefully this problem resonates with enough people, and the proposed solution makes sense. Of course, we can work on the name and accepted values, but I think the general idea is there.

Thank you!

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12046 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 3 April 2025 19:40:51 UTC