HTML element with default `display: contents`

display: contents does not have widespread support yet. I imagine once it is widely supported, it will be used quite frequently. As such, it is logical that there exists an element that defaults to it, the same was <span> and <div> default to display: inline and display: block respectively.

What I’m proposing is essentially the equivalent of <span> and <div>. I’m not sure what the name should be ─ my initial thought was <contents>, but that was previously used. However, it would not be unprecedented to deprecate and element and later reimplement it (I can’t recall the element, but this has happened once before).

Hopefully this will receive some consideration.

New elements shouldn’t represent merely a specific styling but should have semantic meaning in and of itself. While this has not historically always been true it definitely is for any new elements.

I agree, but anything along the lines of <span class='contents'> along with .contents { display: contents; } certainly has little to no semantic meaning. Aria tags would likely help, but few developers even do this.

It certainly seems like the typical use case for display: contents would be to group elements together when a new parent is not actually needed. In my opinion, this would certainly constitute greater semantic meaning than a CSS class.

The way to get new elements is to have a use-case, show current methods to get what you want or get close, and show why it is important a new element be introduced to solve this purpose. Even better now that Web Components exist, make a polyfill of the element so it can be played with an explored.

Simply asking for an element because you want some CSS property to get used more won’t go anywhere. That provides no reason to drive browser developers to implement a new element.

If you feel so strongly about the new property, instead of asking for an element to try and get people to use it, evangelize it. Write a blog post. Look into conversations on different networks and chime in when you see a problem where the property solves the case. Write to newsletters and let them know your blog post exists and ask to get included in a future letter to subscribers.

My use case is for React containers. Every React component tree needs to be rendered into some kind of container element, so we often create an empty <div> for this purpose. But maybe the React components themselves are inline-block and shouldn’t create a block-level element, so I find it’s best to add display:contents to this container so that the React component can control the flow instead of the container.

This isn’t hard to do, but neither <div> nor <span> feels right for this purpose because neither traditionally has this flow. It might improve HTML readability if you knew what the element was doing by default.

React supports fragments via React.Fragment/<>...</>, nullifying this use case.

Separately, I do have a proposal specifically with frameworks in mind, to provide a more direct variant that is intentionally not visible to CSS: Proposal: Live fragments

I’m talking about the DOM node that you render React into. React.Fragment does not help you there.