- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Wed, 10 Feb 2016 14:29:39 -0500
- To: whatwg@lists.whatwg.org
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
Received on Wednesday, 10 February 2016 19:30:16 UTC