Skip to content

[css-display-4] Proposal: display-visibility property #12046

Open
@benface

Description

@benface

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 visible and hidden values from the visibility and content-visibility properties:

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:

<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!

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions