[css-display-4] Add inner and outer display properties

[Jamesernator]

CSS display level 3 adds the great change of allowing controlling the inner and outer display of an element. However it does not give a way to control them independently.

e.g. Consider a web component with a shadow root that would like to lay out its internals:

<user-summary>
  <#shadow-root>
    <style>
      :host {
        display: block grid;
        grid:
          "avatar displayName" max-content
          "avatar userName" max-content
          / auto auto !important;
      }

      #avatar {
        grid-area: avatar;
      }

      #displayName {
        grid-area: displayName;
      }

      #userName {
        grid-area: userName;
      }
    </style>

    <img id="avatar" src="{{avatarSrc}}"/>
    <div class="name">{{displayName}}</div>
    <div class="username">{{userName}}</div>
  </#shadow-root>
</user-summary>

In this case the grid styling is important for the functionality of the component, however this comes with a couple caveats:

• In order to style the outer display a user needs to know the internal inner display, e.g. user-summary { display: inline grid; }
• Prevention of overriding the grid style using !important breaks the ability to make user-summary a different outer style

As such I'd like to propose adding display-inside/display-outside as individual properties, then the styles could be written as such:

:host {
  display-outside: block; /* Can override externally */
  display-inside: grid !important; /* Cannot override externally as it is necessary */
}

[Loirooriol]

See https://drafts.csswg.org/css-display-3/#changes

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

So maybe for level 4?

[fantasai]

Yeah, one of the key restrictions here being that nobody wants to implement display-outer: table-cell; display-inner: grid;. :) Tagged as css-display-4, but doubt we'll get any traction on it until there's a way forward on that combination...

[jonrimmer]

I don't understand this objection. Since the current spec already supports a two-value syntax, then can't people can already specify that combination? Unless it's illegal, in which case what difference would having separate properties for display-inside and display-outside make? Just specify that the combination of particular values is also illegal.

Furthermore, given the whole web development industry, both standards-based (web components) and framework-based (React, Angular, Vue, etc.) has spent that last decade pursuing component-oriented development, why is a single problematic combination being allowed to prevent the delivery of a basic mechanism of layout encapsulation, the lack of which is a huge pain point?

I'd really like to give people the benefit of the doubt here, but the dropping of display-inside and display-outside seems to point to a total disconnect between the reality of contemporary web development and what's happening in this part of the standards process.

[Loirooriol]

can't people can already specify that combination?

No, display: table-cell grid is invalid syntax.

Unless it's illegal, in which case what difference would having separate properties for display-inside and display-outside make?

If display-inside and display-outside are added, then

• display: table-cell would seemingly expand to display-outside: table-cell; display-inside: flow-root, i.e. table-cell would need to be valid syntax for display-outside.
• display: grid would seemingly expand to display-outside: block; display-inside: grid, i.e. grid would need to be valid syntax for display-inside.

So display-outside: table-cell; display-inside: grid; would be valid syntax, but nobody wants to implement it for now.

Just specify that the combination of particular values is also illegal.

It's not that simple. There is no mechanism to treat a usually valid value as invalid syntax depending on the value of another property. Actually this can't be done at specified value time, since we may not know the resolved values of both properties until computed-value time (there might be a var() or inherit).

What could potentially be done is, at computed-value time, say that e.g. if display-outside computes to table-cell, then display-inside must compute to flow-root even if some other value was specified. Or maybe make both of them invalid at computed-value time or something (there are various possibilities to prevent the combination at computed-value time, which one is better?).

However, if in the future browsers are willing to implement a table-cell grid combination, then it will be a breaking change. There might be some sites that rely on this combination not working, so they break once it works.

Is the risk worth it? I don't know, but if you think so, it may be better if you read the spec, come with a clear proposal, and try to convince the editors about that. Saying that they are disconnected from the reality of contemporary web development is not productive.

[MatsPalmgren]

@fantasai

Yeah, one of the key restrictions here being that nobody wants to implement display-outer: table-cell; display-inner: grid;.

Uhm, I literally implemented them in Gecko and asked you to add them to the spec in #3940 (comment).

@Loirooriol

No, display: table-cell grid is invalid syntax

Not if #3940 is adopted.

[jonrimmer]

@Loirooriol I didn't say the editors were disconnected, I said the output of the standards process is in this case. And from the perspective of an author, it clearly is.

The issue you describe needs a resolution of some kind, but the worst-case impact of any conceivable resolution would still be better than the actual impact right now of such a fundamental encapsulation use-case being missing from the platform.

As for how it should be resolved, you say there are actually various options, so why not just have a discussion during a face-to-face meeting, reach a consensus on the least-worst, and go with that? As for the argument re. forwards compatibility, that seems entirely fallacious, in that the same objection applies the entire design of CSS. I can put display: hypercube into my CSS right now and it could break if that ever becomes valid syntax. So what? Browsers make breaking changes all the time, many far bigger than this would ever conceivably be, and there is a robust system for counting usage and making those decisions appropriately.

[SebastianZ]

What could potentially be done is, at computed-value time, say that e.g. if display-outside computes to table-cell, then display-inside must compute to flow-root even if some other value was specified. Or maybe make both of them invalid at computed-value time or something (there are various possibilities to prevent the combination at computed-value time, which one is better?).

As @MatsPalmgren pointed out, table-cell grid shouldn't be a problem. In order to be able to introduce display-outside/display-inside properties, it needs to be clarified whether that applies to all combinations of <display-outside>/<display-inside> values, and if not, how to resolve those combinations.

From a gut feeling, I'd say keeping the computed value of display-outside forcing the display-inside value is the way to go, as authors probably don't expect both to be invalidated in this case. Though I didn't give this much thought yet.

Sebastian

[kizu]

Would be nice to maybe return to this? I, and others (https://mastodon.social/@ollicle/111146605034670150) would really want to see separate properties for these, though usually we'd also want to toggle the display-box separately as well.

Like, I cannot see why we can't allow display: flex inline none, for example — I would find this closer to how some other properties work like border: it is ok to have border: 2px none pink, and then when you need a border just toggle border-style: solid and get your border as set up previously.

Even more: I think in my practice the most common case was always: to keep the flow, flex or grid intact, then separately toggle block/inline, and then also toggle none/not-none (I guess we lack a keyword for this), so you could keep toggling the element on and off while keeping its outer and inner layouts intact.

[SebastianZ]

Like, I cannot see why we can't allow display: flex inline none

With a separate longhand that controls the display of the box within the box tree (e.g. a display-box longhand), we don't necessarily need a third value for the display shorthand. Instead, the none or non-none value (name TBD) could be set implicitly, like border: 2px solid sets border-color to its initial value currentcolor.

Taking your example, a display flex inline; would then set display-box to the non-none value. And you could overwrite it via display-box: none;.

Sebastian

[benface]

Even more: I think in my practice the most common case was always: to keep the flow, flex or grid intact, then separately toggle block/inline, and then also toggle none/not-none (I guess we lack a keyword for this), so you could keep toggling the element on and off while keeping its outer and inner layouts intact.

Yes. Having separate properties for these 3 things would be A-MA-ZING.