[css-content] content: contents will not be compatible.

[emilio]

I was fixing a Gecko compat issue (webcompat/web-bugs#46914) which is present because we always serialize content: normal as content: none, even on elements.

I'm going to fix Gecko to follow the spec and getComputedStyle() returns none for pseudo-elements, but not for elements. But such code wouldn't work if we were to make content: normal compute to content: contents on elements either, which is what the latest draft specifies: https://drafts.csswg.org/css-content/#content-property

So I propose for content: normal to compute to itself for elements, and removing content: contents from the spec.

[Loirooriol]

Changing the computed value of content: normal seems bad.

If content: normal computes to contents in elements, it means that in

#foo { content: normal }
#foo::before { content: inherit }

the ::before will inherit content: contents. But in ::before, contents has a very different meaning than normal (even if it will still behave as none because contents can only be used once per element).

I'm also not sure about computing content: normal to none in pseudo-elements. It implies that in

#foo::before {
  content: normal;
  display: list-item;
}
#foo::before::marker {
  content: inherit;
}

the ::before::marker will inherit content: none, even if in markers none has a completely different meaning than normal. Probably not much important since the marker won't be displayed, but IMO seems strange.

So I support content: normal computing to normal in elements and staying as normal in getComputedStyle for compat. I also tend to think that content: normal should compute to normal in pseudo-elements, but probably have a resolved and used value of none.

[faceless2]

We got the content: contents value working last week, and it wasn't immediately obvious what it was useful for, even as we were implementing it. The best I came up with was when either the ::before or ::after pseudo-element need to act as a content-replacement rather than a content-list, but you still need to generate content around the element itself.

The distinction between content-replacement and content-list remains important, as discussed in #2657

Here's a slightly contrived example of how the contents value might be useful, and so (in my opinion) worth keeping:

<style>
a.external {
    content: none;
}
a.external::before {
    content: "(" contents ")";
}
a.external::after {
    content: url(https://upload.wikimedia.org/wikipedia/commons/2/25/External.svg);
    height: 1em;
}
</style>

See <a class="external" href="http://w3.org">w3.org</a> for detail

See (w3.org) for detail

--

I also think removing content: contents would make your proposed ::contents pseudo-element a bit less useful, @Loirooriol.

[Loirooriol]

The problem here is content: normal computing to contents. We could say that content: normal computes to and resolves to normal, but the used value could still be contents. This should be compatible. Then discuss whether contents should be removed or not in another issue.

[emilio]

Yes, that's fair. I was missing the subtle distinction there. But in any case content: normal should not compute to content: contents.