[whatwg] Unnecessary loading of fallback content in canvas element

Charles McCathieNevile chaals at opera.com
Sat Jan 8 16:03:44 PST 2011

On Sun, 09 Jan 2011 00:02:47 +0100, Benjamin Poulain  
<benjamin.poulain at nokia.com> 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 an img tag should not
>> spawn a network request during page load, for the fallback content
>> unnecessarily.
>> After page load, it makes sense for img and iframe; as injected by
>> scripting; prior to that, it seems wasteful, it seems that
>> img.abort() should be called.
> My point is that such behavior would create differences in behavior  
> depending on where the image is in the dom.
> Once the page is loaded, one would expect all images to be available.  
> Which would not be the case if images are not loaded, the one under  
> canvas would have a different behavior.

Hmmm. While the user agent accessibility guidelines require the ability  
for the user to swap between the alternatives (in this case, the canvas  
and its content elements) in rendering, until you do that there is no need  
I can see to *load* an image if you're only moving focus - until you have  
a need for the image *data*, it is just a placeholder anyway.

> I understand your point, loading stuff is not a free operation. I just  
> think not doing it would make things even more complicated for content  
> provider.

That's not clear to me - it seems like it coulbe left as an implementation  
detail when the load might take place.



Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

More information about the whatwg mailing list