Re: [whatwg] Fullscreen
On Mon, 03 Oct 2011 18:52:24 +0200, Tantek Çelik tan...@cs.stanford.edu wrote: Fullscreen is currently #2 in my queue after getting another LCWD of CSS3-UI out. Cool! I've been incrementally editing on the wiki page you mentioned until it's my primary focus. Feel free to make edits to the wiki if there are particular aspects you want to improve or raise as issues. Thanks, will do. Either way, though I sympathize with the desire to get rid of prefixes, there are other aspects (besides spec (re)formatting/massaging from wiki to W3C WD) that need more help if prefix-removal is your primary goal, e.g. we don't have a Fullscreen test suite nor even someone to curate/coordinate the creation of one - is that something you'd be available to help with? I'm (and Opera is too) primarily interested in getting a somewhat more formal specification. I'm willing to help out with writing tests, but I have no ideas on how to test this in an automated way (apart from simple IDL tests). -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] document.all quickiness
Hi ! The spec for HTMLAllCollection [1] says The HTMLAllCollection interface represents a generic collection of elements. After some quick testing in IE [2], IE returns the doctype, processing instructions and comment nodes too. If converts them all to comments but that's something else we shouldn't even touch with a long stick. I would suggest that the spec be updated to match IE better. Thank you. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#htmlallcollection-0 [2] http://dl.dropbox.com/u/9681493/procinsts.html
[whatwg] [CORS] WebKit tainting image instead of throwing error
If the CORS-check did not succeed on img src=http://crossorigin.example.net crossorigin, this should happen according to spec: Discard all fetched data and prevent any tasks from the fetch algorithm from being queued. For the purposes of the calling algorithm, the user agent must act as if there was a fatal network error and no resource was obtained. If a CORS resource sharing check failed, the user agent may report a cross-origin resource access failure to the user (e.g. in a debugging console). http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#potentially-cors-enabled-fetch In this scenario an author wanting to do some canvas processing with the image, will be able to check img.onerror to see whether she can use that image. The image won't load on a failed check. Gecko does this. WebKit, on the other hand, only taints the image and loads it anyway, breaking the spec. The error will instead crop up in a way that is more verbose and harder to miss when she tries to read the image data out. Is WebKit's method a lesser surprise than the image just not showing up (if they don't check for thrown error)? It'd be nice to hear why it's implemented like that, if there are any good reasons. WebKit's method seemed most obvious to me at first, but after investigating a bit I'm not sure anymore... -- Odin Hørthe Omdal Core QA, Opera Software
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On Tue, 4 Oct 2011, Odin Hørthe Omdal wrote: If the CORS-check did not succeed on img src=http://crossorigin.example.net crossorigin, this should happen according to spec: Discard all fetched data and prevent any tasks from the fetch algorithm from being queued. For the purposes of the calling algorithm, the user agent must act as if there was a fatal network error and no resource was obtained. If a CORS resource sharing check failed, the user agent may report a cross-origin resource access failure to the user (e.g. in a debugging console). http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#potentially-cors-enabled-fetch In this scenario an author wanting to do some canvas processing with the image, will be able to check img.onerror to see whether she can use that image. The image won't load on a failed check. Gecko does this. WebKit, on the other hand, only taints the image and loads it anyway, breaking the spec. The error will instead crop up in a way that is more verbose and harder to miss when she tries to read the image data out. Is WebKit's method a lesser surprise than the image just not showing up (if they don't check for thrown error)? It'd be nice to hear why it's implemented like that, if there are any good reasons. WebKit's method seemed most obvious to me at first, but after investigating a bit I'm not sure anymore... The idea is that if the server explicitly rejected the CORS request, then the image should not be usable at all. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] document.all quirkiness
On Tue, 04 Oct 2011 19:58:56 +0200, João Eiras jo...@opera.com wrote: Hi ! The spec for HTMLAllCollection [1] says The HTMLAllCollection interface represents a generic collection of elements. After some quick testing in IE [2], IE returns the doctype, processing instructions and comment nodes too. If converts them all to comments but that's something else we shouldn't even touch with a long stick. I would suggest that the spec be updated to match IE better. After further testing (and getting someone to test in IE9), IE9 only returns Elements, even in quirks mode, so I presume the change is not needed. Thanks.
[whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
Hi everyone, following WebKit's attempt at implementing the behavior of |sheet| and |disabled| per HTML5 / CSSOM [1], we have found that the specs [2] [3] either under-specify the behavior or do not match what browsers are doing. Here are the behaviors seen during testing: * IE9 does not support link.sheet. * Opera and FF always have an associated stylesheet if |link.rel| matches a stylesheet and |href| is set. * They both fill link.sheet with default values even if the stylesheet was / ends up in error. * However, FF loads the stylesheet synchronously whereas Opera does it asynchronously from a JS perspective * Some websites (4chan.org for examples) assumes that the |sheet| is always available and that |disabled| will work properly regardless of when it is called. We ended up reverting our changes due to incompatibilities seen in the wild and seek the spec amended before resuming our implementation in a compatible manner. Thanks, Julien [1] https://bugs.webkit.org/show_bug.cgi?id=65140 (see in particular comments #26 [our reading of the spec] and #29 [some findings summed up here for easier reading]) [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#dom-link-disabled [3] http://dev.w3.org/csswg/cssom/#the-linkstyle-interface
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On Tue, 04 Oct 2011 20:32:02 +0200, Ian Hickson i...@hixie.ch wrote: The idea is that if the server explicitly rejected the CORS request, then the image should not be usable at all. FWIW, from a CORS-perspective both scenarios are fine. CORS only cares about whether data gets shared in the end. One advantage I can see about img crossorigin still displaying the image is that the request does not use cookies. Not displaying the image probably makes debugging easier however. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On 10/4/11 2:32 PM, Odin Hørthe Omdal wrote: WebKit, on the other hand, only taints the image and loads it anyway, breaking the spec. File a bug on them please? The idea of CORS is that CORS-using requests stop making the harmful distinction between ability to embed and ability to read. That's why CORS had to be opt-in for images. If WebKit is not implenenting this properly, they just need to fix their code... And in particular an img crossorigin that's in the DOM and fails the CORS checks should not render the image on the page. Anything else is just broken. -Boris
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On 10/4/11 2:41 PM, Julien Chaffraix wrote: * However, FF loads the stylesheet synchronously whereas Opera does it asynchronously from a JS perspective Uh... Firefox does not load anything synchronously. What Firefox does do is block execution of script tags (but not timeouts, callbacks, etc!) if there are pending non-altenate parser-inserted stylesheet loads. This is necessary to make sure that scripts getting layout properties see the effect of those stylesheets. A side-effect is that a script coming after a link will never see the link in an unloaded state... unless there's a network error for the link or whatever. * Some websites (4chan.org for examples) assumes that the |sheet| is always available and that |disabled| will work properly regardless of when it is called. OK. That behavior is allowed by the spec as far as I can tell. We ended up reverting our changes due to incompatibilities seen in the wild and seek the spec amended before resuming our implementation in a compatible manner. What specific changes do you want to the spec? As far as I can tell, right now the spec says nothing about when sheets become associated and that this would need to be defined, right? Anything else? -Boris
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On 10/4/11 2:44 PM, Anne van Kesteren wrote: On Tue, 04 Oct 2011 20:32:02 +0200, Ian Hickson i...@hixie.ch wrote: The idea is that if the server explicitly rejected the CORS request, then the image should not be usable at all. FWIW, from a CORS-perspective both scenarios are fine. CORS only cares about whether data gets shared in the end. Displaying images involves sharing data, basically. That's why we're having to jump through all these hoops -Boris
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On Tue, 04 Oct 2011 20:55:28 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 10/4/11 2:44 PM, Anne van Kesteren wrote: On Tue, 04 Oct 2011 20:32:02 +0200, Ian Hickson i...@hixie.ch wrote: The idea is that if the server explicitly rejected the CORS request, then the image should not be usable at all. FWIW, from a CORS-perspective both scenarios are fine. CORS only cares about whether data gets shared in the end. Displaying images involves sharing data, basically. That's why we're having to jump through all these hoops Sure, but not more than per usual. Note that if you do not specify the crossorigin attribute the image can still get untainted. And if it does not you would still display the image (as always). -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On Tue, Oct 4, 2011 at 11:55 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/4/11 2:44 PM, Anne van Kesteren wrote: On Tue, 04 Oct 2011 20:32:02 +0200, Ian Hickson i...@hixie.ch wrote: The idea is that if the server explicitly rejected the CORS request, then the image should not be usable at all. FWIW, from a CORS-perspective both scenarios are fine. CORS only cares about whether data gets shared in the end. Displaying images involves sharing data, basically. That's why we're having to jump through all these hoops As far as I can tell the tainting behavior WebKit implements is correct, and is specified by the text in http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element . Scroll down to step 6 in the algorithm for When the user agent is to update the image data Note that the default origin behaviour is set to taint when fetching images. -Ken
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On 10/4/11 3:02 PM, Anne van Kesteren wrote: Sure, but not more than per usual. Note that if you do not specify the crossorigin attribute the image can still get untainted. And if it does not you would still display the image (as always). Yes; the point of specifying crossorigin is to opt in to the security model we think the web _should_ have but that we can't roll out across the board. Yet. -Boris
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On 10/4/11 3:04 PM, Kenneth Russell wrote: As far as I can tell the tainting behavior WebKit implements is correct, and is specified by the text in http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element . Scroll down to step 6 in the algorithm for When the user agent is to update the image data Note that the default origin behaviour is set to taint when fetching images. default origin behavior is only relevant when the mode is No CORS. See http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch So for images it only applies when the crossorigin attribute is not set. So no, WebKit's implementation is not correct if you were trying to implement the spec. In particular, if crossorigin is set, you end up at http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch step 3 item 1 in the 'If mode is Anonymous or Use Credentials' section, which is exactly what was cited in the mail that started this thread. -Boris
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On Tue, 04 Oct 2011 21:06:29 +0200, Boris Zbarsky bzbar...@mit.edu wrote: Yes; the point of specifying crossorigin is to opt in to the security model we think the web _should_ have but that we can't roll out across the board. Yet. Well, what you think it should have is not shared by me. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On 10/4/11 3:14 PM, Anne van Kesteren wrote: On Tue, 04 Oct 2011 21:06:29 +0200, Boris Zbarsky bzbar...@mit.edu wrote: Yes; the point of specifying crossorigin is to opt in to the security model we think the web _should_ have but that we can't roll out across the board. Yet. Well, what you think it should have is not shared by me. That's fine. Then you need a better proposal for the various security bugs involved. I'm all ears. -Boris
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On Tue, 4 Oct 2011, Anne van Kesteren wrote: On Tue, 04 Oct 2011 20:32:02 +0200, Ian Hickson i...@hixie.ch wrote: The idea is that if the server explicitly rejected the CORS request, then the image should not be usable at all. FWIW, from a CORS-perspective both scenarios are fine. CORS only cares about whether data gets shared in the end. One advantage I can see about img crossorigin still displaying the image is that the request does not use cookies. Not displaying the image probably makes debugging easier however. On Tue, 4 Oct 2011, Boris Zbarsky wrote: Displaying images involves sharing data, basically. That's why we're having to jump through all these hoops On Tue, 4 Oct 2011, Anne van Kesteren wrote: Sure, but not more than per usual. Note that if you do not specify the crossorigin attribute the image can still get untainted. And if it does not you would still display the image (as always). The thing is that you can grab the image data (at least the alpha channel using 2D canvas) from these images, even with tainting enabled, so if the server says no, we really should honour it. On Tue, 4 Oct 2011, Boris Zbarsky wrote: And in particular an img crossorigin that's in the DOM and fails the CORS checks should not render the image on the page. Anything else is just broken. Agreed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On Tue, 4 Oct 2011, Kenneth Russell wrote: As far as I can tell the tainting behavior WebKit implements is correct, and is specified by the text in http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element . Scroll down to step 6 in the algorithm for When the user agent is to update the image data Note that the default origin behaviour is set to taint when fetching images. If you do a CORS-enabled fetch, you never get that far. If the CORS check fails, the browser is required to act as if a network error occurred. http://www.whatwg.org/specs/web-apps/current-work/#potentially-cors-enabled-fetch -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [MIME Sniffing] Editorial feedback
Comparisons between media types, as defined by MIME specifications, are done in an ASCII case-insensitive manner. [RFC2046] so, the problem is that your `note` here is ambiguous it's hard to understand that you're just saying `mime rfc says that mime comparisons are insensitive`, v. `this specification wants mime comparisons to be insensitive` you want the former; but `note:` doesn't cause that result; nor does the `[rfc]` at the end I'm tempted to just rename them to be less semantic. They're just symbols that don't mean anything, really. please do :) That's a lot of editing! I'm not sure that buys us much. i ask, because it actually was useful when i was dealing w/ someone else's spec they had hex digits and some of them were wrong it was much easier to read when the hex digits were in tt That is intentional. Sniffing SWF is bad times. i think it might be worth an actual NOTE in the spec explaining that SWF is intentionally not sniffed, and what that means for untyped SWF files (actually explaining how it flows and to which resulting sniff type) Thanks to Alfred HÎnes Boris Zbarsky David Singer Mark Pilgrim, and Russ Cox. you need some punctuation before `Boris`, `David`, and `Mark` :) If RDF-flag is 1 and RSS-flag is 1, then let the sniffed-type be application/rss+xml and abort these steps. could you change that to: If both RDF-flag and RSS-flag are 1, then ...?
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On Tue, Oct 4, 2011 at 12:11 PM, Boris Zbarsky bzbar...@mit.edu wrote: default origin behavior is only relevant when the mode is No CORS. See http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch So for images it only applies when the crossorigin attribute is not set. So no, WebKit's implementation is not correct if you were trying to implement the spec. In particular, if crossorigin is set, you end up at http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#potentially-cors-enabled-fetch step 3 item 1 in the 'If mode is Anonymous or Use Credentials' section, which is exactly what was cited in the mail that started this thread. Right, I see now. Sorry. On Tue, Oct 4, 2011 at 12:10 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 4 Oct 2011, Anne van Kesteren wrote: On Tue, 04 Oct 2011 20:32:02 +0200, Ian Hickson i...@hixie.ch wrote: The idea is that if the server explicitly rejected the CORS request, then the image should not be usable at all. FWIW, from a CORS-perspective both scenarios are fine. CORS only cares about whether data gets shared in the end. One advantage I can see about img crossorigin still displaying the image is that the request does not use cookies. Not displaying the image probably makes debugging easier however. On Tue, 4 Oct 2011, Boris Zbarsky wrote: Displaying images involves sharing data, basically. That's why we're having to jump through all these hoops On Tue, 4 Oct 2011, Anne van Kesteren wrote: Sure, but not more than per usual. Note that if you do not specify the crossorigin attribute the image can still get untainted. And if it does not you would still display the image (as always). The thing is that you can grab the image data (at least the alpha channel using 2D canvas) from these images, even with tainting enabled, so if the server says no, we really should honour it. I don't think that this is a good argument for the currently specified behavior. The server only has the option of declining cross-origin access if the application specified the crossorigin attribute. A hostile application would simply not specify that attribute, would receive the tainted image, and would use the timing attack I assume you're referring to to infer the alpha channel. The far more common case today is that the server doesn't understand the CORS request, not that it explicitly forbids cross-origin access to the resource. It seems to me that tainting the image if the CORS check fails is more graceful behavior, but I also see the advantages in early error reporting. Odin, if you file a bug on bugs.webkit.org, would you CC my email address? -Ken On Tue, 4 Oct 2011, Boris Zbarsky wrote: And in particular an img crossorigin that's in the DOM and fails the CORS checks should not render the image on the page. Anything else is just broken. Agreed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On 10/4/11 4:24 PM, Kenneth Russell wrote: I don't think that this is a good argument for the currently specified behavior. The server only has the option of declining cross-origin access if the application specified the crossorigin attribute. A server has the option of declining _all_ non CORS request (e.g. all requests without an Origin header). Servers that care about others getting at their images should do so. Of course that relies on all UAs implementing @crossorigin so that servers can require it when linking to their images... But once we get there, this becomes a quite viable strategy for the server to avoid leaking their images. -Boris
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On Tue, 04 Oct 2011 23:15:01 +0200, Boris Zbarsky bzbar...@mit.edu wrote: A server has the option of declining _all_ non CORS request (e.g. all requests without an Origin header). Servers that care about others getting at their images should do so. Of course that relies on all UAs implementing @crossorigin so that servers can require it when linking to their images... But once we get there, this becomes a quite viable strategy for the server to avoid leaking their images. I think http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html is a better strategy for achieving that. The advantage being that only changes on the server are required. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
* However, FF loads the stylesheet synchronously whereas Opera does it asynchronously from a JS perspective Uh... Firefox does not load anything synchronously. What Firefox does do is block execution of script tags (but not timeouts, callbacks, etc!) if there are pending non-altenate parser-inserted stylesheet loads. This is necessary to make sure that scripts getting layout properties see the effect of those stylesheets. A side-effect is that a script coming after a link will never see the link in an unloaded state... unless there's a network error for the link or whatever. Thanks for the explanation. I took a black-box approach in testing - I don't pretend to know how Firefox works - and from that perspective, it looked like it was synchronous as the |sheet| was present and properly populated in JS. * Some websites (4chan.org for examples) assumes that the |sheet| is always available and that |disabled| will work properly regardless of when it is called. OK. That behavior is allowed by the spec as far as I can tell. It is. However the specification states that |disabled| would be ignored if there is no |sheet|. It looks like web-authors don't factor this into their code. We ended up reverting our changes due to incompatibilities seen in the wild and seek the spec amended before resuming our implementation in a compatible manner. What specific changes do you want to the spec? As far as I can tell, right now the spec says nothing about when sheets become associated and that this would need to be defined, right? Anything else? I think you pinpointed the problem here: defining when the association occurs (and also when none will happen) would remove the issue that we see. Thanks, Julien
Re: [whatwg] Fullscreen
I've been working on implementing this spec in Firefox. We ended up diverging from it slightly, I've added a few notes in the proposed spec as to our changes. I'd like to see this turned into an official spec, and am happy to provide feedback etc. Thanks! Chris Pearce. On 4/10/2011 5:52 a.m., Tantek Çelik wrote: Hi Anne, Fullscreen is currently #2 in my queue after getting another LCWD of CSS3-UI out. I've been incrementally editing on the wiki page you mentioned until it's my primary focus. Feel free to make edits to the wiki if there are particular aspects you want to improve or raise as issues. Either way, though I sympathize with the desire to get rid of prefixes, there are other aspects (besides spec (re)formatting/massaging from wiki to W3C WD) that need more help if prefix-removal is your primary goal, e.g. we don't have a Fullscreen test suite nor even someone to curate/coordinate the creation of one - is that something you'd be available to help with? Thanks, Tantek --Original Message-- From: Anne van Kesteren Sender: whatwg-boun...@lists.whatwg.org To: WHATWG Subject: [whatwg] Fullscreen Sent: Oct 3, 2011 01:17 Is anyone working on turning https://wiki.mozilla.org/Gecko:FullScreenAPI into a standard? It would be nice to get rid of the prefixes. I'm willing to work on it or help someone out if work is already going on. (I know I offered doing this last year, but then some DOM4 things came up and I left for three months. It should be better now.)
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On Tue, 4 Oct 2011, Anne van Kesteren wrote: On Tue, 04 Oct 2011 23:15:01 +0200, Boris Zbarsky bzbar...@mit.edu wrote: A server has the option of declining _all_ non CORS request (e.g. all requests without an Origin header). Servers that care about others getting at their images should do so. Of course that relies on all UAs implementing @crossorigin so that servers can require it when linking to their images... But once we get there, this becomes a quite viable strategy for the server to avoid leaking their images. I think http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html is a better strategy for achieving that. The advantage being that only changes on the server are required. There's no way with this for the server to allow the client to use the image only if the origin is one of a few hundred origins, but not otherwise. (For example, allowing the image to be used by any google.* domain registered by Google, but not any other domain). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On Tue, 4 Oct 2011, Kenneth Russell wrote: The server only has the option of declining cross-origin access if the application specified the crossorigin attribute. A hostile application would simply not specify that attribute, would receive the tainted image, and would use the timing attack I assume you're referring to to infer the alpha channel. A server can avoid that problem by simply not returning the image in that case. The far more common case today is that the server doesn't understand the CORS request, not that it explicitly forbids cross-origin access to the resource. If it doesn't understand the request, there's no point adding the attribute in the first place. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [CORS] WebKit tainting image instead of throwing error
On 10/4/11 5:25 PM, Anne van Kesteren wrote: I think http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html is a better strategy for achieving that. Possibly. The advantage being that only changes on the server are required. Once all clients implement that proposal, yes? -Boris
