Re: Title of the spec may cause heartache

On Tue, Sep 23, 2014 at 9:22 AM, Yoav Weiss <yoav@yoav.ws> wrote:

> That would trigger a double download in supporting browsers, since
> HTMLImageElement just looks to see if its parent is an HTMLPictureElement,
> and doesn't go any further up the tree.
>

That's actually not true, since <noscript>'s DOM is inert. So, that method
could be used to provide some fallback for users that disabled their JS
(but not to ones that got their JS broken for some other reason).


> But yeah, if we want to polyfill *and* avoid double download on old
> browsers, we have to break the pages for users with JS disabled/broken.
>
> Maybe the best compromise is the LQIP technique you were advocating a
> while back - add the src with a very low quality image, with old browsers
> double downloading it (but since it's very small, the damage is minimal),
> and noscript users on old browsers get a low quality image, which is better
> than nothing.
>
> On Tue, Sep 23, 2014 at 11:54 AM, Podjarny, Guy <gpodjarn@akamai.com>
> wrote:
>
>> All,
>>
>> Could this double-download be mitigated by wrapping the <img> tag with
>> <noscript>?
>>
>> Something like this:
>> <img srcset=“book.jpg 1x, book-HD.jpg 2x”>
>> <noscript>
>> <img src=“book-default.jpg”>
>> </noscript>
>>
>> Seems to me like:
>>
>>    - If JS is enabled, no browser will preload book-default.jpg (I
>>    haven’t tested it, but it’s hard to believe this isn’t the case)
>>    - On old browsers (that don’t support srcset)
>>       - If JS is enabled, the polyfill will make the srcset attribute
>>       work, and can delete the <noscript> element if desired
>>       - If JS is disabled, book-default.jpg will be loaded (and perhaps
>>       even preloaded)
>>    - On new browsers (that support <picture>)
>>       - If JS is enabled, they’ll simply use the srcset attribute
>>       - If JS is disabled, they’ll break
>>
>> In other words, you’re trading double-downloading on all non-picture
>> browsers (which for a good while will include, for example, the vast
>> majority of mobile traffic) for broken pages on new browsers with JS
>> disabled.
>>
>> My apologies if I’m missing something obvious or am making a wrong core
>> assumption here.
>>
>> Cheers,
>> Guypo
>>
>> --
>> Guy Podjarny | Akamai CTO, Web | www.guypo.com | @guypod
>> <http://twitter.com/guypod/>
>>
>> From: Yoav Weiss <yoav@yoav.ws>
>> Date: Tuesday, September 23, 2014 at 11:33 AM
>> To: Bruce Lawson <brucel@opera.com>
>> Cc: Attiks <attiks@gmail.com>, John Albin Wilkins <john@albin.net>,
>> Christopher Schmitt <schmitt@christopher.org>, Jason Grigsby <
>> jason@cloudfour.com>, Odin Hørthe Omdal <odinho@opera.com>, "
>> public-respimg@w3.org" <public-respimg@w3.org>
>> Subject: Re: Title of the spec may cause heartache
>> Resent-From: <public-respimg@w3.org>
>> Resent-Date: Tuesday, September 23, 2014 at 11:34 AM
>>
>> @attiks - if you use <img src> with an old browser, you'd have a double
>> download, regardless of using <picture> or srcset, if you're using
>> picturefill.
>> so, if you are using a polyfill, and want to avoid the double download,
>> just omit the src attribute in either case.
>>
>> In any case, that's irrelevant to the "picture or srcset" question.
>>
>> On Tue, Sep 23, 2014 at 7:24 AM, Bruce Lawson <brucel@opera.com> wrote:
>>
>>> On 23 September 2014 13:51, Attiks <attiks@gmail.com> wrote:
>>> > We're using picturefill that adds support for srcset as well, so
>>> you'll get
>>> > both.
>>>
>>> ah, well, I didn't know that. That's nothing to do with new responsive
>>> images in browsers, though.
>>>
>>> bruce
>>>
>>>
>>
>