Intent to Ship: Constructable Stylesheet Objects

[Rakina Zata Amni‏]

Contact emails

rak...@chromium.org, dom...@chromium.org, taba...@chromium.org

Explainer

https://github.com/WICG/construct-stylesheets/blob/gh-pages/explainer.md

Spec

https://wicg.github.io/construct-stylesheets/

(See https://github.com/w3c/csswg-drafts/issues/3433 for intent to migrate into the main CSSOM specification.)

TAG review: https://github.com/w3ctag/design-reviews/issues/308

Summary

The API provides a way to create CSSStyleSheet objects from script, without needing <style> or <link> elements. Script can optionally modify the stylesheet by adding, removing, or replacing rules in it. Each stylesheet object can then be used in document/shadow roots, applying to those document/shadow roots' styling scope.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/irhrlr6n5YQ/LOS8xSGsBwAJ

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

Yes

Risks

Interoperability and Compatibility

Blink will be the first to implement this feature, but we have received positive signs from other browser vendors.

Edge: No signals

Firefox: Public support (interacted in GitHub & TPAC, position: “worth prototyping”)

Safari: No public signals (helpful engagement during TPAC, though noting minuted)

Web / Framework developers: Positive signals from some web developers (Salesforce, participants in TPAC) & frameworks (Polymer, Ionic).

Ergonomics

CSS text parsing is done synchronously in Blink, so calls to CSSStyleSheet.replace and CSSStyleSheet.replaceSync might block for some time if given a large chunk of text, but import loading will not be blocking as it’s done asynchronously (or prohibited in the case of the “replace” method). The specification is structured to allow asynchronous/off-main-thread CSS parsing, so in the future if Blink's architecture becomes flexible enough to allow this, it will require no changes to author code.

Activation

• Feature-detecting this is quite simple (checking document.adoptedStyleSheets)

• A simple polyfill would create <style> elements when the constructor is called and update the text content when replaced, etc. There’s work going on for creating a polyfill.

• Web component frameworks (like Polymer, Salesforce, Ionic, etc.) are expected to be major consumers of this feature, automatically using it behind the scenes for their users.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes, test suite: https://wpt.fyi/results/css/cssom/CSSStyleSheet-constructable.html (just moved it so still showing up as “missing”, but the test is there)

Entry on the feature dashboard

https://www.chromestatus.com/feature/5394843094220800

[Boris Zbarsky‏]

On 12/13/18 4:27 AM, Rakina Zata Amni wrote:
> Blink will be the first to implement this feature, but we have received
> positive signs from other browser vendors.

Hello,

It's my understanding that what is being proposed for shipping is rather
different from what was discussed at TPAC, because the thing we all
agreed on at TPAC ran into some sort of Chrome-internal implementation
constraints.

I know for a fact that Mozilla has not had a chance to review the
proposed changes to the behavior. Do you plan to wait for such review
and feedback from other browsers before shipping this?

Why was the idea of just fixing Chrome's implementation to do the
agreed-on thing rejected? Is the relevant discussion public, by any chance?

-Boris

[Domenic Denicola‏]

Hey Boris!

We had a pretty public discussion, and indeed pinged you, in https://github.com/WICG/construct-stylesheets/pull/69 . Anne got a chance to review there, and was really helpful in fixing various issues.

As I explain in the thread, we did add a restriction to the spec partially motivated by the difficulty of implementing multi-document constructible stylesheets in Chrome. But, we think (and from what I recall of TPAC, others thought so too) that this restriction was desirable anyway as a simplification to the model.

We'd be happy to loosen that restriction in the spec, either now---if Mozilla thinks multi-document constructible stylesheets are important to their customers---or later, once we have customer demand for multi-document constructible stylesheets. But, as I mention in the thread, starting simpler seems nicer, so tentatively Rakina merged the PR to add the restriction, with the understanding that we'd be happy to continue discussing with you, Anne, or anyone else from Mozilla who finds multi-document constructible stylesheets essential to their support of the feature.

 

-Boris

[Boris Zbarsky‏]

On 12/13/18 7:55 AM, Domenic Denicola wrote:
> We had a pretty public discussion, and indeed pinged you, in
> https://github.com/WICG/construct-stylesheets/pull/69

Thank you. That hadn't made it to the top of my backlog of github bits
yet. I'll try to follow up there in the next few days.

-Boris

[bratell‏]

Boris, did you find time to take a look?

/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/ac814577-4c9e-d431-0354-6d5f1c6f37c2%40mit.edu.

[Boris Zbarsky‏]

On 12/18/18 9:30 AM, bratell wrote:
> Boris, did you find time to take a look?

I read through the updated spec today, but I'm still thinking through
the implications of the cross-document bits.

-Boris

[Yoav Weiss‏]

Starting simpler does indeed seem nicer, especially when there's no clear use-case for the extra complexity. (Boris - please correct me if I'm wrong about the lack of use-case here)

The only thing I'm concerned about here is that ignoring those stylesheets on other documents can lead to a scenario where adding such support in the future is not web compatible.

At the same time, I understand that throwing here would add a lot of complexity. How confident are we that we would or would not want to support the multi-document scenario in the future? 

 

 

-Boris

--
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/CAM0wra8Vpx08xJJbCeyR5SqscxE%2BdJ3f0k28v_sYNgC3tOAeww%40mail.gmail.com.

[Domenic Denicola‏]

On Wed, Jan 2, 2019 at 10:32 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Thu, Dec 13, 2018 at 1:55 PM Domenic Denicola <dom...@chromium.org> wrote:

On Thu, Dec 13, 2018 at 8:10 PM Boris Zbarsky <bzba...@mit.edu> wrote:

On 12/13/18 4:27 AM, Rakina Zata Amni wrote:
> Blink will be the first to implement this feature, but we have received
> positive signs from other browser vendors.

Hello,

It's my understanding that what is being proposed for shipping is rather
different from what was discussed at TPAC, because the thing we all
agreed on at TPAC ran into some sort of Chrome-internal implementation
constraints.

I know for a fact that Mozilla has not had a chance to review the
proposed changes to the behavior.  Do you plan to wait for such review
and feedback from other browsers before shipping this?

Why was the idea of just fixing Chrome's implementation to do the
agreed-on thing rejected?  Is the relevant discussion public, by any chance?

Hey Boris!

We had a pretty public discussion, and indeed pinged you, in https://github.com/WICG/construct-stylesheets/pull/69 . Anne got a chance to review there, and was really helpful in fixing various issues.

As I explain in the thread, we did add a restriction to the spec partially motivated by the difficulty of implementing multi-document constructible stylesheets in Chrome. But, we think (and from what I recall of TPAC, others thought so too) that this restriction was desirable anyway as a simplification to the model.

We'd be happy to loosen that restriction in the spec, either now---if Mozilla thinks multi-document constructible stylesheets are important to their customers---or later, once we have customer demand for multi-document constructible stylesheets. But, as I mention in the thread, starting simpler seems nicer, so tentatively Rakina merged the PR to add the restriction, with the understanding that we'd be happy to continue discussing with you, Anne, or anyone else from Mozilla who finds multi-document constructible stylesheets essential to their support of the feature.

Starting simpler does indeed seem nicer, especially when there's no clear use-case for the extra complexity. (Boris - please correct me if I'm wrong about the lack of use-case here)

The only thing I'm concerned about here is that ignoring those stylesheets on other documents can lead to a scenario where adding such support in the future is not web compatible.

At the same time, I understand that throwing here would add a lot of complexity. How confident are we that we would or would not want to support the multi-document scenario in the future?

I think if we added multi-document support, we'd make it opt-in, so there shouldn't be a compatibility issue there.

I'll also note that per the latest discussions with Mozilla folks, we may change to disallow multi-document support in a slightly different manner. Comparing the current draft spec/the Chrome implementation (A) and that proposal (B), it is technically possible to write code that behaves differently between A and B. But my opinion is that the delta is largely about edge cases, and is small enough that it would be safe to ship A for a release or two and then switch to B. It also seems likely that we'd be able to get zero releases with A, if folks work toward agreeing on B quickly enough.

So overall, I'm still hopeful this is worthy of API owner approval in its current state :).

[Martin Šrámek‏]

Can you please add the privacy and security considerations section to the spec? The idea seems straightforward, but the discussion of multi-document support caught my attention :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra96iw%3DkGUSDx7noOLoAS84SEJ_jDg%2B-_wuqOiQ1DscrLA%40mail.gmail.com.

[TAMURA, Kent‏]

It sounds the current API with the single-document restriction is stable enough.  LGTM1.

 

 

 

 

 

-Boris

--
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/CAM0wra8Vpx08xJJbCeyR5SqscxE%2BdJ3f0k28v_sYNgC3tOAeww%40mail.gmail.com.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra96iw%3DkGUSDx7noOLoAS84SEJ_jDg%2B-_wuqOiQ1DscrLA%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Rakina Zata Amni‏]

On Sat, Jan 5, 2019 at 6:07 AM Martin Šrámek <msr...@chromium.org> wrote:

Can you please add the privacy and security considerations section to the spec? The idea seems straightforward, but the discussion of multi-document support caught my attention :)

I'm not exactly sure what to write in that section - can you give an example of a spec with a similar section? Also I think I'm not experienced enough in the area to detect potential security threats around stylesheets, loading, etc. so if you or anybody else have any suggestions please do file an issue on the Github repo :)

[Philip Jägenstedt‏]

LGTM2

I see that the discussion in https://github.com/WICG/construct-stylesheets/issues/23 is continuing, but it's clear that multi-document shouldn't be supported and some debate over how to achieve it. I agree with Domenic that having one behavior initially and switching after 0-2 releases is low risk.

https://wpt.fyi/results/css/cssom/CSSStyleSheet-constructable.html?label=experimental shows that the tests are passing behind the flag, and I guess more tests will be needed for the multi-document behavior.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r5aQQyY%2Bj5C03dL7orVBZoGj%3DNzKB12J_g%2BPmgyWUUnQQ%40mail.gmail.com.

[Yoav Weiss‏]

LGTM3 - As it seems that an opt-in approach would be required anyway if we go down the multi-document route.