Hacker News Reader

Comment by amelius | Hacker News Reader

I still wonder why we have

    display: flex

and

    display: inline-flex

It seems to me that the committee who designed this has been confusing what is happening inside the box (flex or not) with what is happening outside the box (inline or block). Those two behaviors should be orthogonal, IMHO.

View on HN

> It seems to me that the committee who designed this has been confusing what is happening inside the box (flex or not) with what is happening outside the box (inline or block).

That has nothing do do with "the committee who designed this", the issue has been inherited all the way from CSS 2's inline-block, which defines `display` as a single-value property altering both inner and outer display types.

> Those two behaviors should be orthogonal, IMHO.

Which is why Display Module Level 3 exists https://www.w3.org/TR/css-display-3/#the-display-properties.

However Display 3 is a Working Draft, and thus not available to flexbox (or grid), so until then they need an inline- prefixed "legacy" value.

Problem is in another architectural error that authors of the spec have made. In fact flexbox is the worst CSS spec ever produced - too many problems yet bloated.

display is a wrong CSS property for that. The display defines requirement of the element to its container.

For example

    div { display:inline-block; }

demands that div itself to be placed inside line-box container in a row with other inline elements.

But the flex is about quite different entity: specification of how children of the container shall be replaced.

That's why there is a need for the whole zoo:

   display: table | inline-table | flex | inline-flex | grid | inline-grid | etc.

Yet even this does not solve principal problem. What if I want to have display:list-item that uses flexes inside. No way...

It is really should be

    display:list-item; // list item 
    flow:horizontal;   // children replaced horizontally
                       // with flexes if needed

or some as such.

Sigh.

Truly there should be no use case for the "inline-" prefixed properties anymore. Your HTML+CSS systems should denote layout strictly from parents ("cascading!") and any exceptions to your rules would exhibit either an unsatisfactory rule or an inconsistent design.

It's interesting (and reasonable) that cascade has become synonymous with inheritance, while the standard defines it as the process that looks at importance and origin, followed (if necessary) by specificity, followed by order: https://www.w3.org/TR/CSS22/cascade.html#cascade

In my usage I meant to express that a modern system should be constructed similarly to how flexbox and grid determine the "display" property of the selected element's children.

If your code constantly requires manual display:inline-block; on elements (and it's not just to override the browser's default stylesheet), then you probably aren't adhering to a consistent pattern and your CSS's maintainability will eventually drop off at an exponential rate.

Flexbox enables you to even avoid patterns like .inline-list>li{float:left;}, so sibling-level specificity isn't going to align with best practices anymore in the near future.

Oh, I agree with your comment. I guess I should have quoted the part that led to my rather off-the-topic remark:

parents ("cascading!")

I wonder whether the people who coined the term CSS also had in mind cascading as related to inheritance, or maybe even only this meaning, and later the standards "lawyers" tied the term cascade to the definition I cited. Thanks for replying.

What is the correct way to achieve, say, the example that article uses for inline-flex?

In anything implementing the current draft of CSS Display Module Level 3, the `display` values we commonly use today become a shorthand for two orthogonal properties.

For example, `display: block` becomes shorthand for `display: block flow`, where `block` is the <display-outside> and `flow` is the <display-inside>.

----

https://drafts.csswg.org/css-display/#propdef-display

> The `display` property defines box’s display type, which consists of the two basic qualities of how an element generates boxes:

> * the inner display type, which defines [...] the kind of formatting context it generates, dictating how its descendant boxes are laid out.

> * the outer display type, which dictates how the box participates in its parent formatting context.

...

> <display-outside> = block | inline | ...

> <display-inside> = flow | flow-root | table | flex ...

...

   Short `display` | Full `display`     | Generated box
   ----------------|--------------------|---------------
   'block'         | 'block flow'       | block-level block container
   'flow-root'     | 'block flow-root'  | block-level block container that establishes a new block formatting context
   'inline'        | 'inline flow'      | inline box
   'inline-block'  | 'inline flow-root' | inline-level block container
   ----------------|--------------------|---------------
   'flex'          | 'block flex'       | block-level flex container
   'inline-flex'   | 'inline flex'      | inline-level flex container

----

It looks like there were, in the first draft of the spec, independent `display-inside/outside` properties, with `display` being a "one property that sets multiple properties" shorthand:

https://www.w3.org/TR/2014/WD-css-display-3-20140911/#the-di...

But that has since been changed to `display` being a "one property that takes multiple values" shorthand, in the current version of the spec:

https://www.w3.org/TR/2015/WD-css-display-3-20150721/#change...

> Changes since the 11 September 2014 Working Draft include:

> 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.)

Even that display-inside is a fuzzy one. What does it mean

   display-inside: block;

for example? I would expect flex-direction to go there

   display-inside: default | row | column | ... ;

So display-inside: row; will replace children horizontally.

In this formulation, `block` is a <display-outside> value, and would not be valid as a <display-inside> value.

----

<display-inside>, which can be `flow`, `flex`, `grid`, etc, but not `block`:

> defines [...] the kind of formatting context it generates, dictating how its descendant boxes are laid out"

https://drafts.csswg.org/css-display/#formatting-context

Which, as I interpret it, is "just" another level of indirection on top of your proposal, providing a mechanism for more messy and incompatible, legacy and future, layout systems to coexist.

So if I have this:

   img-row {
     display: block flow;
   }

and markup

   <img-row>
     <img src=1.png>
     <img src=2.png>
     <img src=3.png>
   </img-row>

I will still have a problem with white space appearance between image of these [inline-]blocks ?

While with this:

   img-row {
     display: block;
     flow:horizontal;
   }

child images will be treated as blocks and so white spaces will not go into rendering/layout tree of the img-row.

So again partial solution, sigh.

As far as I can tell, the only way the source-whitespace will appear is when both of the following are true:

1. The parent has `display-inside: flow` or `display-inside: flow-root` (ie, the "original", pre-flexbox, formatting contexts)

  eg `display: block`, `display: inline`, `display: inside-block`

2. The children have `display-outside: inline`

  eg, `display: inline`, `display: inline-block`, `display: inline-flex`

In any other combination, the source-whitespace disappears, in some way or other.

----

What I think you want, a horizontal row disregarding source-whitespace, could be achieved with `display-inside: flex` (eg, `display: flex`, `display: inline-flex`) on the parent (with `flex-direction: row` being the default). So:

    img-row {
        display: flex;
    }

aka

    img-row {
        display: block flex;
    }

aka (though this syntax has been temporarily removed)

    img-row {
        display-outside: block;
        display-inside: flex;
    }

aka

    img-row {
        display-outside: block;
        display-inside: flex;
        flex-direction: row; /* the default */
    }

----

Note that this longhand syntax doesn't seem to be implemented in Chrome, at least, yet. So if you want to check it out, you'll have to work in the shorthand (still translatable from the longhand as specified in the draft spec https://drafts.csswg.org/css-display/#propdef-display).

As far as I understand

    display-inside: flow;

is the current (default) layout method. So all runs having characters (including spaces) and children that have display:inline | inline-block will be replaced in line boxes preserving spaces between them (consecutive spaces are collapsed into one but still they will be there).

But suddenly all children that have display:block will be a) replaced on new row each and b) with spaces between them ignored.

Such a dichotomy is the source of weird hacks, like advices to remove spaces between blocks at all, etc.

Yes, it is my understanding that one of the major, inviolable design goals in this is not to break any old behaviour, or any such (yes, totally distasteful) "hacks" dependent on it. Now that particular old behaviour is "isolated" under the `display-inside: flow` formatting context, which has to remain the default.

Lets go back to the spec draft:

----

https://drafts.csswg.org/css-display/#propdef-display

> The display property defines box’s display type, which consists of the two basic qualities of how an element generates boxes:

> * the inner display type, which defines [...] the kind of formatting context it generates, dictating how its descendant boxes are laid out.

> * the outer display type, which dictates how the box participates in its parent formatting context.

...

> <display-inside> = flow | flow-root | table | flex ...

> <display-outside> = block | inline | ...

----

It's not just the reframing into `display-inside` (how to lay out children) and `display-outside` (how to participate in parent) which addresses your problem -- that just provides a new way to specify the same behaviour as before. Split into 2 orthogonal axes, cleanly leaving room for new behaviour to exist in combination with old behaviour.

But, rather, it's that plus the specific provision of `display-inside: flex`, within this new framing, which addresses your problem.

If you stick with `display-inside: flow` in your examples of things that are problems, of course nothing is going to change, because that specifically specifies "behave like you always used to".

I'm honestly not sure I understand your complaint. I'm definitely open to the possibility that this is an internally-inconsistent or short-sighted solution, but I'm not seeing it here.

> But that has since been changed to `display` being a "one property that takes multiple values" shorthand, in the current version of the spec

FWIW, there is a WG resolution to have display-inside/outside properties in Level 4.

Reply on news.ycombinator.com