[whatwg] Canvas origin-clean should not ignore Access Control for Cross-Site Requests

On Mon, Mar 16, 2009 at 2:43 PM, Anne van Kesteren <annevk at opera.com> wrote:
> On Mon, 16 Mar 2009 14:07:38 +0100, Hans Schmucker <hansschmucker at gmail.com>
> wrote:
>>>
>>> Why does the DOM need to get involved here?
>>
>> Well it should be involved, although I don't think we can actually do
>> it. I think the CORS header response should be stored and be available
>> the same way across all DOM elements that can load data. If that would
>> be provided by a special interface from which all elements that load
>> data descend, it would not only make the whole thing cleaner in the
>> spec, but also in the implementations.
>
> If the specifics are not exposed to authors the DOM does not need to get
> involved.

Correct. I'm not a browser maker, so my perspective is probably a bit
different than yours. I just write JS. The problem for me is that if
such data is not available, I would be forced to basically do a lot of
try/catch or other form of error catching just to find out what
exactly I can do when I could just look it up in the elements
attributes.

>> Instead of an UA supporting
>> first XHR, then image, then video, then XY, the status of the
>> implementation would be identical in all parts of the UA. Basically,
>> it would force implementations to create the CORS dom support with a
>> common codebase for all elements that use it, instead of having
>> duplicate code which might behave differently.
>
> I don't think we should be in the business of enforcing how implementations
> implement things. We can certainly encourage things by re-using algorithms,
> indicating things are identical, etc., but if there is no author-observable
> difference we cannot test it.

Well, a bit. We do that all the time when we specify inheritance. At
least we encourage it and plant the idea that this really should be in
a common spot.

>>>> Then there's the (IMHO) despicable way of just writing a random
>>>> chapter about it and referencing that chapter in the spec wherever
>>>> appropriate. Feels very, very wrong, but I don't think we have much
>>>> choice here.
>>>
>>> I don't see how this is wrong. Since the exact semantics of a
>>> cross-origin request vary per API anyway grouping the common things
>>> somewhere makes sense to me. (E.g. EventSource would completely fail in case
>>> the resource sharing check fails where as an image would still be
>>> displayed.)
>>
>> Reading this again the next morning I really should have worded that
>> differently. Sorry about that. But I'm really afraid JS developers, in
>> addition to catching different behaviours in different UAs would also
>> have to deal with different behaviour inside the same UA. Yes, the
>> actual use would be different across different cases, but at least the
>> raw data would be readable the same way and the parts that implement
>> the different uses would have a standardized to where to get their
>> data from.
>
> Consistency is enforced by tests and proper specifications. Currently HTML5
> has not integrated support for CORS (yet) so it seems a bit early to
> complain :-)

Better now than when the damage is done, right?

Received on Monday, 16 March 2009 06:58:02 UTC