Need to define what fetch groups various loads from the sheet go in

[bzbarsky]

This applies to @import, backgrounds, fonts, etc.

This is a bit more complicated than the <link> case, because in that case there is only one plausible fetch group: the one for the document. With constructible sheets, there are at least two fetch groups involved: the one for the window the constructor came from (esp. for sheets not attached to anything) and the one for wherever the sheet is actually being used.

I guess a sheet can in fact be used in multiple places, so there could be any number of fetch groups involved....

As a concrete question, if I create a sheet from documen A's window, and am using it in documents B and C, and B matches a rule with one background image while C matches a rule with another, which load events, if any, are blocked by the resulting image loads.

[TakayoshiKochi]

What if we constrain the usage of the constructed stylesheet which is created in document A, it shall only be used within document A? (related issue: #10 and #23)

I don't think this restriction will mess up any (useful) use cases, and just in case if you really need to use the same stylesheet to another document, we can come up with document.adoptStyleSheet().

[TakayoshiKochi]

As #23 concludes a stylesheet can be only used for one document, closing this.

If the conclusion was reverted, I'll reopen this.

[bzbarsky]

@TakayoshiKochi Even if you can only use them in one document, there are open questions in this issue because that document might not match the window the constructor came from. Please actually address those questions.

Unfortunately it looks like I cannot reopen this issue...

[TakayoshiKochi]

@bzbarsky could you elaborate how can we create the situation to make your script run in a document which is different from the current global? (sorry for my ignorance...)

[bzbarsky]

Maybe I misunderstood what the proposal was? If I do this:

<iframe></iframe>
<script> var sheet = new frames[0].CSSStyleSheet(text);</script>

Can I use sheet in document? Or so I have to use it in frames[0].document? In the latter case, there is no ambiguity, apart from the fact that the document in that Window can change...

[rakina]

@bzbarsky it should only be usable in frames[0].document I think, and if the document changes it's not usable on the changed document.

[bzbarsky]

In that case, if the sheet is actually tied to a Document not a Window, why is it not created via a factory method on that Document?

[TakayoshiKochi]

@bzbarsky I share the same question... in terms of the CSSOM spec CSSStyleSheet doesn't have the notion of ownerDocument, but has .ownerNode, and even when its inner slot location is null (e.g. for <style>) url() in the sheet is actually resolved against the document's base URL.

So for the constructor, it has an indirect association with its global (window)'s document, but it would be clearer if Document has another (other than one returns a Promise) factory method to return a CSSStyleSheet object. (this may sound contradict my own #2 (comment), but...)

@tabatkins do we still want a CSSStyleSheet() constructor independent of document?

[annevk]

How does ownerNode work when the style sheet is reused across shadow roots?

[rakina]

How does ownerNode work when the style sheet is reused across shadow roots?

Constructed stylesheets' ownerNode is null. Can you elaborate on what might be the problem you mentioned on the other thread?

[annevk]

Sorry, I didn't mean to imply there was a problem, just that you have to do something. Always returning null might be viable. Perhaps ownerNode was just a badly designed API that should not have been there.

[tabatkins]

ownerNode isn't necessarily bad, but it's an element-ish API, making the assumption that a stylesheet lives in one and only one place in a document. This wasn't an unreasonable assumption before, as duplicating a stylesheet was worthless.

So yeah, just having it be always null for constructed sheets is the way to go.

[yutakahirano]

@hiroshige-g Hi Hiroshige, I think the situation is similar to the case where a stylesheet is shared by multiple documents via MemoryCache. Do you know what we are doing in Blink right now? Do you have any suggestion what should be specced here?

[hiroshige-g]

Yeah, the same question applies to a stylesheet loaded from network and shared via MemoryCache across multiple Documents.
Currently, Blink loads background images etc. in stylesheets using ResourceLoader that belongs to the Document that needed the background image for the first time.

For example:
Q. if a stylesheet is loaded from network from document A, shared with documents B and C via MemoryCache, and B matches a rule with one background image R while C matches a rule with another background image S, which load events, if any, are blocked by the resulting image loads?
A. R blocks B's load event, S blocks C's load event.

[hiroshige-g]

Clarification: the "load event" discussed here is Document/Window's load events, right?

In the first place, I don't think the delay-the-Document-load-event behavior for background images are specced or interoperable.

• @domenic is proposing to define "critical subresources" of CSS as @imported things which don't include background-images in Improve clarity in link and style sheet resource fetching whatwg/html#3544.
• According to Define which subresources block the DOM load event w3c/csswg-drafts#1088 (comment) Edge doesn't delay the Document load event for background images.

[hiroshige-g]

Anyway, I agree with @TakayoshiKochi's comment:
#15 (comment)

In general, I think enforcing same-Document relationship is good for code health and security.

[bzbarsky]

Per discussion today, static @import can use the fetch group of the document the sheet is being created for, we can disallow dynamic @import (see #56), and for other loads we may want to do separate fetches per document (esp. because for fonts the Origin headers might need to be different if document.domain is used). Gecko apparently already does this last for user and UA stylesheets, which are shared across documents.

[tabatkins]

Oooh, good final point.

So that suggests we should be fine to share a stylesheet across documents? That makes some things much simpler.

(Is it already specified how adopting a shadow host into another document re-resolves any url()s in its stylesheets?)

[bzbarsky]

So that suggests we should be fine to share a stylesheet across documents?

That's what @rakina and @domenic and @emilio and I were discussing during break. The conclusion so far was that it might be feasible. There's some double-checking to be done.

Is it already specified how adopting a shadow host into another document re-resolves any url()s in its stylesheets?

If we're talking about sheets that come from the shadow DOM, for sheets loaded via <link> there would be nothing to re-resolve. For sheets loaded via <style>, I'm not sure what happens.

One thing we could do for constructible stylesheets is to just capture a base URL at construction time and not do any re-resolving on adopt.

[tabatkins]

One thing we could do for constructible stylesheets is to just capture a base URL at construction time and not do any re-resolving on adopt.

While I'm sad that this doesn't match the behavior of other stylesheets with relative urls, I am happy that this is way simpler.

[bzbarsky]

While I'm sad that this doesn't match the behavior of other stylesheets with relative urls

Does it not? I'm not aware of other cases where re-resoving happens, offhand, but it's been a while since I looked at the relevant bits.

Definitely in Gecko a base URL is captured by a CSSStyleSheet at the point when it's created.