[webkit-dev] The SrcN responsive images proposal

[Yoav Weiss]

On Thu, Nov 7, 2013 at 3:32 AM, Benjamin Poulain <benjamin at webkit.org>wrote:

> On 11/6/13, 3:24 PM, Yoav Weiss wrote:
>
>>
>> On Wed, Nov 6, 2013 at 11:33 PM, Benjamin Poulain <benjamin at webkit.org
>> <mailto:benjamin at webkit.org>> wrote:
>>
>>     On 11/6/13, 10:53 AM, John Mellor wrote:
>>
>>         On Sun, Oct 20, 2013 at 2:00 AM, Maciej Stachowiak
>>         <mjs at apple.com <mailto:mjs at apple.com>
>>         <mailto:mjs at apple.com <mailto:mjs at apple.com>>> wrote:
>>           >
>>           > My initial impression is that it seems a bit overengineered.
>>
>>         I sympathize. The issue of srcN appearing to be a complex
>>         solution to a
>>         seemingly simple problem came up again on IRC chatting to rniwa,
>>         so I
>>         thought I'd try to explain this briefly.
>>
>>         Unfortunately, responsive images is a deceptively complex
>>         problem. There
>>         are 3 main use cases:
>>         1. dpr-switching: fixed-width image resolution based on
>>         devicePixelRatio.
>>         2. viewport-switching: flexible-width image resolution based on
>>         viewport
>>         width and devicePixelRatio.
>>         3. art direction: same as #1 or #2, except additionally, must
>> serve
>>         completely different images based on viewport width.
>>
>>
>>     How important and common are each of those use cases?
>>     Handling every imaginable use case by the Engine is a non-goal.
>>
>>
>>     There has been a lot of demand for dpr-switching since the first
>>     iPad Retina. This has caused some very ugly hacks on the Web. It is
>>     very important to address that issue.
>>
>>     Viewport switching is usually done to adapt images for mobile device
>>     VS large/huge display devices. It is a valid concern but it is not
>>     easily addressed. Srcset can/should likely be improved regarding this.
>>
>>     I believe (feel free to prove me wrong) dynamic viewport adaptation
>>     and what you call "art direction" is not as common.
>>
>> On a survey ran at the last Mobilism conference (and on Twitter) 41% of
>> respondents said they're already using some hack to get their responsive
>> image "art-directed".
>> A manual responsive site survey
>> <http://japborst.net/blog/the-current-state-of-art-direction.html>
>> showed that
>>
>> 23% of the sites "art-direct" their images, and 58% do that when
>> (subjectively) the design requires it.
>> So it might not be as common as viewport switching (which is practically
>> everywhere), but it is pretty common.
>>
>
> The survey you linked (http://japborst.net/blog/the-current-state-of-art-
> direction.html) was targeting specifically responsive websites.


That's true. This is why I called it a "responsive site survey".

Those websites represents only an unquantified subset of the web.
>

Arguably, they also represent the future of Web design, since the multitude
of devices and form factors renders the alternative methods impractical.


> Even with that very targeted subset, only a small percentage was actually
> implementing art-direction.
>

I wouldn't consider almost 1 out of 4 a small percentage, given the fact
that art-direction today requires some extra effort over a native solution
(the use of polyfills, etc).


> It looks to me like art-direction should not be imposing all the design
> constraints over the more important use cases.
>
>
> Something that is still unclear to me is why srcN would be doing a better
> job than JavaScript for art-direction?
>

SrcN would enable art-directed image to be picked up by the preloader and
loaded fairly early in the page's life-cycle (like all other images).
Using polyfills, you have to either download the polyfill script
synchronously (which is considered a performance bad practice) and
frequently poll the DOM for discovered images that you'd then add to the
resource download queue, or download it asynchronously and start polling
the DOM for image much later in the page's life-cycle. In short, with srcN,
performance would be better.

There are many complex cases that are handled dynamically (changing images
> on zoom; tiling large images on zoom; changing layout on rotation; creating
> popover style layout when switching portrait/landscape, etc).


That's true, and none of them is considered to be implemented as part of a
responsive images solution. (even though some of them can be handled with
CSS).
These cases are all related to interaction with images once they were
loaded, not to the loading process itself and the decision which images
need to be loaded in the first place.

>
>
> Benjamin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131107/4141c427/attachment.html>