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
