Intent to Ship: CSS :lang pseudo class level 4

Roger Zanoni

unread,

Mar 16, 2023, 6:10:01 AM3/16/23

to blin...@chromium.org

Summary

The :lang CSS pseudo-class currently matches elements based on level 3 specs logic, which describes a prefix-matching rule to match language values. The level 4 spec changes this matching logic, supporting argument-list and language range matching (according to the specs of the extended filtering operation from RFC4647 - Matching of language tags - section 3.3.2, and the simple priority list matching described on section 2.3)

Blink component

Blink>CSS

Search tags

css, lang, pseudo

TAG review

Just extends functionality of the existing :lang selector.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This change mostly extends :lang functionality and don't change existing behavior, except for adding implicit wildcard matching, which breaks one of the existing level 3 tests: https://wpt.fyi/results/css/selectors/i18n/css3-selectors-lang-005.html

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1121792)

WebKit: Shipped/Shipping (https://webkit.org/status/#feature-css-selector-:lang)

Web developers: No signals

Other signals: CSSWG consensus to ship documented in https://www.w3.org/TR/css-2017/#experimental (CSSWG includes reps from all major browser vendors)

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?

No.

Debuggability

Automatically supported, same as other pseudo-elements.

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

Yes

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

No

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1281157

Estimated milestones

No milestones specified

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).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5071058079055872

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dd1cdecb-3bd5-cf6c-bf5c-120735d36ee6%40igalia.com

This intent message was generated by Chrome Platform Status.

Mustafa Teke

unread,

Mar 16, 2023, 12:42:05 PM3/16/23

to Roger Zanoni, blin...@chromium.org

16 Mar 2023 Per, saat 13:09 tarihinde Roger Zanoni <rza...@igalia.com> şunu yazdı:

--
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/29b5144d-ba62-bfc9-677c-a9a7e72c09f9%40igalia.com.

--

🏌️

Yoav Weiss

unread,

Mar 17, 2023, 5:59:14 AM3/17/23

to Roger Zanoni, blin...@chromium.org

On Thu, Mar 16, 2023 at 11:09 AM Roger Zanoni <rza...@igalia.com> wrote:

Contact emails
rza...@igalia.com

Explainer
https://github.com/rogerzanoni/docs/tree/main/lang-level-4

Specification
https://www.w3.org/TR/selectors-4/#the-lang-pseudo

Summary

The :lang CSS pseudo-class currently matches elements based on level 3 specs logic, which describes a prefix-matching rule to match language values. The level 4 spec changes this matching logic, supporting argument-list and language range matching (according to the specs of the extended filtering operation from RFC4647 - Matching of language tags - section 3.3.2, and the simple priority list matching described on section 2.3)

Blink component
Blink>CSS

Search tags
css, lang, pseudo

TAG review
Just extends functionality of the existing :lang selector.

TAG review status
Not applicable

Risks

Interoperability and Compatibility

This change mostly extends :lang functionality and don't change existing behavior, except for adding implicit wildcard matching, which breaks one of the existing level 3 tests: https://wpt.fyi/results/css/selectors/i18n/css3-selectors-lang-005.html

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1121792)

Can you file for a Mozilla position? https://bit.ly/blink-signals

WebKit: Shipped/Shipping (https://webkit.org/status/#feature-css-selector-:lang)

Web developers: No signals

Other signals: CSSWG consensus to ship documented in https://www.w3.org/TR/css-2017/#experimental (CSSWG includes reps from all major browser vendors)

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?

No.

Debuggability

Automatically supported, same as other pseudo-elements.

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

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

Why not? How do we know that WebKit actually supports this if it's not tested?

Flag name

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1281157

Estimated milestones

No milestones specified

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).

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5071058079055872

Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dd1cdecb-3bd5-cf6c-bf5c-120735d36ee6%40igalia.com

This intent message was generated by Chrome Platform Status.

--

Philip Jägenstedt

unread,

Mar 29, 2023, 12:00:19 PM3/29/23

to Yoav Weiss, Roger Zanoni, blin...@chromium.org

Hi Roger,

I took a look for the tests, and am wondering if the tests added here are for Level 4?

https://github.com/web-platform-tests/wpt/pull/37950

At least some of them are already passing in Chrome Dev (with experimental features enabled), but not Chrome stable, so some of these tests seem relevant. Overall, is the test coverage for this feature in WPT satisfactory?

As Yoav said, a standards-positions issue for Gecko would be great, mostly as a heads up that we're shipping this and it's already shipping in Safari.

Best regards,

Philip

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW9m-osR6jJ0jNC9-w_j9jVRR7GaB41%2B%2BBPPJXOQAbSqw%40mail.gmail.com.

Roger Zanoni

unread,

Mar 30, 2023, 2:58:10 AM3/30/23

to blink-dev, yoav...@chromium.org, blin...@chromium.org, Roger Zanoni

Hi Yoav, thanks for checking, I will answer inline

On Friday, March 17, 2023 at 10:59:14 AM UTC+1 yoav...@chromium.org wrote:

On Thu, Mar 16, 2023 at 11:09 AM Roger Zanoni <rza...@igalia.com> wrote:

Contact emails rza...@igalia.com

Explainer https://github.com/rogerzanoni/docs/tree/main/lang-level-4

Specification https://www.w3.org/TR/selectors-4/#the-lang-pseudo

Summary
The :lang CSS pseudo-class currently matches elements based on level 3 specs logic, which describes a prefix-matching rule to match language values. The level 4 spec changes this matching logic, supporting argument-list and language range matching (according to the specs of the extended filtering operation from RFC4647 - Matching of language tags - section 3.3.2, and the simple priority list matching described on section 2.3)

Blink component Blink>CSS

Search tags css, lang, pseudo

TAG review Just extends functionality of the existing :lang selector.

TAG review status Not applicable

Risks

Interoperability and Compatibility
This change mostly extends :lang functionality and don't change existing behavior, except for adding implicit wildcard matching, which breaks one of the existing level 3 tests: https://wpt.fyi/results/css/selectors/i18n/css3-selectors-lang-005.html

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1121792)

Can you file for a Mozilla position? https://bit.ly/blink-signals

Filed: https://github.com/mozilla/standards-positions/issues/735

WebKit: Shipped/Shipping (https://webkit.org/status/#feature-css-selector-:lang)

Web developers: No signals

Other signals: CSSWG consensus to ship documented in https://www.w3.org/TR/css-2017/#experimental (CSSWG includes reps from all major browser vendors)

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?

No.

Debuggability
Automatically supported, same as other pseudo-elements.

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

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

Why not? How do we know that WebKit actually supports this if it's not tested?

It's tested by Webkit, but not by wpt tests, it's tested by https://github.com/WebKit/WebKit/blob/main/LayoutTests/fast/selectors/lang-extended-filtering.html and https://github.com/WebKit/WebKit/blob/main/LayoutTests/fast/selectors/lang-extended-filtering-with-string-arguments.html

I'm still working on the wpt tests to make them cover as much as it's tested there, I will update my CL with more tests.

Roger Zanoni

unread,

Mar 30, 2023, 3:09:05 AM3/30/23

to blink-dev, blin...@chromium.org

Hi Philip, thanks for looking for the tests, they are relevant but they don't cover some cases, like implicit wildcard matching with more than one language subtags, private singleton matching

I think we should add more cases to wpt tests targeting specific level4 matching logic, like the cases that are tested on https://github.com/WebKit/WebKit/blob/main/LayoutTests/fast/selectors/lang-extended-filtering.html and https://github.com/WebKit/WebKit/blob/main/LayoutTests/fast/selectors/lang-extended-filtering-with-string-arguments.html

About the standards-positions issue, I filed it on https://github.com/mozilla/standards-positions/issues/735

Yoav Weiss

unread,

Apr 4, 2023, 11:58:55 PM4/4/23

to Roger Zanoni, blink-dev

LGTM1 once this is WPT tested with good coverage and our shipped behavior matches both WebKit and the spec. Please get back to this thread if e.g. the implemented WebKit behavior varies from the specified one.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ecdf13bd-734a-430c-bb1d-7d6f5c43ae71n%40chromium.org.

Philip Jägenstedt

unread,

Apr 5, 2023, 11:42:08 AM4/5/23

to Yoav Weiss, Roger Zanoni, blink-dev

LGTM2, and thanks for taking another look over the tests and ensuring solid coverage in WPT!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXQF3bDjxk4tfgG-0KZPXEuE2UfUS1F5veLtGOd%2BdPfEQ%40mail.gmail.com.

Daniel Bratell

unread,

Apr 5, 2023, 11:42:51 AM4/5/23

to Yoav Weiss, Roger Zanoni, blink-dev

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXQF3bDjxk4tfgG-0KZPXEuE2UfUS1F5veLtGOd%2BdPfEQ%40mail.gmail.com.

Daniel Bratell

unread,

Apr 5, 2023, 11:43:55 AM4/5/23

to Yoav Weiss, Roger Zanoni, blink-dev

Make that LGTM3, after Philip's LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d2e1b9e1-4e73-90f3-7c29-d6304afdfd31%40gmail.com.

Jonathan Kew

unread,

Apr 8, 2023, 10:15:34 AM4/8/23

to blink-dev, Roger Zanoni, yoav...@chromium.org, blin...@chromium.org

Looking at the webkit tests, I"m concerned that some of them may conflict with the spec (as I understand it), and this presumably reflects an issue with webkit's implementation.

Specifically, in https://github.com/WebKit/WebKit/blob/main/LayoutTests/fast/selectors/lang-extended-filtering.html there are cases like

shouldBe('document.querySelectorAll(":lang(foöÉbÁr)").length', '1');

which appear to expect a non-ASCII :lang() code to match. This seems unexpected to me, given that the Selectors 4 spec refers to BCP47

> An element’s content language matches a language range if, when represented in BCP 47 syntax [BCP47], it matches that language range in an extended filtering operation per [RFC4647] Matching of Language Tags(section 3.3.2).

and BCP47 specifically mentions that

> the language tags described in this document are sequences of characters from the US-ASCII [ISO646] repertoire

From this, I would conclude that a string containing non-ASCII characters cannot be a "language tag" per BCP47 at all, and therefore cannot possibly match.

fantasai

unread,

Apr 10, 2023, 11:09:00 PM4/10/23

to blin...@chromium.org, Jonathan Kew

On 4/8/23 05:15, Jonathan Kew wrote:
> Looking at the webkit tests, I"m concerned that some of them may conflict with
> the spec (as I understand it), and this presumably reflects an issue with
> webkit's implementation.

> [...]

> and BCP47 specifically mentions that
>
>> the language tags described in this document are sequences of characters from

> the US-ASCII [ISO646 <https://www.rfc-editor.org/rfc/rfc5646#ref-ISO646>]

> repertoire
>
> From this, I would conclude that a string containing non-ASCII characters
> cannot be a "language tag" per BCP47 at all, and therefore cannot possibly match.

I'm not sure that behavior's wrong, so much as undefined then?

I'm OK with either treating non-ASCII tags as not matching, or passing them
through; but that's probably something to discuss in a CSSWG issue with i18nWG
input.

~fantasai

Reply all

Reply to author

Forward