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