When evaluating a parser-inserted script, there are three potential script
global objects to use:
1) The script global object of the document whose active parser the parser
that inserted the script is.
2) The script global object of the document that owned the script element at
the time of
I'm not sure it makes much of a difference from a security point of
view. I suspect WebKit does #3 because it grabs the security context
immediately before executing the script. That actually seems
marginally safer because it means you're unlikely to grab an out-dated
security context.
Adam
On Fri, Sep 3, 2010 at 10:47 AM, Adam Barth w...@adambarth.com wrote:
I'm not sure it makes much of a difference from a security point of
view.
Agreed. Pages can only move elements between pages that are in the
same security context anyway so I can't really think of any attacks
that any of the
On 9/3/10 1:55 PM, Jonas Sicking wrote:
On Fri, Sep 3, 2010 at 10:47 AM, Adam Barthw...@adambarth.com wrote:
I'm not sure it makes much of a difference from a security point of
view.
Agreed. Pages can only move elements between pages that are in the
same security context anyway so I can't
On Thu, Sep 2, 2010 at 4:41 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Well, serving up data as text/plain for it to be readable is one. I agree
that for the specific case of video this is not a big deal.
Yes, I'm talking specifically about that. Sniffing in other cases (in
particular, text
Hi,
It looks like the reset algorithm for input elements is considering all
types except the input type='file'. Shouldn't empty the list of
selected files be added?
Thanks,
--
Mounir
On Sep 3, 2010, at 12:48 , Aryeh Gregor wrote:
Er... Where did I propose this? I proposed speccing that there MUST NOT be
any sniffing, with browsers that sniff therefore being nonconformant. I
didn't propose allowing ad-hoc sniffing.
Right. But the spec never allowed sniffing, and two
On 2010-09-01 21:34, David Singer wrote:
seems like a comma-separated list is the right way to go, and that audio/*
should mean what it says -- any kind of audio (whether that is useful or not
remains to be seen).
I would suggest that this is likely to be used for short captures, and that
I agree that if the server says it accepts something, then it should cover at
least the obvious bases, and transcoding at the server side is not very hard.
However, I do think tht there needs to be some way to protect the server (and
user, in fact) from mistakes etc. If the server was hoping
Most of the MIME types that support multiple channels and sample rates
have registered parameters for selecting those. Using a PCM format
such as audio/L16 (CD/Red Book audio) as a default would waste a huge
amount of network bandwidth, which translates directly into money for
some users.
On
On 08/21/2010 10:23 AM, Christoph Päper wrote:
Someone on wha...@whatwg.org:
This question is sort of CSS related, but I think it's worth bringing up here,
assuming it hasn't already been discussed.
I’m cross-posting to www-style, please follow-up there.
[required]:after {content:*;}
label
On 9/3/10 3:48 PM, Aryeh Gregor wrote:
Why are you assuming that?
Because blocking an entire MIME type seems like it would be massive
overkill . . . but if that's a real use-case, well, okay. It still
can't be *too* hard to check the first few bytes of the contents.
They must do it anyway if
On 2010-09-04 01:55, James Salsman wrote:
Most of the MIME types that support multiple channels and sample rates
have registered parameters for selecting those. Using a PCM format
such as audio/L16 (CD/Red Book audio) as a default would waste a huge
amount of network bandwidth, which
13 matches
Mail list logo
