Define how CSS interacts with spec for the sake of defining how referrers should be handled

[jeisinger]

Esp for resources loaded from stylesheets, and stylesheets loaded from stylesheets.

@mikewest @estark37 @annevk @tabatkins

[annevk]

@bzbarsky if you have a moment I'd appreciate if you could take a look at this. The question is what to do with referrer and stylesheets. I believe we talked about it before and you felt pretty strongly that the referrer being the stylesheet's URL for any subresources of the stylesheet was the way to go (and what Gecko implements). Presumably if a stylesheet references another stylesheet, the subresources of that second stylesheet would use that second stylesheet's URL.

#68 (review) is probably also worthwhile to read as it illustrates some other scenarios.

[bzbarsky]

Talked about this with folks today. The conclusion seems to be to use the stylesheet URI as the referrer and use the sheet's referrer policy (which may be set via headers). Need tests, especially for the "set via headers" thing.

[domenic]

Should we do the same thing for module scripts? I'm particularly talking about import statements; I assume fetch() calls and such use that of their relevant settings object.

[domenic]

Oh, and does the referrerpolicy attribute on the link element impact anything beyond the initial fetch? For module scripts, a few attributes currently carry over (crossorigin and nonce IIRC).

[bzbarsky]

For CSS right now crossorigin does not carry over to anything beyond the initial fetch. I don't think referrerpolicy should either, personally.

[domenic]

I'm certainly willing to change script to align with that for crossorigin and not carry over beyond the initial fetch.

And I guess also change scripts so that they can get a referrer policy from the header.

But what about nonce? @mikewest pretty explicitly made that carry over into script imports. Is nonce different? Should it apply to stylesheet imports?

[jeisinger]

I don't think anybody is proposing to put an referrer policy attribute on here.

For the other attributes, I'd propose to move the discussion over to the respective specs.

[domenic]

link already has a referrerpolicy attribute.

I'm hoping we can at some point hash out a consistent story for all the fetch-options attributes.

[annevk]

I think for module scripts copying crossorigin is needed. Otherwise you get opague module scripts.

[domenic]

No, you just fail the request :)

[jeisinger]

ah. the original idea was to have it only for link rel=prefetch as that navigates.

[jeisinger]

In any case, as I said above, I think we should not take over the referrer policy in these cases.

[annevk]

@domenic that means cross-origin module scripts are nearly impossible to use. Since the origin is that of the document so any nested module scripts have to be same-origin with that origin.

[domenic]

(Sorry for sidetracking everyone.)

@annevk why? crossorigin only affects the credentials mode. Requests for module scripts are made with CORS.

[annevk]

@domenic I see, that still seems rather confusing and could lead to failure depending where on the stack you import it from (as the credentials mode wouldn't necessarily be consistent if you always declared it as use-credentials on the element), but always using CORS indeed doesn't lead to some other problems.