Repository navigation
[css-cascade] Unclear which origins to compare for @import in quirks mode #4838
Description
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.)
Activity
annevk commentedon Mar 6, 2020
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 commentedon Mar 6, 2020
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 commentedon Jan 13, 2021
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 commentedon Jan 13, 2021
Leaving open because this can reasonably be backported to Cascade 3, that just needs to exercise the new Rec-amendment process. @fantasai
annevk commentedon Jan 14, 2021
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 commentedon Jan 15, 2021
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 commentedon Jan 18, 2021
Opaqueness is a quality of the response: https://fetch.spec.whatwg.org/#concept-response-type. Basically, you want HTML's CORS-same-origin.
tabatkins commentedon Jan 20, 2021
Hm, okay. Does that require us to write the
@importrequest more explicitly on top of Fetch, to get an unambiguous Response result?annevk commentedon Jan 21, 2021
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.
[css-cascade-4] wip first version of fetching steps for @import #4838
tabatkins commentedon Sep 3, 2021
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 commentedon Sep 9, 2021
Gathering some chat feedback so it doesn't get lost:
(from Andreu Botella):
(from Anne):
tabatkins commentedon Sep 17, 2021
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 commentedon Sep 17, 2021
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 commentedon Sep 17, 2021
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.