On Mon, 16 Mar 2009 14:07:38 +0100, Hans Schmucker
<[email protected]> 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.
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.
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 :-)
--
Anne van Kesteren
http://annevankesteren.nl/
