[css-cascade] Unclear which origins to compare for @import in quirks mode

[zcorpan]

Spec https://drafts.csswg.org/css-cascade/#content-type

The processing of imported style sheets depends on the actual type of the linked resource. If the resource does not have Content-Type metadata, or the host document is in quirks mode and has the same origin as the imported style sheet, the type of the linked resource is text/css. Otherwise, the type is determined from its Content-Type metadata.

If the linked resource’s type is text/css, it must be interpreted as a CSS style sheet. Otherwise, it must be interpreted as a network error.

The HTML spec says for <link rel=stylesheet>:

Quirk: If the document has been set to quirks mode, has the same origin as the URL of the external resource, and the Content-Type metadata of the external resource is not a supported style sheet type, the user agent must instead assume it to be text/css.

https://html.spec.whatwg.org/multipage/links.html#link-type-stylesheet

I said the following on Twitter https://twitter.com/zcorpan/status/1235724741224226816

Does something say that stylesheets can have an origin? HTML doesn't. https://html.spec.whatwg.org/multipage/origin.html#concept-origin

Which origins should be compared? The imported URL's origin with the host document's origin? The imported URL's origin with the current stylesheet's URL's? (Before or after redirects?)

Reading the @import spec again I think it's clear that it's comparing the host document's origin. But the other origin is less clear, since the origin of "the imported style sheet" is not defined, as far as I know.

(The question about before or after redirects might also apply to HTML.)

cc @tabatkins @annevk

[annevk]

The document's origin and the response's URL's origin. (Letting the document have access to cross-origin resources that are not style sheets as style sheets is bad.)

[zcorpan]

Why the document's URL's origin, rather than the document's origin? This is different for e.g. about:blank document, that shares origin with its embedder document.

[tabatkins]

All right cool, spec is updated to explicitly compare host document's origin with the resource's responses's URL's origin. Thanks for helping figure this out!

[tabatkins]

Leaving open because this can reasonably be backported to Cascade 3, that just needs to exercise the new Rec-amendment process. @fantasai

[annevk]

FWIW, I suspect we don't want to compare with the document's origin, but we actually want to use whether the response is opaque or not. As the document's origin can change over time, but we don't want this determination to change over time.

[tabatkins]

Hm, reading over the definitions, I think you mean that, if this origin comparison fails when the response is retrieved, we treat the response as having a unique opaque origin, then only treat it as text/css if the response is not opaque? (As far as I can tell, opaqueness isn't an inherent quality of network-based origins, right?)

[annevk]

Opaqueness is a quality of the response: https://fetch.spec.whatwg.org/#concept-response-type. Basically, you want HTML's CORS-same-origin.

[tabatkins]

Hm, okay. Does that require us to write the @import request more explicitly on top of Fetch, to get an unambiguous Response result?

[annevk]

Yeah, I think that needs to happen anyway as otherwise it's unclear whether or not (and how) it enforces all the various fetch policies.

[tabatkins]

Okay, first draft of defining @import on top of Fetch committed; you can check the commit (above) or the spec in a few minutes at https://drafts.csswg.org/css-cascade-4/#fetch-an-import.

This was a slog to even get to this point, because afaict there's no documentation of what this sort of thing is supposed to look like; I mostly just started from https://html.spec.whatwg.org/multipage/semantics.html#default-fetch-and-process-the-linked-resource and modified what looked like it needed modifying.

Is this the right place to start from, @annevk? If not, any pointers to existing examples I should be copying from?

[tabatkins]

Gathering some chat feedback so it doesn't get lost:

(from Andreu Botella):

So I'm not an expert on fetch by any means, but there's a few things that stand out to me

• If the original stylesheet was linked to with <link crossorigin>, you'd presumably want imports to use mode "cors" and credentials mode "same-origin", right?
• Unless you explicitly set the request's synchronous mode, fetch will not block, so you don't want to run it in parallel. Instead of that, you should set one or more of the optional algorithms that are passed to fetch: "processResponse" if you just need a response, or "processResponseEndOfBody" which will give you a response and a byte sequence. Those algorithms will be run in tasks on the networking task source, with the event loop that corresponds to request's client.
• And request's client should be a Window's environment settings object, I believe

(from Anne):

Request's client is an environment settings object and used for defaulting of certain things. For CSS this would typically be the one associated with the document ultimately responsible for the request. Now CSS is complex and does some things differently so you might need to set certain things yourself, such as the referrer field. Also, you no longer have to go in parallel or queue a task, you can pass your callbacks to fetch and it'll do all that for you.

[tabatkins]

Okay, trying to rewrite my first attempt to instead pass algos to Fetch. I'll note, tho, that the algo I copied from is in HTML; we should probably get that using Fetch properly so it can serve as an example. @annevk

[tabatkins]

Actually, I'm still not sure what I should be doing. @annevk, do we have any examples of using the current Fetch spec at all? https://html.spec.whatwg.org/multipage/semantics.html#default-fetch-and-process-the-linked-resource is doing "Let |resource| be the result of fetching...", which CSSOM is also using in https://drafts.csswg.org/cssom/#fetching-css-style-sheets, but as far as I can tell, the fetch algo that both link to simply never returns anything at all.

[domenic]

https://fetch.spec.whatwg.org/#dom-global-fetch is probably a good example. Indeed, HTML needs to get updated for the recent changes to Fetch.