On Mon, 30 Jul 2012, James Graham wrote:
>
> There seems to be general agreement (amongst browsers, not yet the spec)
> that if a document does something that causes a new load event from
> within an onload handler (document.open/document.close) the second load
> event is not dispatched. This al
On 11/29/12 9:44 PM, Ian Hickson wrote:
The behaviour called "tainting" in this context in the spec just means
"treat as a cross-origin resource"
Right. My point was that "cross-origin" for the case of stylesheet at
least in Gecko depends on the origin of the script that tries to modify
them
On Thu, 29 Nov 2012, Boris Zbarsky wrote:
> >
> > Anyway, this is somewhat moot to me because it'll all have to be
> > defined by whatever spec it is that currently says that a CSS sheet on
> > http: can't import an image on file:, etc.
>
> Heh. Does it affect things like CSP in any way?
No i
On 11/29/12 5:09 PM, Ian Hickson wrote:
Well, yeah, but the sheet knows which mode it's in, so I don't think that
part of it is a big deal.
Maybe. Problems can arise with a sheet that itself sends CORS headers
but links to sheets that don't and that's tested in a UA that doesn't do
. But OK
On Tue, 1 May 2012, Charles Pritchard wrote:
>
> The list looked at having a (canvas) ctx.stream = mediaElement; option
> to better copy frames from a media stream into Canvas. I don't think
> that the assignment operator will work, but it does seem like we could
> optimize our drawImage calls
On Fri, 8 Jun 2012, Kang-Hao (Kenny) Lu wrote:
> (12/06/08 7:28), Ian Hickson wrote:
> > It still seems like a bit of an edge case, so I think it's ok for us
> > to continue to rely on @import for this for now. But we should keep an
> > eye out for how often people use this technique; if it is in
On Wed, 28 Nov 2012, Boris Zbarsky wrote:
> On 11/28/12 7:42 PM, Ian Hickson wrote:
> > Done, at least on the HTML side. For now it just makes .sheet return
> > null for cross-origin resources.
>
> Pretty sure that's not web-compatible...
Yeah, I don't expect it is. This stuff is going to change
Sounds reasonable to me. Webkit and chromium expose information like this
via the inspector console so users/developers at that can better diagnose
problems locally. Makes sense to also expose that info to app logic so
developers could diagnose from afar.
On Thu, Nov 29, 2012 at 11:40 AM, David B
On Thu, 29 Nov 2012, David Barrett-Kahn wrote:
>
> So are there no objections to this, should I draft a change to the spec?
The "process", insofar as we have one, is what is described here:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
At some p
So are there no objections to this, should I draft a change to the spec?
-Dave
On Mon, Nov 26, 2012 at 12:00 PM, David Barrett-Kahn wrote:
> Right now this event contains no structured information, just an error
> message. It'd be helpful to us to know more about what failed, so we can
> know
These are supported in Chrome. That's what causes the download. From
your comment, it's not clear to me if you are correctly reverse
engineering existing user agents. The techniques we used to create
this list originally are quite sophisticated and involved a massive
amount of data [1]. It woul
On Thu, Nov 29, 2012 at 2:30 PM, Adam Barth wrote:
> On Wed, Nov 28, 2012 at 10:30 PM, Gordon P. Hemsley
> wrote:
>> Based on my reading of the source code, it seems that Gecko treats a
>> resource served as 'application/octet-stream' as an unknown type which
>> is sniffed as if no Content-Type
On Wed, Nov 28, 2012 at 10:30 PM, Gordon P. Hemsley wrote:
> Based on my reading of the source code, it seems that Gecko treats a
> resource served as 'application/octet-stream' as an unknown type which
> is sniffed as if no Content-Type was specified.
>
> Are there security implications with doin
On Nov 29, 2012, at 4:31 AM, Anne van Kesteren wrote:
> On Sat, May 26, 2012 at 3:58 AM, Maciej Stachowiak wrote:
>> I don't think location.domain would be the same as location.tld, to the
>> extent I understand the intent of them.
>> For the URL "http://www.apple.com/";, "apple.com" would be
On Thu, 29 Nov 2012, Gordon P. Hemsley wrote:
>
> The apparent contradiction occurs when, e.g., an Opus file is tagged as
> "application/octet-stream".
>
> If I understand correctly, a UA would return "" when canPlayType() is
> called against such a file—but then the file would actually play
>
To be clear, I'm asking this because I would like to remove the
sniffing of archive types from the mimesniff spec if there aren't any
valid usecases.
On Wed, Nov 28, 2012 at 12:18 PM, Gordon P. Hemsley wrote:
> The mimesniff spec currently includes signatures for ZIP, gzip, and
> RAR archive form
On 11/29/12 1:11 PM, Gordon P. Hemsley wrote:
So... are there any additional places where "application/octet-stream"
should be treated as if the media type was undefined? Or is this
conversation moot now?
To my knowledge, the only places in the web platform that special-case
application/octet-
On Thu, Nov 29, 2012 at 12:57 PM, Boris Zbarsky wrote:
> canPlayType is not called "against a file". It's called with a single
> argument which is a string MIME type. If you pass
> "application/octet-stream", it will return "". Its behavior does not depend
> on any state of the element it's cal
On 11/29/12 12:45 PM, Gordon P. Hemsley wrote:
The apparent contradiction occurs when, e.g., an Opus file is tagged
as "application/octet-stream".
If I understand correctly, a UA would return "" when canPlayType() is
called against such a file
canPlayType is not called "against a file". It's
On Thu, Nov 29, 2012 at 3:02 AM, Boris Zbarsky wrote:
> On 11/29/12 2:53 AM, Gordon P. Hemsley wrote:
>>
>> At one point it says, "The MIME type "application/octet-stream" with
>> no parameters is never a type that the user agent knows it cannot
>> render. User agents must treat that type as equiv
Hi,
Per http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0116.html
I removed the string coercion done in the Notifications API. It is now
up to the UI layer how to deal with lone surrogates, similar to how
that is handled elsewhere in the platform.
https://github.com/whatwg/noti
On Sat, May 26, 2012 at 3:58 AM, Maciej Stachowiak wrote:
> I don't think location.domain would be the same as location.tld, to the
> extent I understand the intent of them.
> For the URL "http://www.apple.com/";, "apple.com" would be the domain, and
> "com" would be the TLD.
Yes, but for the U
On Thu, 29 Nov 2012 04:35:21 +0100, Ian Hickson wrote:
Having the exception object, if any, in the onerror callback, seems
reasonable, and would indeed limit how many more arguments we may have to
add over the years. It seems that providing it as an argument would be
better than as a global, th
On 11/29/12 2:53 AM, Gordon P. Hemsley wrote:
At one point it says, "The MIME type "application/octet-stream" with
no parameters is never a type that the user agent knows it cannot
render. User agents must treat that type as equivalent to the lack of
any explicit Content-Type metadata when it is
On Thu, Nov 29, 2012 at 2:32 AM, Boris Zbarsky wrote:
> On 11/29/12 2:07 AM, Gordon P. Hemsley wrote:
>>
>> So perhaps a more useful question would be what to do in situations
>> like that—should mimesniff treat "application/octet-stream" as a type
>> "supported by the browser" for the purposes of
On 11/29/12 2:32 AM, Boris Zbarsky wrote:
On 11/29/12 2:07 AM, Gordon P. Hemsley wrote:
I imagine this ties in, too, to the issues with sniffing CSS files
that has been raised elsewhere:
https://bugzilla.mozilla.org/show_bug.cgi?id=560388
https://bugzilla.mozilla.org/show_bug.cgi?id=562377
Ne
26 matches
Mail list logo
