- From: Hans Schmucker <hansschmucker@gmail.com>
- Date: Mon, 16 Mar 2009 14:07:38 +0100
>> So, where would you put it? The problem for me is that there's no >> logical grouping of elements that load offsite resources (like img, >> script, link, video, ...) where one could add the necessary >> attributes. All off them descend directly from HTMLElement. So there >> would be two routes: Either making all elements that load offsite data >> descend from a common HTMLRemotelyFedElement interface (which seems >> like the right way to do things, but it's also IMHO completely >> unrealistic as it would either require reworking the DOM top to bottom >> or including ugly hacks) or adding the necessary attributes to >> HTMLElement itself... which seems like asking for trouble. > > 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. 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. >> 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.
Received on Monday, 16 March 2009 06:07:38 UTC