Intent to Implement: constructable stylesheet objects

[Takayoshi Kochi‏]

Contact emails

ko...@chromium.org, rak...@chromium.org (Blink)

jacka...@gmail.com (spec)

Explainer

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

Spec

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

We started a public review/discussion of the spec at

https://discourse.wicg.io/t/proposal-constructable-stylesheet-objects/2572

The idea in general has already got consensus at W3C TPAC meetings

in the past.

In TPAC2016 meeting notes:
https://www.w3.org/2016/09/19-webapps-minutes.html
around the following conversation (about discussing the issue #468):
> rniwa: In that API, how you going to get the style sheet?
> bz: There's been talk is CSSWG about interface to get style sheet. It's reasonable for the platform anyway
> esprehn: Tab is already speccing a constructable style sheet thing anyway

In TPAC2017 meeting notes:
https://www.w3.org/2017/11/10-webplat-minutes.html#item04
> ryosyke: we think the general concept is great, I have specific naming complaints ...

Summary

The CSSStyleSheet object can be constructed from scripts. It used to be only

constructed via <style> or <link rel="stylesheet"> in HTML. The spec also gives

a way to make the constructed CSSStyleSheet to be applied to a document or

a shadow tree.

Motivation

With this enabled, you can pass constructed a CSSStyleSheet object to a shadow

root instance, which can save initialization cost and potentially duplicate memory

usage in cases that a single document uses a lot of the same component which uses

Shadow DOM and sharing the same style.

It also paves a way to pass it to custom element constructor (w3c/webcomponents#468)

so a custom element can have a custom UA-stylesheet or alike.

Risks

Interoperability and Compatibility

Medium, the spec is still in draft and may change, so we will start implementing this

under the experimental flag to give feedback on the spec first. We also plan to

contribute WPTs in parallel with the spec.

Edge: ?

Firefox: Not opposed

Safari: Not opposed

Web developers: ?

(above is based on the responses in the TPAC meeting minutes as far as I read)

Debuggability

Probably need a new UI element or something to identify where the matching style rule

is coming from in devtools.

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?

As the spec is still under development, we don't start contributing tests immediately, but

we have plan to move layout tests to WPTs once the spec gets in better shape or consensus.

Link to entry on the feature dashboard

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

Requesting approval to ship?

No

--

Takayoshi Kochi

[Boris Zbarsky‏]

On 2/5/18 4:04 AM, Takayoshi Kochi wrote:
> Firefox: Not opposed

To be clear, we're not opposed to the general idea, but the details
really matter here. Doubly so because stylesheet creation via <link> is
both underspecified in HTML/CSS And not interoperable across UAs today.
To the extent that UAs reuse their existing infrastructure for the new
API, it would be very easy for it to also not be interoperable.

Some specific things to keep in mind that are either not covered by the
spec draft so far or are covered but the answer picked by the spec draft
is not obvious to me:

1) Should it be possible to construct a CSSStyleSheet from a url, or the
actual sheet content, or both?

2) What is the URL of the resulting sheet? This matters for base URL
resolution inside the sheet, and various DOM accessors.

3) What is the origin of the resulting sheet?

4) What is the behavior for .cssRules accesses before the sheet is "done
loading". This can happen for the "parse drom text" case as well, due
to @import rules.

5) The spec draft introduces a new situation that can't exist right now:
sheets sharing MediaList instances. Note that MediaList is mutable.
Should these get cloned instead of getting shared?

6) Should handling of non-text/css responses (for either the sheet
itself if loading from URL is allowed, or @import in all cases) have the
quirky behavior <link> has?

That's off the top of my head; I'm sure more questions can come up
during an actual implementation.

-Boris

P.S. I would have filed the issues on the spec directly, but don't see
a way to do that. Certainly not one linked from the spec draft.

[Takayoshi Kochi‏]

Hi, thanks for the detailed feedback!

I'll file issues at https://github.com/WICG/construct-stylesheets/issues later, but feel free to add there, and I'll link it from the spec draft.

On Mon, Feb 5, 2018 at 11:49 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 2/5/18 4:04 AM, Takayoshi Kochi wrote:

Firefox: Not opposed

To be clear, we're not opposed to the general idea, but the details really matter here.  Doubly so because stylesheet creation via <link> is both underspecified in HTML/CSS And not interoperable across UAs today. To the extent that UAs reuse their existing infrastructure for the new API, it would be very easy for it to also not be interoperable.

Some specific things to keep in mind that are either not covered by the spec draft so far or are covered but the answer picked by the spec draft is not obvious to me:

1) Should it be possible to construct a CSSStyleSheet from a url, or the actual sheet content, or both?

At this moment from string only.  Can construct from URL be achieved with fetch API and this?

2) What is the URL of the resulting sheet?  This matters for base URL resolution inside the sheet, and various DOM accessors.

Will file an issue.

 

3) What is the origin of the resulting sheet?

Some argument is already there in the spec (ISSUE 6).

> One possible solution here is to add another origin, the "author default" origin, which sits between "user" and "author", and applies in all shadow roots automatically. 

> ...

We think we first implement it as a "author" origin, when it's added via ".moreStyleSheets".

But this still needs investigation.

4) What is the behavior for .cssRules accesses before the sheet is "done loading".  This can happen for the "parse drom text" case as well, due to @import rules.

Will file an issue.

 

5) The spec draft introduces a new situation that can't exist right now: sheets sharing MediaList instances.  Note that MediaList is mutable. Should these get cloned instead of getting shared?

Good catch, will file an issue.

 

6) Should handling of non-text/css responses (for either the sheet itself if loading from URL is allowed, or @import in all cases) have the quirky behavior <link> has?

To be honest I'm not familiar with the <link>'s underspecified / non interoperable behaviors.

I'd appreciate if you can give any pointers.

Even assuming the top-level style sheet is loaded from string or fetch(), @import sounds causing an issue

if the returning MIME type is different from text/css.  I don't think we should depend on the <link> behavior

and clarify as much as possible, while <link>'s issue could be addressed independently.

 

That's off the top of my head; I'm sure more questions can come up during an actual implementation.

-Boris

P.S.  I would have filed the issues on the spec directly, but don't see a way to do that.  Certainly not one linked from the spec draft.

--
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/e21086b6-bbd4-93e6-e72f-43c9aea1064d%40mit.edu.

--

Takayoshi Kochi

[Boris Zbarsky‏]

On 2/5/18 11:09 PM, Takayoshi Kochi wrote:
> I'll file issues at https://github.com/WICG/construct-stylesheets/issues
> later, but feel free to add there, and I'll link it from the spec draft.

I'll file there, thank you.

> At this moment from string only.  Can construct from URL be achieved
> with fetch API and this?

Yes, if you restrict to things that are same-origin or fetched via CORS.
No if you need to fetch non-CORS-enabled cross-origin things.

> 3) What is the origin of the resulting sheet?
>
>
> Some argument is already there in the spec (ISSUE 6).
> > One possible solution here is to add another origin, the "author
> default" origin, which sits between "user" and "author", and applies in
> all shadow roots automatically.

Sorry, different sort of origin. I mean security origin, not cascade
level. In practice, you need to define whether
https://drafts.csswg.org/cssom/#concept-css-style-sheet-origin-clean-flag
is set.

> 6) Should handling of non-text/css responses (for either the sheet
> itself if loading from URL is allowed, or @import in all cases) have
> the quirky behavior <link> has?
>
> To be honest I'm not familiar with the <link>'s underspecified / non
> interoperable behaviors.
> I'd appreciate if you can give any pointers.

I'll put it in an issue, but this behavior _is_ specified and
interoperable: cross-site loads (or same-site on non-quirks pages) that
are not text/css don't get handled as stylesheets.

The issues around <link> are things like whether you can access the
sheet or its rules before it's done loading.

-Boris

[Takayoshi Kochi‏]

On Tue, Feb 6, 2018 at 2:24 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 2/5/18 11:09 PM, Takayoshi Kochi wrote:

I'll file issues at https://github.com/WICG/construct-stylesheets/issues later, but feel free to add there, and I'll link it from the spec draft.

I'll file there, thank you.

Cool, thank you!

 

At this moment from string only.  Can construct from URL be achieved with fetch API and this?

Yes, if you restrict to things that are same-origin or fetched via CORS.  No if you need to fetch non-CORS-enabled cross-origin things.

    3) What is the origin of the resulting sheet?


Some argument is already there in the spec (ISSUE 6).
 > One possible solution here is to add another origin, the "author default" origin, which sits between "user" and "author", and applies in all shadow roots automatically.

Sorry, different sort of origin.  I mean security origin, not cascade level.  In practice, you need to define whether https://drafts.csswg.org/cssom/#concept-css-style-sheet-origin-clean-flag is set.

    6) Should handling of non-text/css responses (for either the sheet
    itself if loading from URL is allowed, or @import in all cases) have
    the quirky behavior <link> has?

To be honest I'm not familiar with the <link>'s underspecified / non interoperable behaviors.
I'd appreciate if you can give any pointers.

I'll put it in an issue, but this behavior _is_ specified and interoperable: cross-site loads (or same-site on non-quirks pages) that are not text/css don't get handled as stylesheets.

The issues around <link> are things like whether you can access the sheet or its rules before it's done loading.

-Boris

--

Takayoshi Kochi