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
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
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
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
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
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
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
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.
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,
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
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
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
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
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
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.
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
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
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
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
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
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
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
* 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
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
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
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
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
27 matches
Mail list logo
