On 1/8/11 7:03 PM, Charles McCathieNevile wrote:
That's not clear to me - it seems like it coulbe left as an
implementation detail when the load might take place.
The thing is... DOM APIs allow access to various aspects of the image
data (at least the width/height metadata and the actual imag
On Sun, 09 Jan 2011 00:02:47 +0100, Benjamin Poulain
wrote:
On 01/08/2011 11:45 PM, ext Charles Pritchard wrote:
My point was that the resources are requested, instead of aborted.
Yes, the elements should be in the DOM and focusable (and I've opened
a webkit bug for that) -- my point is that
On 01/08/2011 11:45 PM, ext Charles Pritchard wrote:
My point was that the resources are requested, instead of aborted.
Yes, the elements should be in the DOM and focusable (and I've opened
a webkit bug for that) -- my point is that an img tag should not
spawn a network request during page load,
Date: Sat, 08 Jan 2011 17:41:33 +0100
From: Benjamin Poulain
Subject: Re: [whatwg] Unnecessary loading of fallback content in
canvaselement
On 01/08/2011 12:57 AM, ext Charles Pritchard wrote:
> Let me know if this has been discussed before:
>
> Loading an html page c
On 01/08/2011 12:57 AM, ext Charles Pritchard wrote:
Let me know if this has been discussed before:
Loading an html page containing:
loads the fallback.jpg image, even when canvas is supported.
Is this intentional, or simply the easiest route for the moment?
I would say that is the indented
Let me know if this has been discussed before:
Loading an html page containing:
loads the fallback.jpg image, even when canvas is supported.
Is this intentional, or simply the easiest route for the moment?
-Charles
