[css-display] Add a new property to replace display: none declaration

[tzi]

I want to discuss about the display property, and more specifically about the nonevalue.

The associated specification is here: https://drafts.csswg.org/css-display-3/#box-generation

Usecase

I sometimes find display: none behavior very frustrating. I want to use it to prevent the rendering, but as a "side-effect" it also changes the display type of the element.

For example:

/* Flexible menu */
.menu {
    display: flex;
    justify-content: space-between;
}

@media (max-width: 600px) {

    /* Hidden menu on mobile */
    .menu {
        display: none;
    }

    /* Visible menu on user action */
    .menu--visible {

        /* I just want to "unhide" the menu, but I have to set it as flexible again */
        display: flex;
    }
}

Workaround

When discussing it on twitter with other CSS developers, they said they currently change their CSS architecture because of this problem.

For example, you can avoid this problem by using the :not() selector:

/* Flexible menu */
.menu {
    display: flex;
    justify-content: space-between;
}

@media (max-width: 600px) {

    /* Hidden menu on mobile, except after a user action */
    .menu:not(.menu--visible) {
        display: none;
    }
}

There are at least two downside of this kind of solution:

• the developer intentions are less clear (at least for me), and it could create maintenance difficulties
• it adds more specificity on the selector, so it could break architectures like BEM

Suggestion

What would be great is a new property. It would avoid developers to change their CSS structure because of the current display: none behavior. I'm not really good at naming 😄, but since I'm here I will play the game:

Name:	render
Value:	normal | none
Initial:	normal
Applies to:	all elements
Inherited:	yes
Percentages:	N/A
Computed value:	as specified
Animatable:	no

An example inspired from the previous examples:

/* Flexible menu */
.menu {
    display: flex;
    justify-content: space-between;
}

@media (max-width: 600px) {

    /* Hidden menu on mobile */
    .menu {
        render: none;
    }

    /* Visible menu on user action */
    .menu--visible {
        render: normal;
    }
}

If we compare with the current available solutions, I find the code with the new property render reflects much better the developer intentions. It also allows us to keep a low selector specificity.

There are probably others solutions to find. I just suggested one to start the discussion!

[Loirooriol]

This was called box-suppress:

The display: none value was historically used as a "toggle" to switch between showing and hiding an element. Making this reversible requires either setting up the CSS cascade carefully, or remembering what the display value was before it was set to none. To make this common use-case easier, this module introduces the separate box-suppress property to do the same thing, so that toggling whether or not an element appears in the formatting tree can now be done without affecting its display type when it is displayed.

But was deferred to level 4, Changes Prior to CR Status:

Deferred the box-suppress/display-or-not property to the next level of Display, in order to provide time for further discussion of use cases.

[tzi]

Thanks a lot @Loirooriol!
I didn't find it by myself.

Here is a short resume of the situation, so this issue should not start the same discussions again:

• The original name was display-box and then box-suppress
  https://lists.w3.org/Archives/Public/www-style/2013Mar/0095.html
• There is an open issue to rename the box-suppress property to display-<something>
  [css-display] Consider renaming box-suppress property to box-generation #343
• The feature was delayed because we were missing a good name, but the display- was decided
  [css-display] Consider renaming box-suppress property to box-generation #343 (comment)

[tabatkins]

Yup, this is a topic with a long history, that we'll get to in time. Since this thread has pinged the others now, I'll consider its purpose fulfilled; we can see this as another call for prioritization when we next review those threads. I'll go ahead and close this as a dupe, then. Thanks!