[css-content-3] Let UAs parse `content` syntax with alternative text even without support for it

@hamishwillee noted in https://bugzil.la/1281158#c3 that the new syntax of content including the optional alternative text lets user agents not supporting it ignore it.

And yes, it is the standard behavior to ignore a property declaration when the value is unsupported.
Though it also means for authors that they have to work around that.

1. They can write the declaration once with and once without alternative text. (Example taken from the Mozilla bug.)

a::before {
  content: url("https://mozorg.cdn.mozilla.net/media/img/favicon.ico");
  content: url("https://mozorg.cdn.mozilla.net/media/img/favicon.ico") / " MOZILLA: ";
}

2. They can test for the new Syntax via @supports.

a::before {
  content: url("https://mozorg.cdn.mozilla.net/media/img/favicon.ico");
}

@supports (content: url("https://mozorg.cdn.mozilla.net/media/img/favicon.ico") / " MOZILLA: ") {
  a::before {
    content: url("https://mozorg.cdn.mozilla.net/media/img/favicon.ico") / " MOZILLA: ";
  }
}

Both solutions obviously require a lot of extra writing. And as the alternative text is just an accessibility addition to the previous syntax, I wonder whether it'd make sense to allow User Agents to parse the new syntax without interpreting the alternative text until they have their implementations ready.

This would allow authors to switch to the new syntax without having to check for it or provide a fallback. I.e. the example from above could then be written as

a::before {
  content: url("https://mozorg.cdn.mozilla.net/media/img/favicon.ico") / " MOZILLA: ";
}

This example is actually mainly the one from MDN.

The downside of this approach is that an author won't be able to check whether the alternative text is actually supported by the browser or not. But there also wouldn't be the need anymore for them to do that, in most cases.

This might be a leading case for other properties as well.

Sebastian

Start with the proposed CSS Content 3 syntax in this issue, then review the linked Mozilla bug and MDN example for context. Determine whether user agents should parse alternative text without interpreting it, and document the CSS Working Group's decision and any resulting specification changes.