Intent to Ship: Standard-compliant pseudo-element argument for getComputedStyle & KeyframeEffect

[Noam Rosenthal]

Contact emails

nrose...@chromium.org

Explainer

None

Specification

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

Summary

The pseudo element argument in some APIs ( getComputedStyle(element, pseudo) and new KeyframeEffect(target, keyframes, {pseudoElement}) is currently parsed in a way that doesn't match the spec - e.g. it allows pseudo-elements without ":", it doesn't parse whitespace correctly if there is argument, and several other issues. There are many failing tests around this. Recently webkit fixed this to more closely match the spec. Proposing to modify the behavior to match the webkit implementation and the spec, un-skipping most of the tests. Using a chromestatus entry for this as it's a web-facing behavior change.

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: Shipped/Shipping (https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-190#Resolved-Issues) Safari fixed the compat issues in the latest STP.

Web developers: No signals

Other signals:

Ergonomics

Shouldn't be, this is fixing an existing feature.

Activation

This should be mostly compatible with existing usage.

Security

N/A

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

N/A

Debuggability

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

This mainly captured in the following two tests, that should be mostly unskipped after this change. https://wpt.fyi/results/css/cssom/getComputedStyle-pseudo-with-argument.html https://wpt.fyi/results/css/cssom/getComputedStyle-pseudo.html

Flag name on chrome://flags

CSSComputedStyleFullPseudoElementParser

Finch feature name

CSSComputedStyleFullPseudoElementParser

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/328470598

Adoption expectation

It's not a widely use feature, but mostly because it's been incompatible across browsers for a long time. With view-transitions making more use of pseudo-elements this will likely become more important.

Estimated milestones

Shipping on desktop

125

Shipping on Android

125

Shipping on WebView

125

Shipping on WebView

125

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None, this is to match existing spec

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6230945893187584

This intent message was generated by Chrome Platform Status.

[Dan Clark]

Am I correct in understanding that Gecko already mostly matches the behavior in the spec? I see that Firefox also fails most of the WPTs at https://wpt.fyi/results/css/cssom/getComputedStyle-pseudo-with-argument.html?label=master&label=experimental&aligned, but I guess that's because they haven't shipped ::highlight() pseudos.

How are you thinking about the compatibility risk? If we're making the parsing stricter in certain ways, presumably sites depending on that behavior could break. Omitting the ":" seems like it could be a particularly easy mistake to make. On the other hand the fact that WebKit (and I guess Gecko) already did it is an encouraging signal.

-- Dan Clark

[Noam Rosenthal]

On Fri, Mar 8, 2024 at 11:56 PM 'Dan Clark' via blink-dev <blin...@chromium.org> wrote:

Am I correct in understanding that Gecko already mostly matches the behavior in the spec? I see that Firefox also fails most of the WPTs at https://wpt.fyi/results/css/cssom/getComputedStyle-pseudo-with-argument.html?label=master&label=experimental&aligned, but I guess that's because they haven't shipped ::highlight() pseudos.

Correct, it's because of ::highlight. It passes most of the tests in https://wpt.fyi/results/css/cssom/getComputedStyle-pseudo.html?label=master&label=experimental&aligned.

 

How are you thinking about the compatibility risk? If we're making the parsing stricter in certain ways, presumably sites depending on that behavior could break. Omitting the ":" seems like it could be a particularly easy mistake to make. On the other hand the fact that WebKit (and I guess Gecko) already did it is an encouraging signal.

Correct. Also, intending to keep current behavior for old pseudos that support single-colon in regular CSS (before, after, first-line, first-letter). If there are other exceptions with a lot of existing code we can consider adding them here.

The way I'm thinking about this from a compat perspective is that if we keep supporting single-colon/no-colon for all pseudos, there would be more non-spec-compliant code written with those, that would seem to work in chrome while developing and then not work in other browsers. So aligning with the spec now is hopefully cleaner.

However, if there are reasons to keep some of the parsing more lenient here I'm happy to hear and find the best solution for the web platform.

[Domenic Denicola]

Thanks Dan for raising the compat concerns here. It seems like a mistake that the original Intent says "None" for that, and I think we need to get that section of the Chrome Status entry fleshed out before considering approvals here.

What I'm hearing so far is that we think the compat risks might be small because Gecko and WebKit are already using strict parsing. That's something, but can we do better? For example:

• Is there any upper bound on the potential number of broken page views? Ideally we'd have a use counter for how many times the lenient parsing is triggered, but for an upper bound even just a use counter for how many times these arguments are supplied to getComputedStyle()/new KeyframeEffect() would help.
• Can we do an HTTP archive analysis of some sort?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYbLLqWEjSNYnt6Pw%2BcV75%3DryQ%3DbsDM%3DAXtktKW6C__kkQ%40mail.gmail.com.

[Noam Rosenthal]

On Mon, Mar 11, 2024 at 5:57 AM Domenic Denicola <dom...@chromium.org> wrote:

Thanks Dan for raising the compat concerns here. It seems like a mistake that the original Intent says "None" for that,

Good point, I updated it.

 

and I think we need to get that section of the Chrome Status entry fleshed out before considering approvals here. 

What I'm hearing so far is that we think the compat risks might be small because Gecko and WebKit are already using strict parsing. That's something, but can we do better? For example:

• Is there any upper bound on the potential number of broken page views? Ideally we'd have a use counter for how many times the lenient parsing is triggered, but for an upper bound even just a use counter for how many times these arguments are supplied to getComputedStyle()/new KeyframeEffect() would help.
• Can we do an HTTP archive analysis of some sort?

Will do both and come back with results. 

[Noam Rosenthal]

I've run a rough HTTP archive query on it, testing all HTTP responses last month (666 million):
getComputedStyle with an argument that doesn't begin with "::" is called in 0.45% of pages, out of which 55% is ":before", 28% is after, and the vast majority of the rest are invalid pseudo-element names (e.g. "height" or "display"). 
There were extremely rare cases that would be affected: getComputedStyle(element, ":placeholder") or getComputedStyle(element, ":marker"), about 0.00001% of requests (34 out of 666 million).
I'm running a more refined version of the query but I doubt I'll get significantly different results.

So I'd perhaps classify backwards compatibility as low-risk?

[Domenic Denicola]

Awesome, thanks so much for the quick investigation! That indeed sounds pretty low risk to me. LGTM1.

[Yoav Weiss (@Shopify)]

On Monday, March 11, 2024 at 6:36:07 AM UTC-4 Noam Rosenthal wrote:

I've run a rough HTTP archive query on it, testing all HTTP responses last month (666 million):
getComputedStyle with an argument that doesn't begin with "::" is called in 0.45% of pages, out of which 55% is ":before", 28% is after, and the vast majority of the rest are invalid pseudo-element names (e.g. "height" or "display"). 
There were extremely rare cases that would be affected: getComputedStyle(element, ":placeholder") or getComputedStyle(element, ":marker"), about 0.00001% of requests (34 out of 666 million).

Is this considering all requests? What's the %age when only looking at HTML and CSS responses? (or on pages)

 

I'm running a more refined version of the query but I doubt I'll get significantly different results.

So I'd perhaps classify backwards compatibility as low-risk?

On Mon, Mar 11, 2024 at 9:32 AM Noam Rosenthal <nrose...@chromium.org> wrote:

On Mon, Mar 11, 2024 at 5:57 AM Domenic Denicola <dom...@chromium.org> wrote:

Thanks Dan for raising the compat concerns here. It seems like a mistake that the original Intent says "None" for that,

Good point, I updated it.

 

and I think we need to get that section of the Chrome Status entry fleshed out before considering approvals here. 

What I'm hearing so far is that we think the compat risks might be small because Gecko and WebKit are already using strict parsing. That's something, but can we do better? For example:

• Is there any upper bound on the potential number of broken page views? Ideally we'd have a use counter for how many times the lenient parsing is triggered, but for an upper bound even just a use counter for how many times these arguments are supplied to getComputedStyle()/new KeyframeEffect() would help.
• Can we do an HTTP archive analysis of some sort?

Will do both and come back with results. 

On Sun, Mar 10, 2024 at 5:55 PM Noam Rosenthal <nrose...@chromium.org> wrote:

On Fri, Mar 8, 2024 at 11:56 PM 'Dan Clark' via blink-dev <blin...@chromium.org> wrote:

Am I correct in understanding that Gecko already mostly matches the behavior in the spec? I see that Firefox also fails most of the WPTs at https://wpt.fyi/results/css/cssom/getComputedStyle-pseudo-with-argument.html?label=master&label=experimental&aligned, but I guess that's because they haven't shipped ::highlight() pseudos.

Correct, it's because of ::highlight. It passes most of the tests in https://wpt.fyi/results/css/cssom/getComputedStyle-pseudo.html?label=master&label=experimental&aligned.

 

How are you thinking about the compatibility risk? If we're making the parsing stricter in certain ways, presumably sites depending on that behavior could break. Omitting the ":" seems like it could be a particularly easy mistake to make. On the other hand the fact that WebKit (and I guess Gecko) already did it is an encouraging signal.

Correct. Also, intending to keep current behavior for old pseudos that support single-colon in regular CSS (before, after, first-line, first-letter). If there are other exceptions with a lot of existing code we can consider adding them here.

The way I'm thinking about this from a compat perspective is that if we keep supporting single-colon/no-colon for all pseudos, there would be more non-spec-compliant code written with those, that would seem to work in chrome while developing and then not work in other browsers. So aligning with the spec now is hopefully cleaner.

However, if there are reasons to keep some of the parsing more lenient here I'm happy to hear and find the best solution for the web platform.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Noam Rosenthal]

On Wed, Mar 13, 2024 at 12:36 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Monday, March 11, 2024 at 6:36:07 AM UTC-4 Noam Rosenthal wrote:

I've run a rough HTTP archive query on it, testing all HTTP responses last month (666 million):
getComputedStyle with an argument that doesn't begin with "::" is called in 0.45% of pages, out of which 55% is ":before", 28% is after, and the vast majority of the rest are invalid pseudo-element names (e.g. "height" or "display"). 
There were extremely rare cases that would be affected: getComputedStyle(element, ":placeholder") or getComputedStyle(element, ":marker"), about 0.00001% of requests (34 out of 666 million).

Is this considering all requests? What's the %age when only looking at HTML and CSS responses? (or on pages)

I refined the query a bit and use January dataset. So this will potentially affect 89 pages out of 17M (226 responses of 420M). So one in every 200,000 pages: 

Total Pages	17,399,427
Total URLs	420,144,799
Potentially affected Pages	89
Potentially affected URLs	226
% Affected Pages	0.0005%
% affected URLs	0.0001%

I'm still running the refinement to only use HTML/JS responses (this is not CSS) but I'm not sure it will tell us something new.

[Yoav Weiss (@Shopify)]

LGTM2

Pages %age seems sufficiently small to give confidence here. Thanks!!

 

[Daniel Bratell]

LGTM3

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSLTt%3DMgVzGw%2Beij8Hsga4%3DTaqDHcsDKwUH3H0khN0acSw%40mail.gmail.com.