4 ms·

Is there a valid reason for not splitting this into 2 properties? I mean, this has always been a pain, and it's great that they are refactoring it. But the way

by d--b 7y ago

Is there a valid reason for not splitting this into 2 properties? I mean, this has always been a pain, and it's great that they are refactoring it. But the way a block behaves and the way it treats its children really are two distinct concepts. If I have a list of items, I may very well want the same "outer display" and a different "content display", and yet, I'll have to define outer display everywhere. Not a massive issue, but display: block flow could be a shorthand for display-outer: block; display-content: flow. In the same way margins or padding work...

seaish 7y ago
The outer one should stay as "display" and the inner one could be "children" or something.
dan-robertson 7y ago
I think a reason is there are some values (contents, none) which don’t split into two properties
_bxg1 7y ago
That could (hopefully) be part of the plan. Other multi-value properties like border and padding can be specified (or overridden) as a series of more granular properties that target their different values individually.
goto11 7y ago
The existing values for "display" have long conflated "inside" and "outside" display models, so it can't really be separated now. But at one point there was a proposal to add two new properties, "display-inside" and "display-outside". And "display" was then redefined as a shorthand which combined both. This have been removed (https://www.w3.org/TR/css-display-3/#changes-wd https://www.w3.org/TR/css-display-3/#changes-wd) with this justification: Removed display-inside, display-outside, and display-extras longhands, in favor of just making display multi-value. (This was done to impose constraints on what can be combined. Future levels of this specification may relax some or all of those restrictions if they become unnecessary or unwanted.) It seems this is to restrict combinations with "display:none" and "display:content" and the various "display:table-*".
- d--b 7y ago
  Thanks much for digging that up

by d--b 7y ago

seaish 7y ago

The outer one should stay as "display" and the inner one could be "children" or something.

dan-robertson 7y ago

I think a reason is there are some values (contents, none) which don’t split into two properties

_bxg1 7y ago

That could (hopefully) be part of the plan. Other multi-value properties like border and padding can be specified (or overridden) as a series of more granular properties that target their different values individually.

goto11 7y ago

The existing values for "display" have long conflated "inside" and "outside" display models, so it can't really be separated now. But at one point there was a proposal to add two new properties, "display-inside" and "display-outside". And "display" was then redefined as a shorthand which combined both. This have been removed (https://www.w3.org/TR/css-display-3/#changes-wd https://www.w3.org/TR/css-display-3/#changes-wd) with this justification: Removed display-inside, display-outside, and display-extras longhands, in favor of just making display multi-value. (This was done to impose constraints on what can be combined. Future levels of this specification may relax some or all of those restrictions if they become unnecessary or unwanted.) It seems this is to restrict combinations with "display:none" and "display:content" and the various "display:table-*".

d--b 7y ago
Thanks much for digging that up