[css-display] Consider renaming box-suppress property to box-generation

[NickGard]

I suggest renaming box-suppress (defined here) to something with a positive context rather than a negative one. The issue is that box-suppress: discard; may be confusing because of the inherent double-negative. An author may think that box-suppress: discard; means the previous box-suppress value is discarded.

I suggest

Name: box-suppress
Value: show | discard | hide
Initial: show

be renamed to

Name: box-generation
Value: initial | none | no-layout
Initial: initial

where the values map from show to initial, discard to none, and hide to no-layout.

[tabatkins]

Hmmm, that's not bad. "generation" butts right up against my feel for "too-complex spelling", but I think it could be okay.

[frivoal]

Well, except that initial is a reserved keyword, and so we should use something else. normal? show? generate?

[NickGard]

I like normal instead of show. The only reason to have show is that it is viewed as the opposite of hide and I don't think that hide really describes what is happening. Plus, the normal/initial/show value is really the opposite of none, so maybe all would be a better name.

[fantasai]

Definitely agree with renaming the property! Also think -generation is a bit long. An earlier proposal was display-box, maybe that could work. Still up for more ideas, though. :)

Wrt value names... I'm okay with normal as the default, but I think discard is clearer than none. I'm not sure what the problem is with hide, but collapse is another possibility.

[fantasai]

Btw, some history on this property: https://lists.w3.org/Archives/Public/www-style/2013Mar/0095.html

I'm not sure that the UA rule suggested there would be Web-compatible at this point. If it's not, then we could go back to having display as a shorthand, since that UA rule was the main reason not to. The none value would be passed to box-suppress (or whatever we call it) and other values would be passed to a display-type or display-as sub-property.

[NickGard]

display-box meets my criteria (that it's not a "negative" name) and I support collapse instead of hide or the other options. My main objection to hide is that it sounds like what an author would want (for a display: none; situation) when they really want none/discard but the fact that the element wouldn't show is only part of what hide/collapse does so this may have unintended consequences.

[fantasai]

It really depends on what the author is trying to do. In both cases,the layout is the same. But I think quite a few situations where authors want to use 'display: none', they actually want the hide behavior, which preserves the animation timer and CSS counters. It also keeps the box in the tree, so in implementations could end up more performant for cases where speed is more important than memory savings. At least, these are the goals. :) We still have to work out the details.

[fantasai]

(Please add) Agenda+ for comment #6. The question: is the original UA-stylesheet motivation for keeping box-suppress independent of display Web-compatible?

• If not, then propose to revert to display-box as a sub-property of display.
• If so, then still hoping to rename the property to something better than box-suppress. ;)

[jacobp100]

Could the display property be split? Say display-layout, which allows stuff like inline, block etc, and display-visibility which could be auto or none, and then make display a short hand for this. display: none would set the display-visibility to none.

Just a thought!

[fantasai]

Yep! That's exactly what I wrote 11 days ago in https://github.com/w3c/csswg-drafts/issues/343#issuecomment-235961589 :)

[FremyCompany]

Hey, I didn't object to today's resolution that we should probably try to harmonize "box-suppress" and "display" but I am still not convinced either that what we want is any different from what "visibility: collapse" does provide for tables internal elements already.

Scanning through this thread yields display-visibility as a proposed property name and collapse as a proposed value name.

So, to summarize:

• We have visibility: collapse that already does pretty much what we want on a subset of display types (the element still generates boxes, but those are not really used for layout and are not rendered)
• We have a proposal to add display-visibility: collapse (or similar) that does pretty much the same thing on all display types (the element still generates boxes, but those are not at all used for layout and are not rendered)
• Using display as a shorthand has implications as user agents usually serialize shorthands into longhands in the cssom, and may break websites. Many assume javascript code assume display to be none or not none, but will chuckle on combinations that a new longhand would make possible. It will be difficult for years not to include css/js from css frameworks that use display improperly if you want to use display-visibility .

As a result, I am still not quite sure why we would not just follow the unification route where we just allow visibility:collapse to apply on non-table elements with the newly suggested behavior.

I guess this is one of the things we can discuss irl this Friday when you come by the office.

[FremyCompany]

(@fantasai mentioned that visibility:collapse acts like hidden on non-table at this point, so this would be a breaking change; usage is very low so maybe we could work that out but we would have to assess it by running some api-usage check)

[fantasai]

Here's the resolution to tuck this display-or-not property under the display property: https://lists.w3.org/Archives/Public/www-style/2016Aug/0034.html So the prefix should be display-*. As for what the property and its values are called, that's still an open question. :) Fwiw, Tab and I are thinking to defer the feature to the next level unless we get some good names here.

[nigelmegitt]

As referenced from the link in https://github.com/w3c/csswg-drafts/issues/343#issuecomment-248151342 the resolution was:

• RESOLVED: Make display into a short hand and add an issue on naming for the long hands.

but surprisingly (to me) there are no follow-up issues linked from here for the long hands. Was an issue ever raised?