- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 16 Mar 2009 13:27:20 +0100
On Sun, 15 Mar 2009 22:09:16 +0100, Hans Schmucker <hansschmucker at gmail.com> wrote: > Sorry, I didn't mean to make it sound like an attack, I really just > meant to say that this (for me) belongs more into HTML5, which deals > primarily with the user agent, than into the CORS spec, which more or > less focuses on the server side and the communication between server > and client. I don't think anyone is disagreeing with that. > 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? > 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.) -- Anne van Kesteren http://annevankesteren.nl/
Received on Monday, 16 March 2009 05:27:20 UTC