Re: [webkit-dev] The SrcN responsive images proposal
[And the holy book sayeth cursed is she who participates in standards email, doomed forever to receive email in CC and being unable to sleep at night. ] On 7 Nov 2013, at 17:43, Tab Atkins Jr. jackalm...@gmail.com wrote: A proposal for a new paradigm of using multiple attributes deserves some resistance, careful consideration and exploration of alternatives. I feel my factual example of path d was flippantly tossed aside. So I responded in jest. Apologies if you believed my response was flippant; it was short, but serious and to the point. I explained why the path d example wasn't very good - it's a single (albeit way overcomplicated) list of commands. The src-N attributes already contain lists, so they're comparable. I'm objecting to combining the src-N attributes into a single attribute because that produces a *list of lists*, which is a significant step further in mental complexity. one of the things I liked about srcset is that in the most urgent case it is simply one extra attribute with one higher resolution image. once we get into structure and ordering and multiple options and art direction any of these attribute solutions looks horrible. I don't care whether it is one attribute or 99, it's a pain to understand. if you want structure, use markup. I'm tempted to think the picture element is a better solution for these advanced cases. fwiw path d is an attribute because we expected thousands of values in that and structure would have been too unwieldy. dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
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? On Fri, Nov 8, 2013 at 3:24 PM, Dean Jackson d...@apple.com wrote: [And the holy book sayeth cursed is she who participates in standards email, doomed forever to receive email in CC and being unable to sleep at night. ] On 7 Nov 2013, at 17:43, Tab Atkins Jr. jackalm...@gmail.com wrote: A proposal for a new paradigm of using multiple attributes deserves some resistance, careful consideration and exploration of alternatives. I feel my factual example of path d was flippantly tossed aside. So I responded in jest. Apologies if you believed my response was flippant; it was short, but serious and to the point. I explained why the path d example wasn't very good - it's a single (albeit way overcomplicated) list of commands. The src-N attributes already contain lists, so they're comparable. I'm objecting to combining the src-N attributes into a single attribute because that produces a *list of lists*, which is a significant step further in mental complexity. one of the things I liked about srcset is that in the most urgent case it is simply one extra attribute with one higher resolution image. once we get into structure and ordering and multiple options and art direction any of these attribute solutions looks horrible. I don't care whether it is one attribute or 99, it's a pain to understand. if you want structure, use markup. I'm tempted to think the picture element is a better solution for these advanced cases. fwiw path d is an attribute because we expected thousands of values in that and structure would have been too unwieldy. dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Friday, November 8, 2013, Dean Jackson wrote: [And the holy book sayeth cursed is she who participates in standards email, doomed forever to receive email in CC and being unable to sleep at night. ] On 7 Nov 2013, at 17:43, Tab Atkins Jr. jackalm...@gmail.comjavascript:; wrote: A proposal for a new paradigm of using multiple attributes deserves some resistance, careful consideration and exploration of alternatives. I feel my factual example of path d was flippantly tossed aside. So I responded in jest. Apologies if you believed my response was flippant; it was short, but serious and to the point. I explained why the path d example wasn't very good - it's a single (albeit way overcomplicated) list of commands. The src-N attributes already contain lists, so they're comparable. I'm objecting to combining the src-N attributes into a single attribute because that produces a *list of lists*, which is a significant step further in mental complexity. one of the things I liked about srcset is that in the most urgent case it is simply one extra attribute with one higher resolution image. once we get into structure and ordering and multiple options and art direction any of these attribute solutions looks horrible. I don't care whether it is one attribute or 99, it's a pain to understand. if you want structure, use markup. I'm tempted to think the picture element is a better solution for these advanced cases. I completely agree. I know at least other browser vendors have complained about the implementation complexity of source element, microsyntax in srcset and src-N attributes aren't that much better due to their unnatural construction. Given browser vendors already had to implement audio/video elements, I don't buy the argument that it'll simplify their implementations either. - R. Niwa -- - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
I think this discussion might be more fruitful at a vendor neutral forum, so I've started a thread out on the WHATWG: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-November/041369.html On Fri, Nov 8, 2013 at 6:06 PM, 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? On Fri, Nov 8, 2013 at 3:24 PM, Dean Jackson d...@apple.com wrote: [And the holy book sayeth cursed is she who participates in standards email, doomed forever to receive email in CC and being unable to sleep at night. ] On 7 Nov 2013, at 17:43, Tab Atkins Jr. jackalm...@gmail.com wrote: A proposal for a new paradigm of using multiple attributes deserves some resistance, careful consideration and exploration of alternatives. I feel my factual example of path d was flippantly tossed aside. So I responded in jest. Apologies if you believed my response was flippant; it was short, but serious and to the point. I explained why the path d example wasn't very good - it's a single (albeit way overcomplicated) list of commands. The src-N attributes already contain lists, so they're comparable. I'm objecting to combining the src-N attributes into a single attribute because that produces a *list of lists*, which is a significant step further in mental complexity. one of the things I liked about srcset is that in the most urgent case it is simply one extra attribute with one higher resolution image. once we get into structure and ordering and multiple options and art direction any of these attribute solutions looks horrible. I don't care whether it is one attribute or 99, it's a pain to understand. if you want structure, use markup. I'm tempted to think the picture element is a better solution for these advanced cases. fwiw path d is an attribute because we expected thousands of values in that and structure would have been too unwieldy. dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher timo...@apple.com wrote: As I replied before, there should only be one attribute — srcset. I have a serious suggestion - could we rename srcset to src-n (literally, src-n), and then just ship it? This puns in three interesting ways: 1. If src-N is never accepted, it's still an attribute that holds N src values, so src-n works well. 2. If src-N is accepted, but as a single attribute, src-n is just named perfectly to match the proposal name. 3. If src-N is accepted fully, the obvious ordering is clearly src-1, src-2, src-3, ..., src-n, which matches the fallback we want. A guaranteed last fallback is legitimately useful for the full src-N proposal, so I'm totally okay with integrating that into my proposal. This'll let us ship now, and then continue to discuss src-N for a while, with whatever solution we land on still having a consistent name. Win for authors no matter what the result is. Further discussion will go to whatwg, which is a better place to discuss technical details of the src-N proposal, but I wanted to comment on this: (1) In the case that src-N is never adopted, or is adopted in single-attribute form, srcset matching the CSS image-set() function will be more useful than src-n matching a hypothetical proposal based on multiple attributes. (2) Neither src-n nor srcset is super-obvious as a final fallback, but either is a rule that could plausibly be learned. (3) In the absence of considerations about matching anything else, source set better conveys the idea of selecting from multiple sources than source n, at least to me. So I don't think your proposal is super helpful to enable a future transition. What might be helpful: (A) Change srcset parsing in implementations now to be compatible to extension with an additional list level (for instance, drop everything after the first ||). (B) Remove support for the w and h specifiers from srcset implementations since no one loves those and they are apparently not really adequate to addressing their use case. (C) Ship srcset with these two changes ASAP. This would leave the field open to either extending the microsyntax or adding more attributes or both. And authors will at least have a way to address the multi-resolution-only case, a case where I believe we have no substantial controversy about the right solution. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Fri, Nov 8, 2013 at 8:44 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher timo...@apple.com wrote: As I replied before, there should only be one attribute — srcset. I have a serious suggestion - could we rename srcset to src-n (literally, src-n), and then just ship it? This puns in three interesting ways: 1. If src-N is never accepted, it's still an attribute that holds N src values, so src-n works well. 2. If src-N is accepted, but as a single attribute, src-n is just named perfectly to match the proposal name. 3. If src-N is accepted fully, the obvious ordering is clearly src-1, src-2, src-3, ..., src-n, which matches the fallback we want. A guaranteed last fallback is legitimately useful for the full src-N proposal, so I'm totally okay with integrating that into my proposal. This'll let us ship now, and then continue to discuss src-N for a while, with whatever solution we land on still having a consistent name. Win for authors no matter what the result is. Further discussion will go to whatwg, which is a better place to discuss technical details of the src-N proposal, but I wanted to comment on this: (1) In the case that src-N is never adopted, or is adopted in single-attribute form, srcset matching the CSS image-set() function will be more useful than src-n matching a hypothetical proposal based on multiple attributes. (2) Neither src-n nor srcset is super-obvious as a final fallback, but either is a rule that could plausibly be learned. (3) In the absence of considerations about matching anything else, source set better conveys the idea of selecting from multiple sources than source n, at least to me. So I don't think your proposal is super helpful to enable a future transition. What might be helpful: (A) Change srcset parsing in implementations now to be compatible to extension with an additional list level (for instance, drop everything after the first ||). (B) Remove support for the w and h specifiers from srcset implementations since no one loves those and they are apparently not really adequate to addressing their use case. The w and h specifiers are not implemented in neither WebKit nor Blink, so this is a non-issue. (C) Ship srcset with these two changes ASAP. This would leave the field open to either extending the microsyntax or adding more attributes or both. And authors will at least have a way to address the multi-resolution-only case, a case where I believe we have no substantial controversy about the right solution. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
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
Re: [webkit-dev] The SrcN responsive images proposal
On Thu, Nov 7, 2013 at 3:32 AM, Benjamin Poulain benja...@webkit.orgwrote: On 11/6/13, 3:24 PM, Yoav Weiss wrote: On Wed, Nov 6, 2013 at 11:33 PM, Benjamin Poulain benja...@webkit.org mailto:benja...@webkit.org wrote: On 11/6/13, 10:53 AM, John Mellor wrote: On Sun, Oct 20, 2013 at 2:00 AM, Maciej Stachowiak m...@apple.com mailto:m...@apple.com mailto:m...@apple.com mailto: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. 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 6, 2013, at 4:26 PM, John Mellor joh...@chromium.org wrote: I've suggested before that the attributes could be combined if that's considered simpler. My only concern is that most developers aren't used to putting line breaks in html attributes, so might feel obliged to put all the alternatives on one line, harming readability. But as long as the developer documentation encourages line breaks, that could be fine... As I replied before, there should only be one attribute — srcset. Given that your micro format extends around parts of the existing micro format of srcset, it just makes sense to reuse the same attribute. Wishing srcset didn't exist doesn't make it go away. Tweaking it is more approachable and should get better support from the WebKit community and likely other venders who are now stalled because of this proposal. Especially since the current viewport syntax in srcset has little-to-no support or implementations. Also if srcset is the attribute, the CSS function srcset() should support the same micro format. Designing this proposal around code formatting is a non-issue in my opinion and it surely didn't stop SVG from providing just one d attribute for path. Following the your logic, it should be d-N. Sure, path d=… is primarily meant to be written by software. Though, as responsive designs get more complex, people are going to rely on software to generate these src strings too. I surely don't want to be micromanaging the intrinsic widths in a viewport-urls set if I need to change the width and export again from Photoshop. Some workflow tool is likely going to generate these and having them in one attribute makes them infinitely easier for a script to manage. (And easier for humans too if things need reordered, as I mentioned earlier.) — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher timo...@apple.com wrote: On Nov 6, 2013, at 4:26 PM, John Mellor joh...@chromium.org wrote: I've suggested before that the attributes could be combined if that's considered simpler. My only concern is that most developers aren't used to putting line breaks in html attributes, so might feel obliged to put all the alternatives on one line, harming readability. But as long as the developer documentation encourages line breaks, that could be fine... As I replied before, there should only be one attribute — srcset. Given that your micro format extends around parts of the existing micro format of srcset, it just makes sense to reuse the same attribute. Wishing srcset didn't exist doesn't make it go away. srcset doesn't significantly exist yet. It's in one browser's nightly. I'd like to resolve this soon, but it doesn't help anything to pretend that it's already a done deal that must be engineered around. Tweaking it is more approachable and srcset's parsing algorithm *cannot* be extended in the future. I gave an example of how it would fail over on blink-dev; I can reproduce it here if necessary. should get better support from the WebKit community and likely other venders who are now stalled because of this proposal. The other vendors have implementors ready to write src-N support when it's felt that it's the right thing. Especially since the current viewport syntax in srcset has little-to-no support or implementations. Also if srcset is the attribute, the CSS function srcset() should support the same micro format. The CSS function is image-set(), and it only exists in WebKit/Blink, prefixed. The connection between the CSS and the HTML solutions isn't that strong. Designing this proposal around code formatting is a non-issue in my opinion and it surely didn't stop SVG from providing just one d attribute for path. Following the your logic, it should be d-N. Sure, path d=… is primarily meant to be written by software. Please don't try to use reducto ad absurdum; it usually gives absurd results. The reasoning for multiple attributes is not because it's a list, it's because it's a list of lists, and would require three different delimiters. ~TJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
Designing this proposal around code formatting is a non-issue in my opinion and it surely didn't stop SVG from providing just one d attribute for path. Following the your logic, it should be d-N. Sure, path d=… is primarily meant to be written by software. Please don't try to use reducto ad absurdum; it usually gives absurd results. The reasoning for multiple attributes is not because it's a list, it's because it's a list of lists, and would require three different delimiters. The style attribute is perhaps a better example, as it is in some cases a list of lists, e.g. div style=transform: rotate() translate(); background: red url(foobar.png) / A list of lists in markup is usually expressed as either sub-elements or as non-markup syntax inside an attribute; Enumerated attributes are highly unusual. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher timo...@apple.com wrote: As I replied before, there should only be one attribute — srcset. I have a serious suggestion - could we rename srcset to src-n (literally, src-n), and then just ship it? This puns in three interesting ways: 1. If src-N is never accepted, it's still an attribute that holds N src values, so src-n works well. 2. If src-N is accepted, but as a single attribute, src-n is just named perfectly to match the proposal name. 3. If src-N is accepted fully, the obvious ordering is clearly src-1, src-2, src-3, ..., src-n, which matches the fallback we want. A guaranteed last fallback is legitimately useful for the full src-N proposal, so I'm totally okay with integrating that into my proposal. This'll let us ship now, and then continue to discuss src-N for a while, with whatever solution we land on still having a consistent name. Win for authors no matter what the result is. ~TJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Thu, Nov 7, 2013 at 2:31 PM, Noam Rosenthal n...@webkit.org wrote: Designing this proposal around code formatting is a non-issue in my opinion and it surely didn't stop SVG from providing just one d attribute for path. Following the your logic, it should be d-N. Sure, path d=… is primarily meant to be written by software. Please don't try to use reducto ad absurdum; it usually gives absurd results. The reasoning for multiple attributes is not because it's a list, it's because it's a list of lists, and would require three different delimiters. The style attribute is perhaps a better example, as it is in some cases a list of lists, e.g. div style=transform: rotate() translate(); background: red url(foobar.png) / A list of lists in markup is usually expressed as either sub-elements or as non-markup syntax inside an attribute; Enumerated attributes are highly unusual. Yeah, that's a reasonable counter-example. Note, though, that using style='' for more than testing tweaks is terrible and warned against by virtually every style guide. If you're hand-authoring, using style is virtually always easier and more readable. If you're using JS, using el.style is far simpler; literally manipulating the style attribute's value from JS would be insane. Using style='' from server-side code is acceptable, but then all the complexity is hidden from you anyway. Translating this over to src-N, hand-authoring is a real use-case, so it's important. We don't yet have an API, but manipulating smaller chunks in single attributes is likely easier than manipulating the whole thing (but there are tradeoffs as well, so it may be a wash). Server-side generation doesn't care either way, so that's a wash. I'm pretty sure the argument is almost entirely around hand-authoring, where experience with style='' shows that lists-of-lists are bad. ~TJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher timo...@apple.com wrote: On Nov 6, 2013, at 4:26 PM, John Mellor joh...@chromium.org wrote: I've suggested before that the attributes could be combined if that's considered simpler. My only concern is that most developers aren't used to putting line breaks in html attributes, so might feel obliged to put all the alternatives on one line, harming readability. But as long as the developer documentation encourages line breaks, that could be fine... As I replied before, there should only be one attribute — srcset. Given that your micro format extends around parts of the existing micro format of srcset, it just makes sense to reuse the same attribute. Wishing srcset didn't exist doesn't make it go away. srcset doesn't significantly exist yet. It's in one browser's nightly. I'd like to resolve this soon, but it doesn't help anything to pretend that it's already a done deal that must be engineered around. It is shipping in Safari 6.1, 7 and iOS 7. That ship has sailed. Tweaking it is more approachable and srcset's parsing algorithm *cannot* be extended in the future. I gave an example of how it would fail over on blink-dev; I can reproduce it here if necessary. I don't subscribe to blink-dev. The WebKit community are the ones you need to convince. Designing this proposal around code formatting is a non-issue in my opinion and it surely didn't stop SVG from providing just one d attribute for path. Following the your logic, it should be d-N. Sure, path d=… is primarily meant to be written by software. Please don't try to use reducto ad absurdum; it usually gives absurd results. The reasoning for multiple attributes is not because it's a list, it's because it's a list of lists, and would require three different delimiters. Three whole delimiters. What a crime against humanity! — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher timo...@apple.com wrote: As I replied before, there should only be one attribute — srcset. I have a serious suggestion - could we rename srcset to src-n (literally, src-n), and then just ship it? This puns in three interesting ways: 1. If src-N is never accepted, it's still an attribute that holds N src values, so src-n works well. 2. If src-N is accepted, but as a single attribute, src-n is just named perfectly to match the proposal name. 3. If src-N is accepted fully, the obvious ordering is clearly src-1, src-2, src-3, ..., src-n, which matches the fallback we want. A guaranteed last fallback is legitimately useful for the full src-N proposal, so I'm totally okay with integrating that into my proposal. This'll let us ship now, and then continue to discuss src-N for a while, with whatever solution we land on still having a consistent name. Win for authors no matter what the result is. No, you are just asking for support to muddy the waters and make the web your science project. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 2:43 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I'm pretty sure the argument is almost entirely around hand-authoring, where experience with style='' shows that lists-of-lists are bad. Until you are dealing with dozens of images per tag. That is untenable one image heavy sites and tools will need to be written to auto generate these lists of lists from the original assets. Scripts can easily deal with a micro format in one attribute. They can't easily deal with a micro format spread across multiple src-n attributes in arbitrary HTML. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Thu, Nov 7, 2013 at 3:39 PM, Timothy Hatcher timo...@apple.com wrote:
On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher timo...@apple.com
wrote:
On Nov 6, 2013, at 4:26 PM, John Mellor joh...@chromium.org wrote:
I've suggested before that the attributes could be combined if that's
considered simpler. My only concern is that most developers aren't
used to
putting line breaks in html attributes, so might feel obliged to put
all the
alternatives on one line, harming readability. But as long as the
developer
documentation encourages line breaks, that could be fine...
As I replied before, there should only be one attribute — srcset. Given
that
your micro format extends around parts of the existing micro format of
srcset, it just makes sense to reuse the same attribute. Wishing srcset
didn't exist doesn't make it go away.
srcset doesn't significantly exist yet. It's in one browser's
nightly. I'd like to resolve this soon, but it doesn't help anything
to pretend that it's already a done deal that must be engineered
around.
It is shipping in Safari 6.1, 7 and iOS 7. That ship has sailed.
Can you please clarify this, I just tested in Safari 6.1 and 7 and I don't
see srcset on HTMLImageElement. What do you mean it's shipped?
document.createElement('img').srcset is undefined.
- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 3:49 PM, Elliott Sprehn espr...@chromium.org wrote:
It is shipping in Safari 6.1, 7 and iOS 7. That ship has sailed.
Can you please clarify this, I just tested in Safari 6.1 and 7 and I don't
see srcset on HTMLImageElement. What do you mean it's shipped?
document.createElement('img').srcset is undefined.
Sorry, I was confusing it with the CSS function. Tab is right, the HTML
attribute is only in the WebKit nightly right now.
— Timothy Hatcher
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Thu, Nov 7, 2013 at 3:39 PM, Timothy Hatcher timo...@apple.com wrote: On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: srcset's parsing algorithm *cannot* be extended in the future. I gave an example of how it would fail over on blink-dev; I can reproduce it here if necessary. I don't subscribe to blink-dev. The WebKit community are the ones you need to convince. A simple Yes would have sufficed. I was just asking if I needed to demonstrate it. Take this markup: img srcset=foo 1x, bar 2x || baz 1x, qux 2x You expect this to break into two lists, foo 1x, bar 2x and baz 1x, qux 2x, which are then each split as currently proposed. However, by the current parsing algorithm, || is read as an unsupported descriptor, so it just breaks them into foo 1x, bar 2x || baz 1x, and qux 2x. The middle one is thrown away, because of the duplicate x descriptor, and so the whole thing is just parsed to the same value as foo 1x, qux 2x, which is completely wrong. Designing this proposal around code formatting is a non-issue in my opinion and it surely didn't stop SVG from providing just one d attribute for path. Following the your logic, it should be d-N. Sure, path d=… is primarily meant to be written by software. Please don't try to use reducto ad absurdum; it usually gives absurd results. The reasoning for multiple attributes is not because it's a list, it's because it's a list of lists, and would require three different delimiters. Three whole delimiters. What a crime against humanity! I'm not sure why you're being sarcastic and hostile. Three delimiters is a rather large mental tax for developers. Being dismissive of mental complexity isn't very friendly to authors. It's not the be-all-end-all, but it is important. ~TJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Thu, Nov 7, 2013 at 3:43 PM, Timothy Hatcher timo...@apple.com wrote: On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I have a serious suggestion - could we rename srcset to src-n (literally, src-n), and then just ship it? This puns in three interesting ways: [...] This'll let us ship now, and then continue to discuss src-N for a while, with whatever solution we land on still having a consistent name. Win for authors no matter what the result is. No, you are just asking for support to muddy the waters and make the web your science project. I have no idea what this means. Could you restate your objection in some other way? This is just a renaming request, mind, for an unreleased feature; it's not unusual. ~TJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On 11/7/13, 4:27 PM, Tab Atkins Jr. wrote: On Thu, Nov 7, 2013 at 3:39 PM, Timothy Hatcher timo...@apple.com wrote: On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: srcset's parsing algorithm *cannot* be extended in the future. I gave an example of how it would fail over on blink-dev; I can reproduce it here if necessary. I don't subscribe to blink-dev. The WebKit community are the ones you need to convince. A simple Yes would have sufficed. I was just asking if I needed to demonstrate it. Take this markup: img srcset=foo 1x, bar 2x || baz 1x, qux 2x You expect this to break into two lists, foo 1x, bar 2x and baz 1x, qux 2x, which are then each split as currently proposed. However, by the current parsing algorithm, || is read as an unsupported descriptor, so it just breaks them into foo 1x, bar 2x || baz 1x, and qux 2x. The middle one is thrown away, because of the duplicate x descriptor, and so the whole thing is just parsed to the same value as foo 1x, qux 2x, which is completely wrong. This just sounds like a bad excuse. As far as I know, no browser has shipped srcset. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 4:27 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 7, 2013 at 3:39 PM, Timothy Hatcher timo...@apple.com wrote: On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: srcset's parsing algorithm *cannot* be extended in the future. I gave an example of how it would fail over on blink-dev; I can reproduce it here if necessary. I don't subscribe to blink-dev. The WebKit community are the ones you need to convince. A simple Yes would have sufficed. I was just asking if I needed to demonstrate it. Take this markup: img srcset=foo 1x, bar 2x || baz 1x, qux 2x You expect this to break into two lists, foo 1x, bar 2x and baz 1x, qux 2x, which are then each split as currently proposed. However, by the current parsing algorithm, || is read as an unsupported descriptor, so it just breaks them into foo 1x, bar 2x || baz 1x, and qux 2x. The middle one is thrown away, because of the duplicate x descriptor, and so the whole thing is just parsed to the same value as foo 1x, qux 2x, which is completely wrong. Good point. Thanks for the example. Luckily no one has shipped srcset, so it could be changed. Designing this proposal around code formatting is a non-issue in my opinion and it surely didn't stop SVG from providing just one d attribute for path. Following the your logic, it should be d-N. Sure, path d=… is primarily meant to be written by software. Please don't try to use reducto ad absurdum; it usually gives absurd results. The reasoning for multiple attributes is not because it's a list, it's because it's a list of lists, and would require three different delimiters. Three whole delimiters. What a crime against humanity! I'm not sure why you're being sarcastic and hostile. Three delimiters is a rather large mental tax for developers. Being dismissive of mental complexity isn't very friendly to authors. It's not the be-all-end-all, but it is important. And that is more of a mental tax than managing multiple attributes? Developers already understand boolean logic. They don't already understand multiple stringed together attributes. A proposal for a new paradigm of using multiple attributes deserves some resistance, careful consideration and exploration of alternatives. I feel my factual example of path d was flippantly tossed aside. So I responded in jest. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 4:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 7, 2013 at 3:43 PM, Timothy Hatcher timo...@apple.com wrote: On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I have a serious suggestion - could we rename srcset to src-n (literally, src-n), and then just ship it? This puns in three interesting ways: [...] This'll let us ship now, and then continue to discuss src-N for a while, with whatever solution we land on still having a consistent name. Win for authors no matter what the result is. No, you are just asking for support to muddy the waters and make the web your science project. I have no idea what this means. Could you restate your objection in some other way? This is just a renaming request, mind, for an unreleased feature; it's not unusual. Literally supporting src-n just to test the waters with the idea of introducing src-1..src-99 later is just an abuse of the HTML language and developers attention. Design something right and support it forever. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 4:27 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 7, 2013 at 3:39 PM, Timothy Hatcher timo...@apple.com wrote: On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: srcset's parsing algorithm *cannot* be extended in the future. I gave an example of how it would fail over on blink-dev; I can reproduce it here if necessary. I don't subscribe to blink-dev. The WebKit community are the ones you need to convince. A simple Yes would have sufficed. I was just asking if I needed to demonstrate it. Take this markup: img srcset=foo 1x, bar 2x || baz 1x, qux 2x You expect this to break into two lists, foo 1x, bar 2x and baz 1x, qux 2x, which are then each split as currently proposed. However, by the current parsing algorithm, || is read as an unsupported descriptor, so it just breaks them into foo 1x, bar 2x || baz 1x, and qux 2x. The middle one is thrown away, because of the duplicate x descriptor, and so the whole thing is just parsed to the same value as foo 1x, qux 2x, which is completely wrong. Designing this proposal around code formatting is a non-issue in my opinion and it surely didn't stop SVG from providing just one d attribute for path. Following the your logic, it should be d-N. Sure, path d=… is primarily meant to be written by software. Please don't try to use reducto ad absurdum; it usually gives absurd results. The reasoning for multiple attributes is not because it's a list, it's because it's a list of lists, and would require three different delimiters. Three whole delimiters. What a crime against humanity! I'm not sure why you're being sarcastic and hostile. Three delimiters is a rather large mental tax for developers. Being dismissive of mental complexity isn't very friendly to authors. It's not the be-all-end-all, but it is important. Do you claim that using multiple numbered possibly out-of-order attributes as one level of list hierarchy is a smaller mental tax than an extra delimiter? Seems clearly the opposite to me. - Maciej ~TJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Thu, Nov 7, 2013 at 4:50 PM, Timothy Hatcher timo...@apple.com wrote: On Nov 7, 2013, at 4:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 7, 2013 at 3:43 PM, Timothy Hatcher timo...@apple.com wrote: On Nov 7, 2013, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I have a serious suggestion - could we rename srcset to src-n (literally, src-n), and then just ship it? This puns in three interesting ways: [...] This'll let us ship now, and then continue to discuss src-N for a while, with whatever solution we land on still having a consistent name. Win for authors no matter what the result is. No, you are just asking for support to muddy the waters and make the web your science project. I have no idea what this means. Could you restate your objection in some other way? This is just a renaming request, mind, for an unreleased feature; it's not unusual. Literally supporting src-n just to test the waters with the idea of introducing src-1..src-99 later is just an abuse of the HTML language and developers attention. I still have no idea what you mean. I think that src-n and srcset are roughly synonymous as names. Both seem to appropriately communicate the semantic of multiple sources. It's convenient that src-n puns with src-1, and is itself a decent name for a concept that would be useful to add to the src-N proposal, but all by itself, even if we completely reject src-N, it's still a decent name for the abilities currently packaged up in srcset. Design something right and support it forever. If you read my proposal email, you'll see that this is an attempt to design it right, and there is no intention to stop supporting it at any time. On Thu, Nov 7, 2013 at 4:34 PM, Benjamin Poulain benja...@webkit.org wrote: This just sounds like a bad excuse. I'd appreciate less hostility, please. As far as I know, no browser has shipped srcset. Correct, but you can't say eh, we can change it, it's not shipped yet and we can't change it, it's already mature at the same time. An accurate assessment of srcset is that it's a mature proposal that is not yet exposed to the web, and so can still be changed or replaced safely if there is cause for it. On Thu, Nov 7, 2013 at 4:45 PM, Timothy Hatcher timo...@apple.com wrote: On Nov 7, 2013, at 4:27 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Three delimiters is a rather large mental tax for developers. Being dismissive of mental complexity isn't very friendly to authors. It's not the be-all-end-all, but it is important. And that is more of a mental tax than managing multiple attributes? Developers already understand boolean logic. They don't already understand multiple stringed together attributes. Actually, yes, it is a mental tax. The reason is that the current division of src-N attributes reflects a significant division in use - each separate attribute represents a *distinct* image (a la Art Direction, where different crops of an image may be used at different sizes). Within each attribute, the sources should be identical except for density. This is a helpful and significant distinction. It's easy to understand that all sources in a single attribute should be for the same image. Making the same distinction within the scope of a single attribute is less obvious. Additionally, I already talked about the strong visual separation of separate attributes - it's easy to scan content and see the separate attributes, but it's much more difficult when scanning to see the || separators. A proposal for a new paradigm of using multiple attributes deserves some resistance, careful consideration and exploration of alternatives. I feel my factual example of path d was flippantly tossed aside. So I responded in jest. Apologies if you believed my response was flippant; it was short, but serious and to the point. I explained why the path d example wasn't very good - it's a single (albeit way overcomplicated) list of commands. The src-N attributes already contain lists, so they're comparable. I'm objecting to combining the src-N attributes into a single attribute because that produces a *list of lists*, which is a significant step further in mental complexity. ~TJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Thu, Nov 7, 2013 at 5:03 PM, Maciej Stachowiak m...@apple.com wrote: Do you claim that using multiple numbered possibly out-of-order attributes as one level of list hierarchy is a smaller mental tax than an extra delimiter? Seems clearly the opposite to me. Of course it does when you phrase one with an entire sentence and the other as just an extra delimiter. ^_^ Out-of-order attributes would of course be confusing. There's no reason for authors to do that on purpose, of course; they'd just be confusing themselves. The fact that it's *possible* for them to be authored out-of-order isn't significant here, because there's no *reason* to do so; all the attributes are specified in a single location, so you don't even have the excuse of things being scattered around the document. Just talking about attributes vs delimiters, though, I explained in my most recent email to Timothy why I believe the attribute separation that src-N uses is significant. It's not separate attributes *just* because it's the second level of hierarchy; there's an important difference in the sources specified in a single attribute. Based on my experiences giving talks and teaching the occasional class, I believe that teaching the distinction of all sources within a single src-N attribute must be for the same image with different densities; use different src-N attributes when you're trying to deliver different images is pretty simple; teaching the same thing, but about top-level groups versus low-level groups will be more difficult. ~TJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 7, 2013, at 6:36 PM, Timothy Hatcher timo...@apple.com wrote: On Nov 7, 2013, at 5:43 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I'm objecting to combining the src-N attributes into a single attribute because that produces a *list of lists*, which is a significant step further in mental complexity. We can agree to disagree then. I do not support the use of multiple attributes. It is a grotesque perversion of the HTML language. For what it’s worth, following this thread has teased me into refreshing my understanding of srcset and looking at the SrcN proposal. I’m with Timothy on this. This multiple-attribute thing is not how anybody should understand HTML to work. Thanks, ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Fri, Nov 8, 2013 at 12:50 AM, Timothy Hatcher timo...@apple.com wrote: On Nov 7, 2013, at 2:43 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I'm pretty sure the argument is almost entirely around hand-authoring, where experience with style='' shows that lists-of-lists are bad. Until you are dealing with dozens of images per tag. That is untenable one image heavy sites and tools will need to be written to auto generate these lists of lists from the original assets. Scripts can easily deal with a micro format in one attribute. They can't easily deal with a micro format spread across multiple src-n attributes in arbitrary HTML.\ If we start from the one-attribute approach, we can improve the situation in a simiilar manner to how style is attached to an element. For example: head srcset name=foobar some list-of-lists-of-lists-of-lists /srcset /head body img srcset=ref(#foobar) / or even img src=srcset(foobar) / /body We can even do this kind of thing after the basic img srcset=all-kinds-of-stuff / is supported, solving the feature problem first and the authoring convenience problem second. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
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
Re: [webkit-dev] The SrcN responsive images proposal
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 intendedhttp://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
Re: [webkit-dev] The SrcN responsive images proposal
On 11/6/13, 10:53 AM, John Mellor wrote: On Sun, Oct 20, 2013 at 2:00 AM, Maciej Stachowiak m...@apple.com mailto: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. 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. I have the feeling those corner cases may be better addressed with JavaScript. In my opinion WebKit should not support srcN in its current form. We are here to make the web a better/friendlier platform. The srcN proposal does not do that, it is a catch all that makes the important use cases more difficult. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Wed, Nov 6, 2013 at 9:00 PM, Maciej Stachowiak m...@apple.com wrote: (b) I am dubious of some of the use cases proposed as essential for src-N that ratchet up the complexity. For example, your case #2 of viewport-switching Viewport switching is very common in almost any responsive design. , in particular its headlining use case of a multi-column view that changes number of columns at different viewport widths, was not addressed or even meaningfully discussed in the N years that srcset and picture were being developed. This case was brought uphttp://24ways.org/2012/responsive-images-what-we-thought-we-needed/as one of the cases previous proposals did not address. Admittedly, it wasn't discussed enough, even though it breaks one of the assumptions of previous viewport switching proposals - that a smaller viewport necessarily means a smaller image. This makes me doubt somewhat that addressing this use case is now absolutely critical. It seams kinda neat, but is it really a showstopper to address this in version 1.0 of the feature? There are other advantages to the viewport-url syntax over the previous viewport-switching proposal, srcset's 'w' syntax, that were thoroughly discussed: * The fact that it enables to define viewport width using relative units enables it to match responsive designs that are based on relative units, without breaking the design or the images for users with an non-typical default font-size (e.g. Kindle, or users that have set a preference) * The fact that it enables authors to define either min or max-width as the breakpoints (or for that matter, any MQ, if the author chooses to do so, at the expense of verbosity), makes it compatible and easy to author with any responsive design approach (the classic example is mobile first vs. desktop first), by defining the image's variable width percentage, instead of a fixed width. That makes it much easier to author any responsive design with fluid images where the image dimensions are not linear (i.e. the image dimensions as percentage of the viewport vary between breakpoints, which is a common case), when compared to srcset's 'w' syntax. So, I'd say that the viewport-url syntax is important for ease of authoring and making sure images match their layout, as well as the varying column number as image width case. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Wed, Nov 6, 2013 at 11:33 PM, Benjamin Poulain benja...@webkit.orgwrote: On 11/6/13, 10:53 AM, John Mellor wrote: On Sun, Oct 20, 2013 at 2:00 AM, Maciej Stachowiak m...@apple.com mailto: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. 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 surveyhttp://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. I have the feeling those corner cases may be better addressed with JavaScript. I don't think art-direction qualifies as a corner case. In my opinion WebKit should not support srcN in its current form. We are here to make the web a better/friendlier platform. The srcN proposal does not do that, it is a catch all that makes the important use cases more difficult. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Wed, Nov 6, 2013 at 8:00 PM, Maciej Stachowiak m...@apple.com wrote: (...) I know there are explanations for how src-N got to be as complex as it is. However, the following counterpoints come to mind: (a) The complexity is not well-contained; some of it leaks out even if you want to do something very simple (e.g. cases that would be served by srcset as currently proposed). Actually, srcN should always be at least as simple as any real world srcset. The dpr-switching case is identical (just rename the attribute to src-1). A simple viewport-switching case like a full-width banner changes from: srcset=xs.png 400w .5x, s.png 400w 1x, m.png 400w 2x, s.png 800w .5x, m.png 800w 1x, l.png 800w 2x, m.png 1600w .5x, l.png 1600w 1x, xl.png 1600w 2x, l.png .5x, xl.png 1x to just: src-1=100%; xs.jpg 160, s.jpg 320, m.jpg 640, l.jpg 1280, xl.jpg 2560 Not only is the srcN version shorter, it's also much easier to author: you just say how wide the image will be, and how wide the available image files are, and the browser does all the error-prone maths for you. More complex examples are even more of a wash in favor of srcN - see how the impenetrable 985 character srcset Tab posted on goo.gl/8qvWg0 can be reduced to an intuitively understandable 113 character src-1. These are not contrived examples; these are very common website layouts. (b) I am dubious of some of the use cases proposed as essential for src-N that ratchet up the complexity. For example, your case #2 of viewport-switching, in particular its headlining use case of a multi-column view that changes number of columns at different viewport widths, was not addressed or even meaningfully discussed in the N years that srcset and picture were being developed. This makes me doubt somewhat that addressing this use case is now absolutely critical. It seams kinda neat, but is it really a showstopper to address this in version 1.0 of the feature? Web developers want something that works for all images. They asked *over and over again* for a solution based on the layout size of the image. Sadly that breaks preloaders http://www.stevesouders.com/blog/2013/04/26/i/, so they grudgingly switched to advocating for solutions based solely on viewport width, as it's all we'd allow them. But as responsive web design becomes increasingly dominant, variable numbers of columns is a real problem that almost every new site encounters. And it's just one convenient example of something you can do with srcN that's hard with more rigid solutions; since srcN's size-viewport-list effectively allows you to define the mapping from viewport width to layout size, it can solve any imaginable layout. (c) Some of the complexity is not intrinsic to the use cases at all. Expressing a list of list syntax where one level of the list is implicit in numbered attribute names and the other level is an explicit list with comma separators is more complex than having a more unified list-of-lists syntax (for example, a microsyntax with two kinds of separators). I've suggested beforehttps://lists.webkit.org/pipermail/webkit-dev/2013-November/025815.html that the attributes could be combined if that's considered simpler. My only concern is that most developers aren't used to putting line breaks in html attributes, so might feel obliged to put all the alternatives on one line, harming readability. But as long as the developer documentation encourages line breaks, that could be fine... (...) Regards, Maciej On Wed, Nov 6, 2013 at 10:33 PM, Benjamin Poulain benja...@webkit.org wrote: On 11/6/13, 10:53 AM, John Mellor wrote: 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? 1. Some images on almost every website. 2. Some images on most responsive websites. 3. Some images on some responsive websites. Judging by the unprecedented amount of noise web developers have made about these issues, I think it's fair to say that all 3 are important. The nice thing about the way srcN handles art direction (multiple attributes notwithstanding) is that it's an optional feature; sites which don't need it just use src-1 and don't have to worry about media queries at all. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On 11/6/13, 3:24 PM, Yoav Weiss wrote: On Wed, Nov 6, 2013 at 11:33 PM, Benjamin Poulain benja...@webkit.org mailto:benja...@webkit.org wrote: On 11/6/13, 10:53 AM, John Mellor wrote: On Sun, Oct 20, 2013 at 2:00 AM, Maciej Stachowiak m...@apple.com mailto:m...@apple.com mailto:m...@apple.com mailto: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. 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. Those websites represents only an unquantified subset of the web. Even with that very targeted subset, only a small percentage was actually implementing art-direction. 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? 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). Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Mon, Nov 4, 2013 at 10:19 PM, Ryosuke Niwa rn...@webkit.org wrote: 99 is a very high upper bound while it would still allow us to implement the optimization we're thinking of. I'm of the opinion that we should use exactly one attribute for this feature. The thing is, srcN isn't a list, it's a list of lists. Consider the following srcN for a fixed-width image with art direction: img src-1=(min-width: 640px) 0.5x ph...@0.5x.jpg, 1x ph...@1x.jpg, 2x ph...@2x.jpg src-2=0.5x photo-c...@0.5x.jpg, 1x photo-c...@1x.jpg, 2x photo-c...@2x.jpg I guess one could combine it all into one attribute, e.g. by introducing || as an 3rd separator, in addition to the existing , and ;. For example: 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 But that seems rather harder to read... - R. Niwa On Mon, Nov 4, 2013 at 2:04 PM, Yoav Weiss y...@yoav.ws wrote: On Thu, Oct 24, 2013 at 9:33 AM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss y...@yoav.ws wrote: On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.orgwrote: On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. Just because it was not a big problem in one engine, it doesn't mean it won't be in other engines. If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10. so that we can enumerate all parsed attributes statically at the compilation time. Out of curiosity, what would be the benefits of such a restriction? We're considering to implement an optimization that takes the advantage of parsed attributes being a finite set at the compilation time. Having this feature will make it much harder to implement such an optimization. Note that data-* attributes don't need to be parsed since it doesn't synchronously update Element's internal states. - R. Niwa Will setting the limit on the number of possible attributes at 99 still enable that optimization? Many people (on the RICG's IRC and on Blink-dev) feel that setting the limit to 9, even if it'd be enough today, leaves fairly little space for future evolution. Setting it to some random number between 10 and 99 feels arbitrary to me. So, will 99 be OK with you? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Nov 5, 2013, at 11:18 AM, John Mellor joh...@chromium.orgmailto:joh...@chromium.org wrote: On Mon, Nov 4, 2013 at 10:19 PM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: 99 is a very high upper bound while it would still allow us to implement the optimization we're thinking of. I'm of the opinion that we should use exactly one attribute for this feature. The thing is, srcN isn't a list, it's a list of lists. Consider the following srcN for a fixed-width image with art direction: img src-1=(min-width: 640px) 0.5x ph...@0.5x.jpg, 1x ph...@1x.jpg, 2x ph...@2x.jpg src-2=0.5x photo-c...@0.5x.jpg, 1x photo-c...@1x.jpg, 2x photo-c...@2x.jpg I guess one could combine it all into one attribute, e.g. by introducing || as an 3rd separator, in addition to the existing , and ;. For example: 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 assume authors would just create a new line for each list. That is basically what you do with src-1 and src-2 as well in your example. Writing both beyond each other wouldn’t be very helpful for readability either. I personally do not see where authors would really care if the lists are in two attributes or one. It seems rather a matter of taste or even believe. The point is that srcset can be extended to support more as you suggest in your example. Greetings, Dirk But that seems rather harder to read... - R. Niwa On Mon, Nov 4, 2013 at 2:04 PM, Yoav Weiss y...@yoav.wsmailto:y...@yoav.ws wrote: On Thu, Oct 24, 2013 at 9:33 AM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: On Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss y...@yoav.wsmailto:y...@yoav.ws wrote: On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.commailto:jackalm...@gmail.com wrote: On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fimailto:koivi...@iki.fi wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. Just because it was not a big problem in one engine, it doesn't mean it won't be in other engines. If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10. so that we can enumerate all parsed attributes statically at the compilation time. Out of curiosity, what would be the benefits of such a restriction? We're considering to implement an optimization that takes the advantage of parsed attributes being a finite set at the compilation time. Having this feature will make it much harder to implement such an optimization. Note that data-* attributes don't need to be parsed since it doesn't synchronously update Element's internal states. - R. Niwa Will setting the limit on the number of possible attributes at 99 still enable that optimization? Many people (on the RICG's IRC and on Blink-dev) feel that setting the limit to 9, even if it'd be enough today, leaves fairly little space for future evolution. Setting it to some random number between 10 and 99 feels arbitrary to me. So, will 99 be OK with you? ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
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. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Thu, Oct 24, 2013 at 9:33 AM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss y...@yoav.ws wrote: On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. Just because it was not a big problem in one engine, it doesn't mean it won't be in other engines. If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10. so that we can enumerate all parsed attributes statically at the compilation time. Out of curiosity, what would be the benefits of such a restriction? We're considering to implement an optimization that takes the advantage of parsed attributes being a finite set at the compilation time. Having this feature will make it much harder to implement such an optimization. Note that data-* attributes don't need to be parsed since it doesn't synchronously update Element's internal states. - R. Niwa Will setting the limit on the number of possible attributes at 99 still enable that optimization? Many people (on the RICG's IRC and on Blink-dev) feel that setting the limit to 9, even if it'd be enough today, leaves fairly little space for future evolution. Setting it to some random number between 10 and 99 feels arbitrary to me. So, will 99 be OK with you? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
99 is a very high upper bound while it would still allow us to implement the optimization we're thinking of. I'm of the opinion that we should use exactly one attribute for this feature. - R. Niwa On Mon, Nov 4, 2013 at 2:04 PM, Yoav Weiss y...@yoav.ws wrote: On Thu, Oct 24, 2013 at 9:33 AM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss y...@yoav.ws wrote: On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. Just because it was not a big problem in one engine, it doesn't mean it won't be in other engines. If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10. so that we can enumerate all parsed attributes statically at the compilation time. Out of curiosity, what would be the benefits of such a restriction? We're considering to implement an optimization that takes the advantage of parsed attributes being a finite set at the compilation time. Having this feature will make it much harder to implement such an optimization. Note that data-* attributes don't need to be parsed since it doesn't synchronously update Element's internal states. - R. Niwa Will setting the limit on the number of possible attributes at 99 still enable that optimization? Many people (on the RICG's IRC and on Blink-dev) feel that setting the limit to 9, even if it'd be enough today, leaves fairly little space for future evolution. Setting it to some random number between 10 and 99 feels arbitrary to me. So, will 99 be OK with you? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Mon, Nov 4, 2013 at 2:19 PM, Ryosuke Niwa rn...@webkit.org wrote: 99 is a very high upper bound while it would still allow us to implement the optimization we're thinking of. I'm of the opinion that we should use exactly one attribute for this feature. Can you explain what this optimization is? It's difficult to figure out how to address your issues without knowing what optimization it prevents. - E ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Mon, Nov 4, 2013 at 3:12 PM, Elliott Sprehn espr...@chromium.org wrote: On Mon, Nov 4, 2013 at 2:19 PM, Ryosuke Niwa rn...@webkit.org wrote: 99 is a very high upper bound while it would still allow us to implement the optimization we're thinking of. I'm of the opinion that we should use exactly one attribute for this feature. Can you explain what this optimization is? It's difficult to figure out how to address your issues without knowing what optimization it prevents. I'm not sure if I wasn't clear here but I'm saying that having an upper bound of 9 or 99 would address the concern of not being able to implement the particular optimization we're considering. Completely separate from that concern, I don't want us to add more than one content attribute to address the use cases src-N proposal addresses for the API's sake although I wouldn't firmly object to it if there is a broad consensus that this is a feature we want in WebKit. However, I don't think that there is such a consensus amongst the WebKit community yet as far as I've been following this thread. As such, I DO NOT support implementing this feature in WebKit. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Mon, Nov 4, 2013 at 4:55 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Nov 4, 2013 at 3:12 PM, Elliott Sprehn espr...@chromium.orgwrote: On Mon, Nov 4, 2013 at 2:19 PM, Ryosuke Niwa rn...@webkit.org wrote: 99 is a very high upper bound while it would still allow us to implement the optimization we're thinking of. I'm of the opinion that we should use exactly one attribute for this feature. Can you explain what this optimization is? It's difficult to figure out how to address your issues without knowing what optimization it prevents. I'm not sure if I wasn't clear here but I'm saying that having an upper bound of 9 or 99 would address the concern of not being able to implement the particular optimization we're considering. Yeah; what optimization do you plan to implement though? Completely separate from that concern, I don't want us to add more than one content attribute to address the use cases src-N proposal addresses for the API's sake although I wouldn't firmly object to it if there is a broad consensus that this is a feature we want in WebKit. However, I don't think that there is such a consensus amongst the WebKit community yet as far as I've been following this thread. As such, I DO NOT support implementing this feature in WebKit. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Mon, Nov 4, 2013 at 5:07 PM, Elliott Sprehn espr...@chromium.org wrote: On Mon, Nov 4, 2013 at 4:55 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Nov 4, 2013 at 3:12 PM, Elliott Sprehn espr...@chromium.orgwrote: On Mon, Nov 4, 2013 at 2:19 PM, Ryosuke Niwa rn...@webkit.org wrote: 99 is a very high upper bound while it would still allow us to implement the optimization we're thinking of. I'm of the opinion that we should use exactly one attribute for this feature. Can you explain what this optimization is? It's difficult to figure out how to address your issues without knowing what optimization it prevents. I'm not sure if I wasn't clear here but I'm saying that having an upper bound of 9 or 99 would address the concern of not being able to implement the particular optimization we're considering. Yeah; what optimization do you plan to implement though? There are many optimizations you can implement if the number of parsed attributes is bounded at compilation time, and that's all I can say. But the bigger issue is that src-N resembles no other content attribute we have as others pointed out on this thread. While the picture element proposal had issues of having to deal with source elements being added or removed dynamically, at least authors are familiar with the pattern. src-N is worse in that it's both complicated and foreign to authors as well as existing tools as Mike pointed out. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. Just because it was not a big problem in one engine, it doesn't mean it won't be in other engines. If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10. so that we can enumerate all parsed attributes statically at the compilation time. Out of curiosity, what would be the benefits of such a restriction? When thinking about the feature's implementation for Blink, I found it easier to iterate once over the element's attribute, create a vector containing all the srcN attributes (so all attrs that start with src-), sort it according to attribute numeric order, and return that vector when the srcN attributes are requested from the element. For the HTMLPreloadScanner, I'd probably need to create a similar vector attribute by attribute, sort it at the tag's end, and send it to the main thread. Wouldn't a similar approach work for WebKit? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Wed, Oct 23, 2013 at 11:24 PM, Yoav Weiss y...@yoav.ws wrote: On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. Just because it was not a big problem in one engine, it doesn't mean it won't be in other engines. If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10. so that we can enumerate all parsed attributes statically at the compilation time. Out of curiosity, what would be the benefits of such a restriction? We're considering to implement an optimization that takes the advantage of parsed attributes being a finite set at the compilation time. Having this feature will make it much harder to implement such an optimization. Note that data-* attributes don't need to be parsed since it doesn't synchronously update Element's internal states. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Thu, Oct 24, 2013 at 7:06 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 23, 2013, at 11:24 PM, Yoav Weiss y...@yoav.ws wrote: On Wed, Oct 23, 2013 at 10:22 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. Just because it was not a big problem in one engine, it doesn't mean it won't be in other engines. If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10. so that we can enumerate all parsed attributes statically at the compilation time. Out of curiosity, what would be the benefits of such a restriction? When thinking about the feature's implementation for Blink, I found it easier to iterate once over the element's attribute, create a vector containing all the srcN attributes (so all attrs that start with src-), sort it according to attribute numeric order, and return that vector when the srcN attributes are requested from the element. Your described strategy is both not quite correct (srcN attributes are not all attributes that start with src-) I left out the followed by an integer part. Obviously, that should be part of the algorithm. and it's O(N^2) for srcN attributes added dynamically with script. The typical case for dynamically added srcN attributes would be adding them in order (since otherwise, a wasteful resource download might be triggered). That is very similar to srcset, which when added dynamically, must be added before the src attribute. For that case, adding N dynamic attributes to the end of the vector would have O(N) complexity. The case for unordered addition can be optimized to O(NlgN) by replacing the vector with a linked list and adding each new attribute in its order using binary search. I think the authoring complexity is a more relevant consideration than the implementation complexity, though. I agree. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
Tab Atkins Jr. jackalm...@gmail.com, 2013-10-22 14:50 -0600: As I've argued before, I think making validators easy to write is a concern that's very, very low on the priority of constituencies. So don't keep framing it that way, then. It's misleading. I'm not arguing for making validators easier to write a priority. (I've never said that, so you don't need to add the quotes.) I'm arguing for not making it harder for authors to catch errors in their HTML markup. Only a few people ever write validators in the entire web, so it's okay to saddle them with extra engineering effort if it helps the other constituencies. I agree about users as a constituency being a higher priority. But I think you're being overly dismissive about the scale of the extra engineering effort you might be saddling tool vendors with when src-N gets implemented. Validators are just one type of tool in a class of related tools that try to provide authoring assistance to people making Web content. In the same class are tools like the HTML-aware features in many text editors, which provide context-sensitive interactive editing help -- with things autocompletion of element and attribute names, etc. There are a lot more of those types of in-editor tools out there than there are validators. And there are libraries and standalone HTML tools that aren't strictly validators but that, like validators, provide a type of static analysis of HTML markup to alert authors to problems they otherwise might not discover until they load their content in a browser and manually test it there. The src-N proposal would potentially making it more difficult for all those kinds of tools to help authors catch errors in the HTML markup they'd use for responsive-images use cases -- specifically, more difficult than markup they'd use if the picture proposal were implemented. (I'm not advocating for picture here, I'm just saying it doesn't have this same shortcoming.) Further, the problem you've described with validating these has nothing to do with src-n itself, but rather is a consequence of the particular technology the W3C's validator currently uses. The particular technology the W3C's validator currently uses is essentially just a formal grammar. And in my experience at least, many other tools that provide static-analysis types of features for working with HTML elements and attributes also use a grammar formalism of some kind. And pretty much none of those formalisms have a way to express that a certain pattern should be allowed as an attribute or element name. They all assume explicit names. Many possible validator architectures would have no problem at all with handling attributes like this. Yeah, it's imaginable that hypothetically a lot of HTML-analysis tools might not have any problem handling a set of attribute names defined by a pattern. The problem is, though, that in practice, I think many existing tools would have a problem with it. In my experience, even existing HTML-analysis tools that don't rely on a grammar like the validator does tend to either pretty much have what amounts to an ad-hoc equivalent of a formal grammar, or are hard-coded with data structures that assume new attribute names that might get added to them are going to be discrete names, not patterns. That assumption in a lot of existing tools that any attribute names they'll ever need to deal with are going to be names, not patterns, pretty much amounts to being an invariant. And with src-N you'd be changing that invariant. --Mike -- Michael[tm] Smith http://people.w3.org/mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Tue, Oct 22, 2013 at 11:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of data-* attributes are not parsed. attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. I didn't say it is a big problem. I said it is ugly. antti ~TJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. Just because it was not a big problem in one engine, it doesn't mean it won't be in other engines. If we're supporting src-N attributes in WebKit, I'd like to see N to have a small upper bound; e.g. 10. so that we can enumerate all parsed attributes statically at the compilation time. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Sat, Oct 19, 2013 at 7:00 PM, Maciej Stachowiak m...@apple.com wrote: My initial impression is that it seems a bit overengineered. Can you elaborate on these concerns? I tried to find the simplest set of features that solves the use-cases I was presented with in a good way: * lists of urls and resolutions, like basic srcset * use of familiar MQs rather than the new and, from developer feedback, rather confusing 100w terminology. * a variant of the above for handling cases where the image's sizes is variable, rather than known at authoring time, without needing to repeat yourself a ton. The FF and Blink implementors, several RICG folk, and a number of web authors have told me that they like src-n quite a bit. That's not conclusive, of course (we can definitely find people who dislike it, too), but it's not something I'm trying to push without any support. ^_^ On Sun, Oct 20, 2013 at 3:31 AM, PERIER Romain romain.per...@gmail.com wrote: srcset is not complicated enough for a web developer? why do you want to add complexity for the developer ? The srcset specification already convers DRP switching and viewport (not implemented yet, but it is planned, it is in my todo list) The src-n proposal is nearly a superset of srcset. For the simple, and expected to be most common, case of just delivering an image at various densities, the syntax is *identical* to srcset. The two other tweaks are just a modification to the viewport-switching from a brand syntax to a more familiar MQ-based syntax, and a shortcut syntax to make it possible to specify a variable-sized image without requiring the author to repeat their urls or do non-obvious math to discover where the best breakpoints are. That last one, in particular, is pretty important I think. Handling a variably-sized image in full srcset syntax is *possible*, but doing it well is quite a lot of work, and I don't think most authors will do so. Instead, they'll do the minimum amount of typing to get stuff to work on the devices they have, and I don't blame them for that. However, this means that monitor sizes outside the range they thought about aren't served well, nor are future higher densities: why would anyone purposely add a 3x or 4x image when such devices don't exist yet; why would anyone spend the effort to provide 1x density images for low-bandwidth connections when *their* bandwidth is just fine? If you last read the spec more than a week ago, I rewrote the section concerning this last grammar branch to make it much easier to understand what it's for, and added more example. Please give it a whirl and see if you understand my point a little better. why don't you propose improvements to the original specification/implementation instead of reinventing the wheel ? Syntaxically-speaking, it's not smart. srcset cannot be reasonably extended into something that solves the problems as well as I think that src-n does. I apologize for coming up with this idea relatively late in the process, but there's not much I can do about that now. That said, the processing algorithm already handles src as a fallback value, and there's an issue logged there talking about how srcset can be used as a fallback as well. While it would be ideal if we dropped our initial srcset implementations in favor of src-n, it's not killer if we end up keeping it and src-n both. On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing in Blink, that it's not a big problem. As to the design concern, the platform certainly does already have lists, but putting this stuff into a single attribute would make it a list of lists, which is hard to read, write, and maintain. I felt that the pain of having lists of lists was worse for authors than the cost of understanding multiple attributes. I think it's similar to data-* - it *could* have been designed as a single data attribute, with either a microsyntax or maybe just JSON to allow you to specify multiple key-value pairs, but it was easier to read and write as separate attributes. The other approach to this is to use multiple elements, like picture/source. Several implementors have expressed concern with this approach from an implementation-difficulty perspective; there have been suggestions about how source processing could be tweaked to make it easier, but then we have the fairly bad situation of source acting differently in video/audio and picture. This approach also means you have to introduce new elements, rather than using the existing
Re: [webkit-dev] The SrcN responsive images proposal
On Oct 22, 2013, at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sat, Oct 19, 2013 at 7:00 PM, Maciej Stachowiak m...@apple.com wrote: My initial impression is that it seems a bit overengineered. Can you elaborate on these concerns? - The syntax is effectively a list of lists, the outer level being implicit in the numbers in the attribute names, and the inner being an explicit comma-separated list. That seems complicated. - Media queries are much more general than is actually needed for the use cases as outlined in the spec (even if reduced to only allowing a single clause). Granted, the useful subset of media queries is easier to read than w/h. - Even if you want to use only the inner level of list, you still need to acknowledge the implicit outer level (in which case having src-1 or whatever in your markup seems weird). To be fair, this could be addressed by still supporting srcset and giving it a defined place in the resolution order, as proposed by the spec itself in ISSUE 5. - The proposal defines a rather complicated structured microsyntax. That's from skimming the spec. My opinion could change on closer reading. Regards, Maciej I tried to find the simplest set of features that solves the use-cases I was presented with in a good way: * lists of urls and resolutions, like basic srcset * use of familiar MQs rather than the new and, from developer feedback, rather confusing 100w terminology. * a variant of the above for handling cases where the image's sizes is variable, rather than known at authoring time, without needing to repeat yourself a ton. The FF and Blink implementors, several RICG folk, and a number of web authors have told me that they like src-n quite a bit. That's not conclusive, of course (we can definitely find people who dislike it, too), but it's not something I'm trying to push without any support. ^_^ On Sun, Oct 20, 2013 at 3:31 AM, PERIER Romain romain.per...@gmail.com wrote: srcset is not complicated enough for a web developer? why do you want to add complexity for the developer ? The srcset specification already convers DRP switching and viewport (not implemented yet, but it is planned, it is in my todo list) The src-n proposal is nearly a superset of srcset. For the simple, and expected to be most common, case of just delivering an image at various densities, the syntax is *identical* to srcset. The two other tweaks are just a modification to the viewport-switching from a brand syntax to a more familiar MQ-based syntax, and a shortcut syntax to make it possible to specify a variable-sized image without requiring the author to repeat their urls or do non-obvious math to discover where the best breakpoints are. That last one, in particular, is pretty important I think. Handling a variably-sized image in full srcset syntax is *possible*, but doing it well is quite a lot of work, and I don't think most authors will do so. Instead, they'll do the minimum amount of typing to get stuff to work on the devices they have, and I don't blame them for that. However, this means that monitor sizes outside the range they thought about aren't served well, nor are future higher densities: why would anyone purposely add a 3x or 4x image when such devices don't exist yet; why would anyone spend the effort to provide 1x density images for low-bandwidth connections when *their* bandwidth is just fine? If you last read the spec more than a week ago, I rewrote the section concerning this last grammar branch to make it much easier to understand what it's for, and added more example. Please give it a whirl and see if you understand my point a little better. why don't you propose improvements to the original specification/implementation instead of reinventing the wheel ? Syntaxically-speaking, it's not smart. srcset cannot be reasonably extended into something that solves the problems as well as I think that src-n does. I apologize for coming up with this idea relatively late in the process, but there's not much I can do about that now. That said, the processing algorithm already handles src as a fallback value, and there's an issue logged there talking about how srcset can be used as a fallback as well. While it would be ideal if we dropped our initial srcset implementations in favor of src-n, it's not killer if we end up keeping it and src-n both. On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto koivi...@iki.fi wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. The parsing aspect isn't particularly new - parsing data-* attributes presents the same problem. You just need to filter the list of attributes on the element to look for things with a src- prefix. I've heard direct feedback from Yoav, implementing
Re: [webkit-dev] The SrcN responsive images proposal
Benjamin Poulain benja...@webkit.org, 2013-10-20 13:08 -0700: On 10/20/13, 9:07 AM, Antti Koivisto wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. I was thinking the same thing last night. In addition to weirdness on the engine side, it looks like a nightmare for authoring/tooling. Is there a precedent for this strange notation? As far as having a open set of attribute names defined by a pattern rather than a set of discrete names, I think the only precedent is the custom data attributes mechanism, which I guess as you know provides for having attribute names with a data- prefix followed by some arbitrary string. But unlike the spec for the data-* attributes, whose values can be pretty much anything, the proposed srcN spec also places requirements on the expected microsyntax/datatype for srcN values. So while tools can pretty much ignore data-* values -- or even ignore the data-* attributes altogether, since they're not meant to have any meaning or utility except in the context of the JavaScript code specific to whatever Web application they're used in -- it's imaginable that tool vendors might want to have their tools provide some assistance to authors with, say, confirming that their srcN values conform to the expected microsyntax. Especially since the proposed srcN microsyntax is relatively arcane and error- prone (though less arcane and error-prone than the srcset microsyntax). For some tools, providing that kind of support for srcN really might not be so hard to do all. But for other tools, I know it can be. To give a specific example: I work on the code for the W3C validator and I can tell you that implementing validator support for the srcN proposal would require adding a not-insignificant amount of new special-casing code that nothing else has ever required, along with some greater-than-normal (though still relatively small) runtime cost. And the way I'd have to implement it seems hacky and ugly and I'd really rather not do it unless there's no other alternative we can get agreement on for solving the responsive-images problem. --Mike -- Michael[tm] Smith http://people.w3.org/mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
Hi all, srcset is not complicated enough for a web developer? why do you want to add complexity for the developer ? The srcset specification already convers DRP switching and viewport (not implemented yet, but it is planned, it is in my todo list) why don't you propose improvements to the original specification/implementation instead of reinventing the wheel ? Syntaxically-speaking, it's not smart. I agree with Maciej. Regards, Romain 2013/10/20 Maciej Stachowiak m...@apple.com My initial impression is that it seems a bit overengineered. - Maciej On Oct 19, 2013, at 4:39 PM, Yoav Weiss y...@yoav.ws wrote: Hello WebKiteers, I'd like to get the project's opinion on a recent responsive image proposal by Tab Atkins dubbed srcN: http://tabatkins.github.io/specs/respimg/Overview.html This proposal covers all the major responsive images use-cases: DPR based resource selection, viewport dimensions based resource selection and art-direction. It does so while avoiding previous implementor concerns regarding the picture element and its complexity, and while providing better authoring tools for viewport based resource selection than previous proposals. The srcN proposal does come to replace the srcset DPR switching syntax which recently landed in WebKit (an effort I was a part of). OTOH, srcN's x-based URL syntax replicates srcset's DPR syntax, so I believe large parts of that code can be reused in srcN's implementation. Will the project welcome patches implementing the srcN proposal? (Possibly behind a flag) Thanks, Yoav ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Oct 20, 2013 11:31 AM, PERIER Romain romain.per...@gmail.com wrote: Hi all, srcset is not complicated enough for a web developer? why do you want to add complexity for the developer ? The srcset specification already convers DRP switching and viewport The reasoning behind the new proposal was detailed by John Melloer at http://www.w3.org/community/respimg/2013/10/14/reasoning-behind-srcn-replacing-srcset-and-picture/ In short, srcset's viewport syntax doesn't cover the art-direction use-case and doesn't really cover the viewport based resource selection use case either. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
Le 20 oct. 2013 à 14:39, Yoav Weiss y...@yoav.ws a écrit : On Oct 20, 2013 11:31 AM, PERIER Romain romain.per...@gmail.com wrote: Hi all, srcset is not complicated enough for a web developer? why do you want to add complexity for the developer ? The srcset specification already convers DRP switching and viewport In short, srcset's viewport syntax doesn't cover the art-direction use-case and doesn't really cover the viewport based resource selection use case either. So, it is a good enough reason to rewrite everything from scratch without even trying to propose an improvement to the specification ? As far I know the spec and the implementation are still work in progress, so… Regards, Romain ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. antti On Sun, Oct 20, 2013 at 4:00 AM, Maciej Stachowiak m...@apple.com wrote: My initial impression is that it seems a bit overengineered. - Maciej On Oct 19, 2013, at 4:39 PM, Yoav Weiss y...@yoav.ws wrote: Hello WebKiteers, I'd like to get the project's opinion on a recent responsive image proposal by Tab Atkins dubbed srcN: http://tabatkins.github.io/specs/respimg/Overview.html This proposal covers all the major responsive images use-cases: DPR based resource selection, viewport dimensions based resource selection and art-direction. It does so while avoiding previous implementor concerns regarding the picture element and its complexity, and while providing better authoring tools for viewport based resource selection than previous proposals. The srcN proposal does come to replace the srcset DPR switching syntax which recently landed in WebKit (an effort I was a part of). OTOH, srcN's x-based URL syntax replicates srcset's DPR syntax, so I believe large parts of that code can be reused in srcN's implementation. Will the project welcome patches implementing the srcN proposal? (Possibly behind a flag) Thanks, Yoav ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On 10/20/13, 9:07 AM, Antti Koivisto wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. I was thinking the same thing last night. In addition to weirdness on the engine side, it looks like a nightmare for authoring/tooling. Is there a precedent for this strange notation? Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
On Sun, Oct 20, 2013 at 11:08 PM, Benjamin Poulain benja...@webkit.orgwrote: On 10/20/13, 9:07 AM, Antti Koivisto wrote: Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. I was thinking the same thing last night. In addition to weirdness on the engine side, it looks like a nightmare for authoring/tooling. Is there a precedent for this strange notation? Also CSS selectors only support matching exact attribute names. There is no way to write universal elements with some srcN attribute query for example. This might not be important for practical uses here but it does demonstrate that the approach is a poor fit to the platform. antti Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The SrcN responsive images proposal
My initial impression is that it seems a bit overengineered. - Maciej On Oct 19, 2013, at 4:39 PM, Yoav Weiss y...@yoav.ws wrote: Hello WebKiteers, I'd like to get the project's opinion on a recent responsive image proposal by Tab Atkins dubbed srcN: http://tabatkins.github.io/specs/respimg/Overview.html This proposal covers all the major responsive images use-cases: DPR based resource selection, viewport dimensions based resource selection and art-direction. It does so while avoiding previous implementor concerns regarding the picture element and its complexity, and while providing better authoring tools for viewport based resource selection than previous proposals. The srcN proposal does come to replace the srcset DPR switching syntax which recently landed in WebKit (an effort I was a part of). OTOH, srcN's x-based URL syntax replicates srcset's DPR syntax, so I believe large parts of that code can be reused in srcN's implementation. Will the project welcome patches implementing the srcN proposal? (Possibly behind a flag) Thanks, Yoav ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
