- From: Hans Schmucker <hansschmucker@gmail.com>
- Date: Mon, 16 Mar 2009 14:58:02 +0100
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