[css-ui] Disallow internal pseudo-elements and 'appearance' values

[zcorpan]

Pseudo-elements for internal parts of controls (e.g., ::-webkit-search-cancel-button)
and related 'appearance' values (e.g., searchfield-cancel-button)
must not be exposed to author origin CSS or in getComputedStyle().

If user agents find that they can't remove support for something,
the pseudo-element and the appearance value should both be specified.

Tests:

• 'appearance' values: already covered by css/css-ui/appearance-cssom-001.html
• pseudo-elements & getComputedStyle: [css-ui] Control-internal pseudo-elements should not be supported web-platform-tests/wpt#17008

Part of #3024.

---

cc @tkent-google @foolip @MatsPalmgren @emilio @jwatt

[FremyCompany]

::-webkit-progress-bar { z-index: 1 }

assert_not_equals(getComputedStyle(elm, pe).zIndex, '1', elm.outerHTML);

web-platform-tests/wpt@c12c73e

Wait, what? You are requiring getComputedStyle to not work on any possible property on an unbound set of pseudo-elements? This is wild, and absolutely not something that seems up for discussion or suggested by anyone as far as I'm concerned.

The only changed required is that the appearance property on those pseudos must return a value that is supported by the property, and that is absolutely logical and shouldn't require any specific text except maybe a note; browsers who support special values internally can convert those values to 'auto' if those pseudos currently have a proprietary value today (either for real, or just for gCS purposes).

But in the test you verify that zIndex lies to author about having a value it actually has, this is significantly way beyond the scope of speccing the appearance property.

[FremyCompany]

cc @frivoal @fantasai

[zcorpan]

Well there's also no spec for those pseudo-elements, and getComputedStyle previously only supported ::before and ::after. But you're right that this is not strictly about the appearance property.

What I tried to address here is the concern raised at the 2018 TPAC f2f, about what getComputedStyle() should return for pseudo-elements where the UA stylesheet has a value that's not specified. Then I thought only ::before and ::after was supported, and therefore there was no problem. But CSSOM now allows any pseudo-element it seems.

I can file a new issue for CSSOM to discuss this.

[zcorpan]

#3980

[jugglinmike]

In this context, "a clear button" might be taken to mean "a button with no background color." Scare quotes would help avoid this ("a "clear" button") as would removing the adjective altogether (which seems acceptable given the phrase is immediately followed by a description of the button's purpose).

[zcorpan]

I'm marking this "Needs Design / Proposal" to indicate that this PR is blocked on a resolution of #3980

[zcorpan]

@FremyCompany

The only changed required is that the appearance property on those pseudos must return a value that is supported by the property, and that is absolutely logical and shouldn't require any specific text except maybe a note; browsers who support special values internally can convert those values to 'auto' if those pseudos currently have a proprietary value today (either for real, or just for gCS purposes).

Yes, I think you are correct, or more simply, the css-ui spec could require such values to be the auto value.