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.)

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.

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!

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

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.

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?)

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

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

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.

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?

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.

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

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.

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.