On Sun, Oct 20, 2013 at 2:00 AM, Maciej Stachowiak <m...@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. The key difference between #2 and #3, is that with #2 it's just different resolutions of the same image, and it's desirable for browsers to be allowed to load lower resolution variants if bandwidth is limited or expensive, whereas with #3, the browser must strictly respect the width breakpoint (as the image could have a different aspect ratio, so loading the wrong one could break the layout). srcset tackles #1 perfectly, doesn't tackle #3, and tries to tackle #2 with the 'w' unit but that doesn't work as intended<http://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/>, because it turns out images destined for narrower viewports are sometimes much larger. <picture> tackles #1 and #3 but doesn't tackle #2. srcN solves all three use cases: 1. srcN's <x-based-urls> syntax (borrowed from srcset) addresses #1. 2. srcN's <viewport-urls> syntax cleanly addresses #2. 3. Finally, srcN lets you supplement either of the above with <media-query>'d alternatives to address #3. It really can't be much simpler; the only simplification that could be made without sacrificing a use case would be to scrap the <x-based-urls> syntax for fixed-width images (which is technically redundant). Then instead of something like the following: <img src-1="ph...@0.5x.jpg 0.5x, ph...@1x.jpg 1x, ph...@2x.jpg 2x"> you'd have to write: <img src-1="400px; ph...@0.5x.jpg 200, ph...@1x.jpg 400, ph...@2x.jpg 800"> where 400px is the intrinsic width of the image (and as usual in a <viewport-urls> declaration, the alternate image urls are annotated with the width in image pixels of the image files). This would make the syntax consistent between use cases #1 and #2, at the expense of requiring an extra ~8 characters for use case #1. Might be a reasonable tradeoff if it helps people understand it? On Wed, Nov 6, 2013 at 5:39 PM, Dean Jackson <d...@apple.com> wrote: > Also, we should be mindful that whatever solution should be vaguely > applicable to other contexts where you’re selecting resources based > on resolution, etc, such as video and CSS properties. I don’t want > an explosion of attributes everywhere, and I don’t even know how > you’d do that in CSS (background-image-1, background-image-2, …) CSS already has media queries, so to give it parity with srcN, you just need to allow <viewport-urls> as an alternate syntax for image-set(), e.g. image-set(100%; 's.jpg' 160, 'm.jpg' 320, 'l.jpg' 640) For video, people should just do adaptive streaming using Media Source Extensions/DASH/HLS. It's only for images that the quality of the first frame is crucial, and yet you can't afford to wait till layout to know the dimensions. On Wed, Nov 6, 2013 at 5:39 PM, Dean Jackson <d...@apple.com> wrote: > > On 5 Nov 2013, at 9:55 am, Timothy Hatcher <timo...@apple.com> wrote: > > On Nov 5, 2013, at 2:18 AM, John Mellor <joh...@chromium.org> wrote: > > <img srcset="(min-width: 640px) 0.5x ph...@0.5x.jpg, 1x ph...@1x.jpg, 2x > ph...@2x.jpg || 0.5x photo-c...@0.5x.jpg, 1x photo-c...@1x.jpg, 2x > photo-c...@2x.jpg"> > > > I prefer this over multiple attributes. It is a syntax that needs little > explanation before you can read it and use it. It also expands the existing > srcset instead of confusing things with other attributes. > > srcN is also too fiddly. If you want to add a higher precedent srcN, you > need to reorder all the existing srcN attribute names. With srcset you just > need to edit a single attribute's value, adding a logic operator between > the rules. > > > This is a great point. > > Also, we should be mindful that whatever solution should be vaguely > applicable to other contexts where you’re selecting resources based on > resolution, etc, such as video and CSS properties. I don’t want an > explosion of attributes everywhere, and I don’t even know how you’d do that > in CSS (background-image-1, background-image-2, …) > > Dean > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
