1725208 - [css-content] content:none should have no effect on elements

Status: NEW

(Core :: Layout: Generated Content, Lists, and Counters, defect)

Description

[Mozilla Apprentice]

A resolution was made for csswg-drafts/#6503.

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

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

Discussion.

Comment 1

[Daniel Holbert [:dholbert]]

I think (?) this resolution matches our currently-shipping behavior, as of bug 1719239. (It looks like we've got content:none computing to normal, which is one way of "having no effect". I posted https://github.com/w3c/csswg-drafts/issues/6503#issuecomment-897003683 to confirm that that's the expected behavior now.)

Assuming our shipping behavior is correct, let's use this bug here to remove the (preffed-off) code & tests for the previously-specced behavior.

Question: does that mean just backing out bug 1699964 and bug 1719239, i.e. backing out these commits:
https://hg.mozilla.org/mozilla-central/rev/2f74b16b4001
https://hg.mozilla.org/mozilla-central/rev/dcc1d0a10a11
...to revert things to as-they-were before bug 1699964 landed? (which had none computing to normal AFAICT) Or, is there some part of that commit that we should keep?

Sorry for that work getting removed, Mats. :( It's a shame this didn't turn out to be web-compatible.

Comment 2

[Mats Palmgren (inactive)]

I think (?) this resolution matches our currently-shipping behavior, as of bug 1719239.

Yes, with the pref disabled we should be back to our previous behavior, which I believe is what the WG resolved.
The resolved vs computed value is weird for this case. I assume the WG's intent is to keep that as before also (resolve to normal but compute to none, i.e. it inherits as none). I'm not sure why we do that though - it appears Chrome just computes it to normal. Emilio might know the history of that. (We should handle that detail in a separate bug though, if we need to change it.)

It might be a good idea to keep the (other) code as is for now, until the WG resolves whether to add a new value for the preffed-on behavior, so we can easily tweak it to implement that. Backing out works too I guess, if we don't expect an answer anytime soon... I think we should request a resolution on this now though, while we're here, and not leave it lingering forever...

Comment 3

[Mats Palmgren (inactive)]

I filed https://github.com/w3c/csswg-drafts/issues/6511 to request a resolution on that too...

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.