W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] Unnecessary loading of fallback content in canvas element

From: Charles McCathieNevile <chaals@opera.com>
Date: Sun, 09 Jan 2011 01:03:44 +0100
Message-ID: <op.vo0k4eehwxe0ny@widsith.local>
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
Received on Saturday, 8 January 2011 16:03:44 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC