On 2/10/16 1:25 PM, Domenic Denicola wrote:
In new JavaScript-only APIs we've made the decision to move away from the 
potentially-confusing HTML style crossOrigin enums in favor of the RequestCredentials 
enum used by Fetch: https://fetch.spec.whatwg.org/#requestcredentials. You can see this 
in e.g. https://github.com/whatwg/html/pull/608 where I chose the same initial 
crossOrigin design and Anne convinced me to move to credentials. I imagine we'll continue 
to use crossorigin="" and corresponding reflected crossOrigin IDL attributes 
for any HTML elements, but for JS-only APIs RequestCredentials is the way to go.

That's not _quite_ the same thing. The HTML setup basically lets you specify one of:

1)  No CORS (attr not set).
2)  CORS, RequestCredentials == "include" (crossrigin="use-credentials")
3)  CORS, RequestCredentials == "same-origin" (any other attr value)

Note that in the pull request you reference your default was not actually any of those situations, as far as I can tell, so I agree that using "crossOrigin" there was not a good fit. But for the ImageBitmap case, we do want to support case 1 above, at least assuming tainted ImageBitmap is a thing. If it's not, then I agree that just a RequestCredentials value is probably sufficient and all the loads involved should use CORS.

That said, the actual phrasing around "crossOrigin" in
https://wiki.whatwg.org/wiki/ImageBitmap_Options doesn't make much sense (e.g. it in fact is not a "CORS settings attribute" because it's not a markup attribute at all). But we can wordsmith it better once we agree on what we actually want it to do.

-Boris

Reply via email to