Intent to Ship: Constructable Stylesheet Objects

707 weergaven
Naar het eerste ongelezen bericht

Rakina Zata Amni

ongelezen,
13 dec 2018, 04:28:1513-12-2018
aan blink-dev, dom...@chromium.org, taba...@chromium.org

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

ongelezen,
13 dec 2018, 06:10:1813-12-2018
aan Rakina Zata Amni, blink-dev, dom...@chromium.org, taba...@chromium.org
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

ongelezen,
13 dec 2018, 07:55:5313-12-2018
aan Boris Zbarsky, rak...@chromium.org, blin...@chromium.org, Domenic Denicola, taba...@chromium.org
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

ongelezen,
13 dec 2018, 11:07:2013-12-2018
aan Domenic Denicola, rak...@chromium.org, blin...@chromium.org, taba...@chromium.org
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

ongelezen,
18 dec 2018, 12:31:0518-12-2018
aan Boris Zbarsky, Domenic Denicola, Rakina Zata Amni, blink-dev, Tab Atkins
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

ongelezen,
19 dec 2018, 20:59:4919-12-2018
aan bratell, Domenic Denicola, Rakina Zata Amni, blink-dev, Tab Atkins
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

ongelezen,
2 jan 2019, 10:32:1702-01-2019
aan Domenic Denicola, Boris Zbarsky, Rakina Zata Amni, blin...@chromium.org, Tab Atkins
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.

Domenic Denicola

ongelezen,
2 jan 2019, 11:33:3302-01-2019
aan Yoav Weiss, Domenic Denicola, Boris Zbarsky, Rakina Zata Amni, blin...@chromium.org, Tab Atkins
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

ongelezen,
4 jan 2019, 16:07:2604-01-2019
aan Domenic Denicola, Yoav Weiss, Boris Zbarsky, Rakina Zata Amni, blink-dev, Tab Atkins
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 :)

TAMURA, Kent

ongelezen,
6 jan 2019, 23:44:0706-01-2019
aan Domenic Denicola, Yoav Weiss, Boris Zbarsky, Rakina Zata Amni, blink-dev, Tab Atkins
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.

Rakina Zata Amni

ongelezen,
7 jan 2019, 00:04:0907-01-2019
aan Martin Šrámek, Domenic Denicola, Yoav Weiss, Boris Zbarsky, blink-dev, Tab Atkins
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

ongelezen,
8 jan 2019, 08:52:2608-01-2019
aan Rakina Zata Amni, Martin Šrámek, Domenic Denicola, Yoav Weiss, Boris Zbarsky, blink-dev, Tab Atkins
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.

Yoav Weiss

ongelezen,
8 jan 2019, 09:32:5208-01-2019
aan Philip Jägenstedt, Rakina Zata Amni, Martin Šrámek, Domenic Denicola, Boris Zbarsky, blink-dev, Tab Atkins
LGTM3 - As it seems that an opt-in approach would be required anyway if we go down the multi-document route.
Allen beantwoorden
Auteur beantwoorden
Doorsturen
0 nieuwe berichten