[css-content] Implementing content:none on elements is not web-compatible

[MatsPalmgren]

The current spec says:

none
On elements, this inhibits the children of the element from being rendered as children of this element, as if the element was empty.

We implemented that in Gecko (bug 1699964) but sadly it broke a bunch of sites so we had to disable it for now (bug 1719239).

So the spec needs to say that none has no effect on elements (what all UAs currently implement AFAIK).
If we want to retain this feature, then we need a new keyword for it (children-none or whatever).

CC @emilio

[css-meeting-bot]

The CSS Working Group just discussed content:none, and agreed to the following:

• RESOLVED: spec content:none as having no effect on elements

The full IRC log of that discussion

<fantasai> Topic: content:none
<Rossen_> github: https://github.com//issues/6503
<fantasai> emilio: We implemented it, broke tons of sites
<fantasai> emilio: We should at least fix the spec to say that content:none has no effect on non-pseudo elements
<fantasai> emilio: It's a bummer because 'content' does have effects on some elements
<fantasai> emilio: We could add another value to the content property to represent that behavior
<fantasai> Rossen_: how broken?
<fantasai> emilio: content:none suppresses boxes for children of element
<fantasai> emilio: sites were specifying it on a bunch of stuff using e.g. * { content:none; }
<fantasai> emilio: initial value is normal
<fantasai> florian: I wouldn't have expected it to be Web-compatible, has been a no-op for a long time, so mistakenly applied in lots of places
<fantasai> emilio: any objection to change the spec to match reality?
<fantasai> emilio: other question is should we add a new value
<Rossen_> q?
<Rossen_> ack fantasai
<florian> fantasai: we should spec it
<florian> fantasai: if we need a new keyword, I'd suggest "empty"
<florian> fantasai: not too sure what the use cases are though
<fantasai> Rossen_: any other comments?
<fantasai> emilio: not sure we should even add the keyword, we implemented for completeness
<rachelandrew> it would be interesting to see if authors have use cases
<fantasai> ??: I think there could be some interesting cases for having the box but not its contents
<bradk> That was me
<astearns> s/??/bradk/
<TabAtkins> we can just leave the discussion out of this issue for now, and open a fresh issue arguing for adding this new keyword
<fantasai> emilio: also interesting question about interaction with content-visibility:hidden
<TabAtkins> no reason to tie it to this discussion
<astearns> +1 to new issue for use cases
<fantasai> bradk: maybe ask authors
<emilio> +1
<fantasai> Rossen_: ok, let's deal with that in a separate issue
<fantasai> RESOLVED: spec content:none as having no effect on elements

[dholbert]

Just to clarify what "having no effect" is going to mean here: it looks like in both Firefox and Chromium, content:none just computes to normal. Is that what we want to spec here? (i.e. are we saying none is effectively an alias for normal, and so it computes to normal) Or is this going to be something more subtle?

(For completeness: I tested WebKit as well, but their getComputedStyle implementation seems to just return the empty string for the computed value of content, when the specified value is normal or none, so I'm not as sure what's going on there.)

[MatsPalmgren]

Gecko resolves none to normal for elements but still computes it to none, i.e. it inherits as none. For example:

<style>
li { content: none }
li::marker { content: inherit }
</style>

<ul><li>x</ul>

<script>
let li = document.querySelector('li');
li.textContent = getComputedStyle(li).content + ' ' +
                 getComputedStyle(li, '::marker').content;
</script>

Firefox: shows "normal none", and no bullet since ::marker inherited none (note that we did this even before implementing content:none for elements so there was no change in this regard from those patches)
Chrome: shows "normal normal" , and a bullet

I think we need to sort this out while we're here since it might be a web-compat issue too...
See also similar issues: #1757 #821 #4632

[Loirooriol]

Just to clarify Chromium's behavior. Chromium implements content as a single linked list. Both normal and none used to be represented as nullptr (empty list). So they were equivalent. When serializing a computed style, nullptr would become none for ::before and ::after, and normal for other things.

But I changed the behavior when implementing ::marker. Now empty list means normal, and none has its own value. So they now have different computed values. But I didn't want to have compat problems, so I kept the old serialization behavior for things other than ::marker.

Regarding the inherit example, ::marker fails to inherit none because content: inherit never works in Chromium:

void Content::ApplyInherit(StyleResolverState& state) const {
  // FIXME: In CSS3, it will be possible to inherit content. In CSS2 it is not.
  // This note is a reminder that eventually "inherit" needs to be supported.
}

[dholbert]

[note: to reduce confusion/noise, I've just deleted a drive-by comment which was just a copypaste of the initial comment here with nothing additional added. The poster seems to have posted similar comments in other repos as well; not sure if they're a bot or just testing out github, but in any case it wasn't adding information here.]