Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
NickGard opened this issue Jul 26, 2016 · 14 comments
Open
Assignees

Comments

@NickGard
Copy link

NickGard commented Jul 26, 2016

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.

@NickGard NickGard changed the title [css-display] rename box-suppress property [css-display] Consider renaming box-suppress property Jul 26, 2016
@NickGard NickGard changed the title [css-display] Consider renaming box-suppress property [css-display] Consider renaming box-suppress property to box-generation Jul 26, 2016
@frivoal frivoal added the css-display-3 Current Work label Jul 27, 2016
@tabatkins
Copy link
Member

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

@tabatkins tabatkins self-assigned this Jul 27, 2016
@frivoal
Copy link
Collaborator

frivoal commented Jul 28, 2016

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

@NickGard
Copy link
Author

NickGard commented Jul 28, 2016

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
Copy link
Collaborator

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
Copy link
Collaborator

fantasai commented Jul 28, 2016

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Collaborator

fantasai commented Aug 2, 2016

(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
Copy link

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
Copy link
Collaborator

fantasai commented Aug 8, 2016

Yep! That's exactly what I wrote 11 days ago in #343 (comment) :)

@FremyCompany
Copy link
Contributor

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
Copy link
Contributor

(@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)

@astearns astearns removed the Agenda+ label Aug 15, 2016
@fantasai
Copy link
Collaborator

fantasai commented Sep 19, 2016

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
Copy link

As referenced from the link in #343 (comment) 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants