Think a web component that you want to lay out as two table cells. The component has to be attached to an element, but there's no way to make a single element be two table cells right now. With display:contents you make the element the component is attached to display:contents, and give it two display:table-cell kids.

Sometimes I'm stuck littering the DOM with random <div> or <span> tags for conditionals and whatnot in various templating engines.

ng-switch in AngularJS, for instance, is going to leave a wrapping tag for the switch declaration.

https://docs.angularjs.org/api/ng/directive/ngSwitch

This would be useful if you were making UI components and you want a generic wrapper element to contain say a checkbox and a label. The wrapper can have display:contents, allowing the checkbox and label to have a shared parent for movement through the DOM or selection via JS, but otherwise have no styles that apply to their parent.

I imagine you can use it to ensure that elements that are added simply for semantic purposes (like, say, containers for other elements that are there just to group them logically) do not create any boxing side effects, like default padding and similar non-obvious CSS buggery.

I fear that now we will just replace it with another set of non-obvious CSS behavior. Consider, does this property nest well? How does absolute positioning work against something like this? Do they just ignore the parent box, since they are replacing it?

Undefined or Browser specific. Or just a further explosion of the spec?

All of this is defined in the spec. display:contents just means that in the box tree the box is elided and its child boxes are placed where it used to be, and then things proceed as normal.

If you have nested display:contents things, it just works: you end up with a box and what used to be its great-nephews/nieces in the same flat list is all.

My point is really that I am not even sure what I would expect to happen in such cases. To the point that I will find it hardly surprising when developers on a browser inevitably makes a mistake in implementation.

So, yes, this may all be there in the spec. But this is really just making the spec larger and larger with what seems to be nominal, if not decreasing, gains.

> My point is really that I am not even sure what I would > expect to happen in such cases.

The same thing as happens if you just delete the parent element from the source (if we ignore for the moment selector matching and inheritance).

> with what seems to be nominal, if not decreasing, gains.

display:contents was pretty commonly requested by component authors who want their component to fit into a larger layout framework (flex, grid, table) as more than one layout unit. I agree that if you're not trying to author components it's of pretty limited utility.

Possibly spec explosion but it is there:

http://dev.w3.org/csswg/css-display/#the-display-outside

It's not uncommon to want to wrap some component in a container for neatness of source/easier manipulation from JS. But this means the container won't break anything.