Intent to ship: CSS display:contents

[Mats Palmgren]

CSS display:contents has been enabled by default in v37 and my intent
is to ship this feature in v37 on all platforms.

It can be disabled by setting the hidden preference
layout.css.display-contents.enabled to false.

Link to standard:
CSS Display Module Level 3
http://dev.w3.org/csswg/css-display/#valdef-display-outside-contents

This feature was previously discussed in this "intent to implement" thread:
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/display$3Acontents/mozilla.dev.platform/QEr_FYzdyCw/br1ovObRnhwJ

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1105369


/Mats

[Boris Zbarsky]

On 2/1/15 4:36 PM, Mats Palmgren wrote:
> CSS display:contents has been enabled by default in v37 and my intent
> is to ship this feature in v37 on all platforms.

Do we have any indication on whether any other UAs are planning to ship
this?

-Boris

[Mats Palmgren]

I'm not aware of other vendors' plans on display:contents, sorry.

FWIW, it's been in the spec for quite a long time though, first as
'box:contents' then as 'display-box:contents', and I haven't seen
any negative comments about it.


/Mats

[Jet Villegas]

CSSWG determined that display:contents covers use cases that CSS Grid
subgrid would otherwise cover [1]. We may punt on subgrid now that we've
got display:contents in Gecko. Other UAs have voiced support for the same
at the May 2014 F2F.

--Jet

[1] https://lists.w3.org/Archives/Public/www-style/2014Apr/0329.html

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[paul....@gmail.com]

Hey Mats, the use cases are not obvious to me, but I didn't follow the original www-style threads on this so I'm lacking context. (A the spec doesn't help either)

Can you help explain why a developer would use `display:contents`?

I think it'd help to have it described a bit. Thanks!

[Tantek Çelik]

I'll rephrase Paul Irish's excellent question.

Rather than an email to be lost in archives, could you provide a URL
to a wiki page where the web designer / developer use-cases for
"display:contents" are documented, e.g. one use-case per section?

If not, I'm happy to ask the CSSWG myself.

Tantek

[L. David Baron]

The key use case is being able to work with CSS layout systems that
aren't transparent to extra elements in the markup (as block and
inline layout mostly are) without being forced to remove elements
from the markup. This is important with systems like flexbox and
(particularly) grid.

So it's not about being able to do things that you can't otherwise
do. All the things that are doable with display:contents could be
done before.

It's just about being able to do those things without deleting
"extra" elements from the markup in order to make the tree conform
to what the CSS layout model expects. Since what it does is
essentially delete an element from the tree as far as CSS is
concerned, while leaving its children; that is, you stop displaying
the element but still display its contents. Put another way, it's
half of display:none without the other half (where display:none is,
likewise, a feature that doesn't add any capabilities not present in
other ways).

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Mats Palmgren]

I wasn't involved in the discussions either so I don't know what use
cases the CSSWG has, so I'll just describe how it works technically
and give some examples what you could use it for.

With display:contents you can have DOM elements for styling or scripting
reasons but in terms of layout behave as if they're not there. In Grid
and Flexbox layout for example, if you wrap some children in an element
it will affect layout since the wrapper becomes a grid/flex item.
Styling it with display:contents undoes that so that the wrapped children
are again the grid/flex items, but they now inherit style from the
wrapper. I imagine it might be useful also in Web Components (styling
the shadow host and/or the shadow DOM elements with display:contents).

Here's a rather academic example just to illustrate:
<style>
tr {display:contents}
</style>
<table>
<tr><td>1<td>2
<tr><td>3<td>4
</table>

The above table will have one row with four cells in layout. In terms
of CSS box construction it's identical to:
<table>
<td>1<td>2
<td>3<td>4
</table>

If you replace the style rule with "td {display:contents}" you'd get two
rows with one cell each ("12" and "34"). With "tr,td {display:contents}"
you'd get one row with one cell.

display:contents can be nested of course, so you can "bubble up" CSS
boxes from arbitrary DOM depths. It allows you to break out of the
(mostly) one-to-one mapping between DOM nodes and CSS boxes.

It's a rather powerful feature and I think it remains to be seen how
web developers will make use of it.

The initial motivation for implementing display:contents in Gecko though
was to support implementing 'overflow:fragments' where we'd like to have
multiple (sibling) boxes for an element, where each can be styled
independently through a pseudo-element:
http://dev.w3.org/csswg/css-overflow-3/#fragment-overflow


/Mats

[paul....@gmail.com]

Thanks guys, appreciate it.

[cmzie...@gmail.com]

I am trying to set up a CodePen to test this feature:

http://codepen.io/WebDevCA/pen/vEeMjx

If I understand "display:contents" properly then if it is working the green border around the DIV can't be seen but the contents of the H1 inside that DIV can be seen?

[Jonas Sicking]

On Mon, Feb 2, 2015 at 1:33 PM, L. David Baron <dba...@dbaron.org> wrote:
> On Monday 2015-02-02 11:27 -0800, paul....@gmail.com wrote:

> The key use case is being able to work with CSS layout systems that
> aren't transparent to extra elements in the markup (as block and
> inline layout mostly are) without being forced to remove elements
> from the markup. This is important with systems like flexbox and
> (particularly) grid.
>
> So it's not about being able to do things that you can't otherwise
> do. All the things that are doable with display:contents could be
> done before.
>
> It's just about being able to do those things without deleting
> "extra" elements from the markup in order to make the tree conform
> to what the CSS layout model expects. Since what it does is
> essentially delete an element from the tree as far as CSS is
> concerned, while leaving its children; that is, you stop displaying
> the element but still display its contents. Put another way, it's
> half of display:none without the other half (where display:none is,
> likewise, a feature that doesn't add any capabilities not present in
> other ways).

Another instance where this becomes useful is for WebComponents.

It's easy to create a WebComponent which renders as a single row in a
table. Just make your element be styled as "display: table-row". Then
make the component's shadow content be styled as "display:
table-cell".

However if you want your component to render as two rows, you are out
of luck. So if you want your component to render as one row which
contains a headline, and one row that contains a data entry, then
you're stuck. Or one row that contains a group headline and a second
row which contains headlines for each table column.

But with this feature you can make your component use "display:
contents" and then make the shadow content render two rows with the
appropriate cells.

The lack of "display: contents" here doesn't just require that you
insert extra elements in the DOM. It requires dramatically changing
the API for your webcomponent.

/ Jonas

[Daniel Holbert]

Correct.

Conceptually, the <div> exists in the style tree (so e.g. your
"text-align:center" style gets inherited to the h1, via the style
system, and any other inherited properties or "div > * {" style rules
would affect the children as well). But the <div> does not exist in the
box tree. It's replaced there with its children (just the <h1> in this
case). So, the border doesn't show up, and the 'width' & 'margin' also
have no effect since they're styling a box that doesn't exist.

~Daniel

[Mats Palmgren]

Right, the H1 will be displayed in DIV's parent and the DIV itself will
not be displayed. However, H1 still inherit style from the DIV so you
can do "h1 {border:inherit}" to get a green border. And the DOM and
CSS selectors works normally, so it still matches "div h1 {}" etc.

Developer documentation for this feature is forthcoming, but for now
I suggest you download Firefox Developer Edition and play with it:
https://www.mozilla.org/en-US/firefox/channel/#developer

Thanks for your interest!

/Mats