Otherwise, there's a nasty side effect of being able to exploit a document by treating it as a component.
There's also the opposite scenario of a hostile component.
Please also see http://firstname.lastname@example.org
Did I get this right? https://dvcs.w3.org/hg/webcomponents/rev/27c0e8822ebb
3:42 PM <annevk> dglazkov: so now you cannot have CORS-cross-origin resources so that part of the spec doesn't make sense anymore
3:43 PM <annevk> dglazkov: you also need to say what happens if fetching failed
3:44 PM <annevk> I guess it's mostly fine otherwise, although I wonder if it shouldn't use a crossorigin attribute on <link> like most other things we have
(In reply to comment #4)
> 3:44 PM <annevk> although I wonder if it
> shouldn't use a crossorigin attribute on <link> like most other things we
But then if you don't specify the attribute, you'll just have a No CORS state, right?
The <track> element works like that, yes. No real opinion on what is better, but some consistency throughout would be good.
(In reply to Anne from comment #6)
> The <track> element works like that, yes. No real opinion on what is better,
> but some consistency throughout would be good.
For <track>, it makes sense to load it but not to expose the detail through API. So having @crossorigin (on its parent <media>) makes sense. However for imports, it doesn't make sense to do that: Unlike movie subtitles, API-invisible imports aren't useful at all.
Theoretically we could possibly have @crossorigin for imports so that the author can make requests with credentials. But I don't see any usecase for that.
In contrast, not having @crossdomain makes the usage easier/simpler. If we introduce @crossorigin, people needs to give @crossorigin all the time once they want it CDN-aware, which is sad. I prefer to have better default than to just make the orange consistent to apples.
I'm closing this for now. Feel free to reopen this to continue conversation.