On Nov 8, 2013, at 9:06 AM, John Mellor <joh...@chromium.org> wrote:
> Most discussion so far seems to be bikeshedding the syntax. To make this more > productive, can we focus on the core issues? > > srcN brings two things to the table, compared to srcset: > 1. It handles viewport-switching better (easier to author, avoids repetition > of image urls, allows bandwidth-driven decisions). > 2. It handles art direction. > > Does everyone agree that these are useful and long-overdue problems to solve, > and that the high-level approach of srcN (with <viewport-urls> syntax to > handle viewport switching, and a layer of media queries above that) is the > best (only) known solution to these? Accepting the premises of these use cases, I'm not sure the given proposals are the *only* solutions, although they may be steps in the right direction. (1) Regarding viewport-urls syntax: it has too many numbers in it with no direct indication of what the numbers are. I've tried to learn it, but when I look at an example like this: <img src-1="100%; pic1.png 160, pic2.png 320, pic3.png 640, pic4.png 1280, pic5.png 2560"> Or like this: <img src-1="100% (640px) 50% (960px) 33%; 160.jpg 160, 320.jpg 320, 480.jpg 480, 640.jpg 640, 960.jpg 960, 1280.jpg 1280, 1920.jpg 1920"> I have to go back to the spec to figure out what each of the numbers means. >From what I can tell, there are three kinds of numbers in the second example. >Image width (specified as a percentage of the viewport here, but it could be a >fixed width in any CSS unit), viewport widths that are breakpoints for >selecting different target image widths given in px units, and underlying raw >image sizes given unitless. However, there's no clear indicator that this is >what the numbers mean, or for that matter that they even indicate widths of >any kind. srcset in its original flavor is much hated on due to the w/h specifiers being kind of mysterious. But I think all the numbers in the above could benefit from some sort of syntactic indicator that explains what they do. Even a "w" somewhere would be better than nothing. Also, why is this width-only? To be fair, most pages scroll vertically, but for a horizontal-scrolling page I could imagine height being a much more relevant factor. It seems strangely asymmetric. And finally, it seems like this syntax has no obvious way to specify the height in addition to the width, which is unfortunate because it means that the img element can't be sized for layout until the relevant selected image loads. You could apply a fixed height with style, but to get a different one based on breakpoints you have to resort to a bunch of CSS with media queries. (2) Regarding media queries: Full media queries strike me as overpowered for the problem. Viewport-urls only handles width. And one could imagine maybe extending it to height. Why then does the art direction case need access to a query language with access to color depth, scan type, orientation, etc? Perhaps it should be reduced to the subset of media queries that are relevant to width/height. And perhaps that subset could be used as the breakpoint syntax Now, I'm not saying my criticisms or suggestions here are necessarily correct after all due consideration. I'm just saying that the proposed individual syntax pieces may not be the only or best solutions to their respective problems. Regards, Maciej _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
