[cssom] Should getComputedStyle() support non-standard pseudo-elements?

[zcorpan]

https://drafts.csswg.org/cssom/#dom-window-getcomputedstyle

See #3968 (comment)

Why does getComputedStyle() support any pseudo-element? Previously it only supported ::before and ::after.

This is an issue for appearance because UAs can support non-standard values for non-standard pseudo-elements. (Though css-ui could require auto to be used instead.)

Do we want such pseudo-elements to be available in author CSS? Do we want to support them in getComputedStyle()?

cc @frivoal @fantasai @FremyCompany

[FremyCompany]

We resolved on this last year, based on the fact all browsers de-facto already allowed it to some extent at least. The discussion is saved there if you are looking for some detail in particular:

#2149 (comment)

[zcorpan]

Thank you. So the rationale was "browsers seem to allow it".

The wpt PR for that change added a test for getComputedStyle(div, "totallynotapseudo"), but no other pseudo-elements (apart from before/after which were already tested).

web-platform-tests/wpt#17008 tests non-standard pseudos for controls.

https://wpt.fyi/results/css/css-ui/control-internal-pseudo-elements-getComputedStyle-001.html?sha=c12c73e623 shows results for Firefox and Safari. Chrome results are missing for some reason, but it passes all the tests for me. Which is to say:

• Firefox supports ::-moz-* pseudos in gCS.
• Chrome and Safari don't support any of the tested pseudos in gCS.

[FremyCompany]

If you could add some tests covering the previous decision, that would be awesome :-)

[birtles]

Firefox also supports ::marker as far as I can tell.

[gmksupernova]

{"error": {"message": "", "code": 404}}

[zcorpan]

@gmksupernova web-platform-tests/wpt.fyi#1322

[AmeliaBR]

I was testing unrecognized pseudo-element selectors in the context of #4456 and discovered how much of an inconsistency this issue is.

Test case: https://codepen.io/AmeliaBR/pen/ZEEJeWm

Summary:

Chrome silently ignores invalid or unrecognized selector strings and returns the main element styles. Firefox silently returns an empty style declaration for unrecognized but valid-syntax pseudoelement selectors, which is better, but also returns the parent element results for completely invalid selectors. (Also, separate issue, but there's lots of disagreement on what to return for content on regular elements…)

The current spec clearly requires a TypeError for selector-parsing errors, but doesn't give any guidance about what to do about unrecognized pseudoelement selectors that are syntactically valid. Either way, browsers clearly aren't following the TypeError expectation.

Requiring errors where no one currently throws them could be bad for compat. Maybe the Firefox approach of returning zero-length style declaration objects would be better? (But make it consistent, for invalid syntax selectors, too!)

[flackr]

We were discussing this in the context of #4745. It seems really unfortunate that we have divergent parsing behavior between this and querySelector. I wonder what the usage of getComputedStyle with an unsupported pseudo-element-selector is; maybe we could throw errors consistent with selectors-4 parsing?

[emilio]

I think we resolved that in #2149, browsers haven't been updated though.

[ExE-Boss]

What does #2149 do with unknown ‑webkit‑ pseudo‑elements?

I would expect that:

getComputedStyle(element, "::-webkit-unsupported");

would throw.