Intent to Ship: CSSImportRule.styleSheet

[Amos Lim]

Contact emails

eui-sa...@samsung.com

Explainer

None

Specification

https://drafts.csswg.org/cssom/#the-cssimportrule-interface

Summary

Allow CSSImportRule.styleSheet to be nullable. The styleSheet attribute in CSSImportRule can be null if there is no associated CSS style sheet.

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: Shipped/Shipping

WebKit: No signal

Web developers: No signals

Other signals:

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?

None

Debuggability

None

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

No

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

Yes

https://wpt.fyi/results/css/cssom/cssimportrule.html?label=experimental&label=master&aligned

Flag name on chrome://flags

Finch feature name

CSSImportRuleStyleSheetNullable

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/40266154

Estimated milestones

Shipping on desktop

124

Shipping on Android

124

Shipping on WebView

124

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

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5123480866783232

This intent message was generated by Chrome Platform Status.

[Dan Clark]

An interesting data point: Firefox still crashes when inspecting the property for a styleSheet in this state (test). I guess that's good motivation on their end to make this update and remain interoperable.

-- Dan

[Mike Taylor]

On 2/23/24 8:31 AM, Amos Lim wrote:

Contact emails

eui-sa...@samsung.com

Explainer

None

Would you mind explaining why this is a useful addition for developers? Or is the motivation improved spec compliance?

Specification

https://drafts.csswg.org/cssom/#the-cssimportrule-interface

Summary

Allow CSSImportRule.styleSheet to be nullable. The styleSheet attribute in CSSImportRule can be null if there is no associated CSS style sheet.

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: Shipped/Shipping

WebKit: No signal

Can you request a signal? https://github.com/WebKit/standards-positions

Web developers: No signals

Other signals:

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?

None

Debuggability

None

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

No

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

Yes

https://wpt.fyi/results/css/cssom/cssimportrule.html?label=experimental&label=master&aligned

All of these tests are passing right now - will you be adding new tests?

Flag name on chrome://flags

Finch feature name

CSSImportRuleStyleSheetNullable

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/40266154

Estimated milestones

Shipping on desktop

124

Shipping on Android

124

Shipping on WebView

124

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

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5123480866783232

This intent message was generated by Chrome Platform Status.

--
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/CAOGEg03EdbMR2-x-7taf692_FmX4%2BwBMgFW%2BwaZiM7gs1Zo5-Q%40mail.gmail.com.

[eui-sa...@samsung.com]

>  Would you mind explaining why this is a useful addition for developers? Or is the motivation improved spec compliance?

In both perspectives. The CSS OM spec was fixed because it was not matched with the spec of @import in css-cascade. The behaviour of CSSImportRule is not following @import. 

> Can you request a signal? https://github.com/WebKit/standards-positions

Sure, I filed an issue. https://github.com/WebKit/standards-positions/issues/325

> All of these tests are passing right now - will you be adding new tests?

Yes, I will add new tests in https://wpt.fyi/results/css/cssom/cssimportrule.html?label=experimental&label=master&aligned

I am working on it.
https://chromium-review.googlesource.com/c/chromium/src/+/5065830/8/third_party/blink/web_tests/external/wpt/css/cssom/cssimportrule.html

[Yoav Weiss (@Shopify)]

Do I understand correctly that this would partially align us with Firefox (modulo the crash), and take us away from WebKit interoperability?

If so, it'd be good to understand if:
* There is interest from developers in this

* WebKit is planning to follow

* This has low compat risk (in terms of current sites relying on this value not being null somehow) 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc77a62d-a28b-4111-91a7-aea76bc5a135n%40chromium.org.

[Yoav Weiss (@Shopify)]

Friendly ping on the above questions! :)

[eui-sa...@samsung.com]

Sorry for the delay.

I am not sure if there is any interest from developers. The spec was updated last April [1]. I started this from the spec change and the related crbug.

I filed an issue[2] last week and got a comment[3] in WebKit. The reviewer's worry would be that the lifetime of these objects is not carefully defined and as such when they return null and non-null can end up varying in edge cases.

I thought this was very clear to be changed in spec that CSSOM was not matched with at-rule behavior and it has low compat risk.

[1] https://github.com/w3c/csswg-drafts/issues/8608

[2] https://github.com/WebKit/standards-positions/issues/325

[3] https://github.com/WebKit/standards-positions/issues/325#issuecomment-1966698090

[Daniel Bratell]

(resending to list since I accidentally dropped it)

Hi,

We discussed this intent in the API Owner meeting, and I ended up with some questions.

Question 1: What is the current behaviour in the case where the specification wants us to return null?

Question 2: I understand that Gecko currently follows the specification as it is written, but if this change has a web compat risk, maybe it is the specification that should change. Was that something you considered?

Question 3: What is the web compatibility risk? Do you have any information about how many pages that would be affected (possibly negatively)? We want to have an idea of how impactful a change will be before shipping it, and at least I don't know if this is used by one page in a billion or half the web.

/Daniel

On 2024-03-06 15:48, eui-sa...@samsung.com wrote:

Sorry for the delay.

I am not sure if there is any interest from developers. The spec was updated last April [1]. I started this from the spec change and the related crbug.

I filed an issue[2] last week and got a comment[3] in WebKit. The reviewer's worry would be that the lifetime of these objects is not carefully defined and as such when they return null and non-null can end up varying in edge cases.

I thought this was very clear to be changed in spec that CSSOM was not matched with at-rule behavior and it has low compat risk.

[1] https://github.com/w3c/csswg-drafts/issues/8608

[2] https://github.com/WebKit/standards-positions/issues/325

[3] https://github.com/WebKit/standards-positions/issues/325#issuecomment-1966698090

On Wednesday, March 6, 2024 at 7:28:32 PM UTC+9 yoav...@chromium.org wrote:

Friendly ping on the above questions! :)

On Wed, Feb 28, 2024 at 6:18 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Do I understand correctly that this would partially align us with Firefox (modulo the crash), and take us away from WebKit interoperability?

If so, it'd be good to understand if:
* There is interest from developers in this

* WebKit is planning to follow

* This has low compat risk (in terms of current sites relying on this value not being null somehow) 

On Tue, Feb 27, 2024 at 2:52 AM eui-sa...@samsung.com <eui-sa...@samsung.com> wrote:

>  Would you mind explaining why this is a useful addition for developers? Or is the motivation improved spec compliance?

In both perspectives. The CSS OM spec was fixed because it was not matched with the spec of @import in css-cascade. The behaviour of CSSImportRule is not following @import. 

> Can you request a signal? https://github.com/WebKit/standards-positions

Sure, I filed an issue. https://github.com/WebKit/standards-positions/issues/325

> All of these tests are passing right now - will you be adding new tests?Yes, I will add new tests in https://wpt.fyi/results/css/cssom/cssimportrule.html?label=experimental&label=master&aligned

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f06f0374-76bd-45a1-abe3-8b007d1eca89n%40chromium.org.

[Chris Harrelson]

Hi, we are going to go ahead and close this review. Please let us know if and when you come back to it so we can reopen.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/437bff89-6ed3-4990-b554-f488e49267b2%40gmail.com.