
The two-value syntax of the CSS Display property - feross
https://hacks.mozilla.org/2019/10/the-two-value-syntax-of-the-css-display-property/
======
paulddraper
Unrelated, but I am looking forward to the "zero-value" display:

    
    
        display: contents
    

[https://caniuse.com/#feat=css-display-
contents](https://caniuse.com/#feat=css-display-contents)

Will make for far easier separation of style and structure, especially with
flex/grid layouts.

~~~
davnicwil
Interesting, wasn't aware of this. I'm just thinking about it though and I
think I'm missing the usecase. If it ignores the parent element for styling,
why not just not have the parent element at all? Or is this for situations
where you don't have control over the markup but you do over the CSS?

~~~
mstade
For example, let's say you want to create a DOM structure which groups
together other elements in an outline like structure, so this:

    
    
        <h1>Hi world!</h1>
        <p>Lorem ipsum...</p>
        <h2>Hi world!</h2>
        <p>Lorem ipsum...</p>
        <h1>Hi world!</h1>
        <p>Lorem ipsum...</p>
    

Becomes this:

    
    
        <div class="h-group h1-group">
          <h1>Hi world!</h1>
          <p>Lorem ipsum...</p>
          <div class="h-group h2-group">
            <h2>Hi world!</h2>
            <p>Lorem ipsum...</p>
          </div>
        </div>
        <div class="h-group h1-group">
          <h1>Hi world!</h1>
          <p>Lorem ipsum...</p>
        </div>
    

Now you can easily select any h2-level group (heading and elements "belonging"
to that heading) by just using the `.h2-group` selector. To my knowledge,
there is no way to do this with css selectors alone, so you need the divs, or
some other element for grouping. But layout might be getting screwed up
because of those divs, so add `.h-group { display: contents; }` and it's like
those divs were never there to begin with. Problem solved!

~~~
IfOnlyYouKnew
This _should_ be accomplished with the more semantic sectioning tags, i. e.
<article> and <section>.

It's possible that there are other examples where this isn't possible, but I
can't think of any right now. Tags can also be nested, and levels can be
selected using CSS dsecendant and child combinators.

(This obviously wouldn't change OP's point)

~~~
mstade
Ironically, I actually used section tags in my original snippets but changed
to divs before posting simply because I didn't want the discussion to turn
into this-vs-that. :o)

In any case, the point of course is that at times these groups are added to
create a kinship between elements that is otherwise not possible to express
via css selections, or because it just makes manipulation easier, and you
don't want these grouping elements to participate in layout but the children
should. In those cases, `display: contents` is the knight in shining armor.

------
d--b
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...

~~~
goto11
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
Thanks much for digging that up

------
_bxg1
What we really need is the ability to specify these two properties _as
separate CSS properties_. This problem has been the bane of writing reusable
components for me. If I want a context to override a component's _outer_
display, I have to go check and make sure I'm preserving its _inner_ display,
which is an incredibly fragile practice and prone to being messed up later.

~~~
jamestomasino
That really does seem like the much saner approach, doesn't it? Like, keep
display for outer display as it has the history, and use "flow" for the inner.
flow: flex, flow: grid, flow: normal, or something. But HN comments aren't in
charge of specs, so I look forward to screwing this up for years to come.

------
valgaze
Worthy read—-Learn CSS the Pedantic Way (by Mikito Takada):
[http://book.mixu.net/css/](http://book.mixu.net/css/)

