[css-pseudo] Add a ::contents pseudo-element

[Loirooriol]

Some years ago I proposed a ::contents pseudo-element. I have been refining the details in https://github.com/Loirooriol/css-contents, and yesterday someone proposed the same idea, so I decided to file this issue.

To summarize, elements generate a ::before pseudo-elements at the beginning of their contents, and an ::after one at the end. This proposal wraps the contents inside a new ::contents pseudo-element.

In some way this is the opposite of display: contents: it allows you to insert a box between an element and its children, without needing to change the HTML in non-semantic ways.

You can see all the details and examples in https://github.com/Loirooriol/css-contents, but the behavior is:

• ::contents has display: contents by default, via a rule in the UA origin. This can be overridden so that it does generate boxes.
• ::contents can be styled with arbitrary properties.
• ::contents has no effect in replaced elements.
• ::contents inherits from its originating element.
• Elements and text nodes inherit inheritable properties from the ::contents originated by the parent element. For non-inherited properties, inheritance is directly from the parent element (to avoid breaking the inherit keyword).
• Alternatively, inheritance could be from ::contents for all properties, and assign all: inherit to ::contents in UA origin.
• This pseudo-element does not affect selectors.

[dbaron]

For what it's worth, similar ideas of inner and/or outer pseudo-elements have been proposed at various times going back at least 19 years. See for example:

• Ian Hickson, February 1999
• David Baron, March 2000
• Joachim Noreik, April 2003
• CSS Generated and Replaced Content Module, May 2003
• Daniel Schierbeck, December 2005
• ...
• Proposal: Add wrapper pseudo element #588, October 2016 (as Marat Tanalin pointed out)
• Zhang Junzhi, March 2018 (as you cited above)

[Loirooriol]

The old CSS 3 Content was killed with fire and allowed the creation of pseudo-elements outside the element, which is not consistent with ::before and ::after and is less useful.

Additionally, it allowed nested pseudo-elements, which either meant that they were created by the selector (ugly) or that the element tree was infinite (hard to implement?). I purposely avoided this feature in my proposal, at least for the moment.

I had seen the ::wrap proposal in #588. Frankly, I believe it's completely unrealistic. It seems amazing at first glance, but it allows aberrations like

#parent > :nth-child(1)::wrap(2), /* wrapper #1 */
#parent > :nth-child(2)::wrap(2)  /* wrapper #2 */
{border: thick solid lime}

<div id="parent">
  <div>1</div> <!-- belongs to wrapper #1 -->
  <div>2</div> <!-- belongs to wrappers #1 and #2 -->
  <div>3</div> <!-- belongs to wrapper #2 -->
</div>

So the result is not really a tree! I prefer to avoid this can of worms.

But I believe my ::contents is completely feasible (if there is implementation interest).

[inoas]

Could ::contents be miss-leading? My initial assumption when reading the issue title was that it was a selector for non-element contents (text) inside dom nodes.

If we have ::before and ::after what about ::prepend and ::append? - or ::inside

[SelenIT]

For me, ::contents doesn't seem to imply non-element contents only, it can refer to any kind of contents of the element (just like it does in the display:contents case). ::inside itself sounds good, but being contrast to ::before/::after it can seem to imply that those two are not inside the element, also leading to the possible confusion. For text-only contents, something with text- in the name would be more straightforward (see #2208).

::prepend and ::append probably should be the better names for ::before and ::after themselves, but renaming them seems now impossible.

[Loirooriol]

@inoas As @SelenIT says the name comes from display: contents, I think it's easy to remember since that's the default value for ::contents. But yes, ::inside or other names could also work.

[Zhang-Junzhi]

For now, I think this proposal seems to be comparatively considerate, I cannot find a case to break compatibility with pages designed in the current standards.

[frivoal]

Alternatively, inheritance could be from ::contents for all properties, and assign all: inherit to ::contents in UA origin.

That does not sound good. You could always override the ones that you don't like when you turn ::contents { display: /*something other than contents*/} on, but most things would be sort of crazy: double margin, double border, double padding, double outline, double background, double transforms, double float, double clip-path... That doesn't seem it would ever be what you want. I think the original proposal of having the inherit keyword (at least on non inherited properties) go for the actual element is much more useful.

[frivoal]

However, sometimes it is desirable to generate content outside the element. This can be accomplished by adding

div { display: contents; }
div::contents { display: block; /* border, margin, ... */ }

This is so cool, I love it.

[frivoal]

You probably also should write down how this affects selectors, and in particular the child selector, or things like nth-of-type and the like. My expectation is that it would not affect them at all. If that's the case, it is worth stating, to remove any doubt.

[Loirooriol]

most things would be sort of crazy: double margin, double border

Yes, in this case setting some display value wouldn't be enough to enable the pseudo-element, authors would need to also use all: unset to make it behave properly. Which wouldn't be nice at all, but I thought somebody could prefer this over different inheritance paths for different kinds of properties.

This is so cool, I love it.

Yes, it's one of my favorite features too. Making ::before and ::after behave as siblings can be used to fix all kinds of layouts. That's why generating a box inside the element is more useful than outside (as proposed in the old CSS Content), then we don't need ::before-outside or ::after-outside.

You probably also should write down how this affects selectors

Yes, selectors shouldn't be affected

[fantasai]

One of the reasons I keep pushing back on proposals like this is because they break cascading. Once you start styling ::contents, you've forcibly overridden anything on the element itself, even if those rules are higher in the cascade. For that reason, I'd rather we directly solved the problems that are currently being worked around, e.g. we added multiple backgrounds, we are going to add multiple borders, we're adding min-content/max-content/fit-content to width, and we have decided to apply gaps to flex items.

[fantasai]

(Sorry, wrong button.)