Re: [whatwg] The src-N proposal
On Fri, Nov 8, 2013 at 11:46 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 8 Nov 2013, Rafael Rinaldi wrote: It looks complex because it tries to solve something complex. I think there’s no way to avoid verbosity to solve such thing. The way you avoid complexity in such things is that you don't solve the overall problem, you solve small segments of the problem (e.g. in script or CSS), then pick the solution you want. So for example, we could have a script to handle image grids, another to handle simple cases where as the window gets wider you display more context in the image, etc. If all these scripts have some common features they all need (e.g. the ability to work with pre-parsing to say which image they need first, so it can be fetched early) then we can provide that common core. This is similar to AppCache vs Alex's ServiceWorkers. AppCache addresses a small set of use cases, probably not enough. ServiceWorkers provides the tools to address a lot of use cases, but isn't directly itself a solution; you use it to build solutions. Another example would be the WebForms2 repetition model, vs Rafael's template. The repetition model idea solved some specific use cases, but trying to make it solve all use cases would be a hugely complicated endeavour and would be really ugly. template provides a tool with which you can build specific solutions, but isn't itself a direct solution. I basically agree with Ian. Let's address the simple use cases first (i.e., device-pixel-ratio switching) and worry about the more complex use cases in the future. Adam
Re: [whatwg] The src-N proposal
On 09.11.2013, at 11:49, Markus Lanthaler markus.lantha...@gmx.net wrote: On Saturday, November 09, 2013 12:53 AM, Bruno Racineux wrote: On 11/8/13 10:46 AM, Rafael Rinaldi rafael.rina...@gmail.com wrote: It looks complex because it tries to solve something complex. I think there¹s no way to avoid verbosity to solve such thing. The only way to avoid verbosity on every img element would be to predefine a relationship between the names/keywords of your images and their respective sizes, ONCE in the head. The browser can then substitute the img suffix to get the right image, without having to spell-out the full image name every time. Well, an alternative would be to move the complexity to the server. I very much doubt that webmasters are going to create all those variations manually anyway. And if so, it's enough to store them according a naming convention the server understands. There are already two proposals how this could work: http://tools.ietf.org/html/draft-grigorik-http-client-hints-00 http://tools.ietf.org/html/draft-snell-http-prefer-18 The browser then just needs to make sure that the right headers are set. We would to be very careful though to not destroy the cacheability of responses. Of course, some form of URL templating would work as well but that probably would become quite complex. While this might be a good solution if you *have* a server, we need to find a solution that works without the server-requirement. There are tons of use-cases for respimg where no server can be provided (e.g. a local/offline App-WebView). Regards, Anselm
Re: [whatwg] The src-N proposal
On Sun, Nov 10, 2013 at 12:20 AM, Adam Barth w...@adambarth.com wrote: On Fri, Nov 8, 2013 at 11:46 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 8 Nov 2013, Rafael Rinaldi wrote: It looks complex because it tries to solve something complex. I think there’s no way to avoid verbosity to solve such thing. The way you avoid complexity in such things is that you don't solve the overall problem, you solve small segments of the problem (e.g. in script or CSS), then pick the solution you want. So for example, we could have a script to handle image grids, another to handle simple cases where as the window gets wider you display more context in the image, etc. If all these scripts have some common features they all need (e.g. the ability to work with pre-parsing to say which image they need first, so it can be fetched early) then we can provide that common core. This is similar to AppCache vs Alex's ServiceWorkers. AppCache addresses a small set of use cases, probably not enough. ServiceWorkers provides the tools to address a lot of use cases, but isn't directly itself a solution; you use it to build solutions. Another example would be the WebForms2 repetition model, vs Rafael's template. The repetition model idea solved some specific use cases, but trying to make it solve all use cases would be a hugely complicated endeavour and would be really ugly. template provides a tool with which you can build specific solutions, but isn't itself a direct solution. I basically agree with Ian. Let's address the simple use cases first (i.e., device-pixel-ratio switching) and worry about the more complex use cases in the future. Remember that we only *have* two use-cases that require different results - resolution choosing and art direction based on viewport breakpoints. These are well-supported as common and necessary operations, done commonly on existing websites using the various responsive image hacks. The final clause that a few people keep hating on is, as I explain in http://www.xanthir.com/b4Su0 solely a mechanism for reducing the *enormous* verbosity that can arise from the existing solutions in fairly simple, reasonable cases. (It's also automatically robust against gains in resolution, whereas the existing solution requires increasing the verbosity *even further* to make it robust.) It's easy to look at something more complex than what you're used to and dismiss all the excess as unneeded, but it's really, seriously not in this case. The things I'm addressing are the things that RICG research found were common and necessary, no more and no less. ~TJ
Re: [whatwg] Viewing situations - Re: The src-N proposal
On Sun, Nov 10, 2013 at 9:36 AM, Markus Ernst derer...@gmx.ch wrote: Am 08.11.2013 16:47 schrieb Yoav Weiss: [1] http://tabatkins.github.io/specs/respimg/Overview.html Having a look at the proposal, and reading the thread especially with regard to complexity and verbosity, I got the impression that @src-n shares a main objection with @srcset and picture, that it mixes up content and design to some extent. Thus I suggest a modified approach which moves the distinction of viewing situations, or breakpoints, to the head of the document, creating some variable-like references to be used instead of numbers. Some kind of src-var instead of src-N. Therefore, a new element for the head would be necessary; I call it situations, it could also be breakpoints or whatever is considered more appropriate: html head situations small: (max-width: 400px); small2x: (max-width: 400px) 2x; medium: (max-width: 1000px); medium2x: (max-width: 1000px) 2x; large2x: (min-width: 1000.01px) 2x; /situations /head body img src-small=pic-small.jpg src-small2x=pic-medium.jpg src-medium=pic-medium.jpg src-medium2x=pic-large.jpg src-large2x=pic-x-large.jpg src=pic-large.jpg alt=Obama talking to a soldier in hospital scrubs. /body /html The variable names are free, instead of small, small2x etc. the author could also use 1, 2 etc. or foo, bar etc. or whatever. Beyond that, it would work the same as src-N, using the resource in @src when none of the defined situations apply. Rationale: Moving the distinction of viewing situations to the head would have some advantages IMO: - Verbosity is centralized, thus has not to be repeated in every img element - The UA does not need to evaluate the same MQs again for every img in the content - In order to achieve a consistent handling of responsivity, the situation variables may be reused in other content elements, such as video, and also in the link element as an alternative to todays @media attribute - Easier handling of redesigns when breakpoints change; no modifications needed in the page content This proposal is not thoroughly thought-through, but I hope it shows the idea. This proposal does not address Variable-Sized Images; handling the difficulty and verbosity of that is indeed centralized to the situations element, but that doesn't make it much better. I'm aware that src-N's reliance on explicit MQs is a weakness. I expect to address it through the general mechanism of custom MQs, which I'll be proposing in a little while when I get around to writing the spec for it. One mechanism I'll propose for defining custom MQs will be a meta value, which'll make the custom MQ available to the preloader, at which point src-N can use them as well. ~TJ
Re: [whatwg] The src-N proposal
On Sun, Nov 10, 2013 at 9:29 AM, Ilya Grigorik igrigo...@gmail.com wrote: On Sun, Nov 10, 2013 at 8:59 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: It's easy to look at something more complex than what you're used to and dismiss all the excess as unneeded, but it's really, seriously not in this case. The things I'm addressing are the things that RICG research found were common and necessary, no more and no less. Big +1 to that -- src-N addresses all the RICG use cases in a consistent and coherent way.. I don't think that's a valuable goal. My preference would be to address only the device-pixel-ratio use case in this iteration. and is the only option that does so. Serving images in our new multi-device / responsive design world *is* a much harder problem and the complexity of src-N is simply a reflection of that.. Sticking our heads in the sand and pretending that this is not the case, or punting the problem down the road (as we've already done for the past few years), is not a sound strategy. If we wait for agreement about how to address the other use cases, we won't ship anything for a long time. I'd rather ship something that's useful today and iterate to improve it in the future than not ship anything for a long time. Adam
Re: [whatwg] Viewing situations - Re: The src-N proposal
2013-11-10 19:36, Markus Ernst wrote:
Having a look at the proposal, and reading the thread especially with
regard to complexity and verbosity, I got the impression that @src-n
shares a main objection with @srcset and picture, that it mixes up
content and design to some extent.
That would be my main concern, too. But I would rather say that it
really mixes up content and presentation, moving to HTML something that
belongs to the scope of styling and can currently be handled in CSS.
Thus I suggest a modified approach which moves the distinction of
viewing situations, or breakpoints, to the head of the document,
creating some variable-like references to be used instead of numbers.
Some kind of src-var instead of src-N. Therefore, a new element for the
head would be necessary; I call it situations, it could also be
breakpoints or whatever is considered more appropriate:
Adding new elements is questionable, especially if they have content
(which would be rendered as-is by current user agents).
head
situations
small: (max-width: 400px);
small2x: (max-width: 400px) 2x;
medium: (max-width: 1000px);
medium2x: (max-width: 1000px) 2x; and
large2x: (min-width: 1000.01px) 2x;
/situations
/head
body
img src-small=pic-small.jpg
src-small2x=pic-medium.jpg
src-medium=pic-medium.jpg
src-medium2x=pic-large.jpg
src-large2x=pic-x-large.jpg
src=pic-large.jpg
alt=Obama talking to a soldier in hospital scrubs.
This, too, would mix content and presentation. Admittedly, the line
between them isn't always crystal clear, even if most of HTML5 pretends
that it is. But here the approach should let an author specify an img
element in markup and separately specify, in a style sheet language,
that in some cases the src attribute value is to be overridden.
If people think that current CSS media queries are inadequate for the
purpose (and I'm not convinced that they are), then the first question
should be whether CSS can be suitably enhanced. Failing that, it would
seem natural to define a new, restricted style language. Something like
this:
style type=text/is
@media(max-width: 400px) { #pic { src: url(pic-small.jpg); } }
...
/style
...
img id=pic src=pic-large.jpg alt=
title=Obama talking to a soldier in hospital scrubs.
If the problem with current CSS approach is that browsers would still
download the resource pointed to by the src attribute, then the
processing of IS (image styling) style sheets could be defined so that
they are evaluated when encountered and they are applied according to
the browsing situation, so that they will take effect when the img
elements are processed. This would be no more adhockery than src-*
attributes would be. Actually, less.
Yucca
Re: [whatwg] The src-N proposal
On Sun, Nov 10, 2013 at 10:46 AM, Adam Barth w...@adambarth.com wrote: On Sun, Nov 10, 2013 at 9:29 AM, Ilya Grigorik igrigo...@gmail.com wrote: On Sun, Nov 10, 2013 at 8:59 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: It's easy to look at something more complex than what you're used to and dismiss all the excess as unneeded, but it's really, seriously not in this case. The things I'm addressing are the things that RICG research found were common and necessary, no more and no less. Big +1 to that -- src-N addresses all the RICG use cases in a consistent and coherent way.. I don't think that's a valuable goal. My preference would be to address only the device-pixel-ratio use case in this iteration. Can you explain why? I believe the RICG's identified use-cases are both reasonable and minimal. If we address *only* the density case right now, significant fractions of *existing* responsive images code won't be able to migrate to the standardized solution, and will be stuck with hacks. We'll obviously never be able to satisfy 100% of use-cases, nor is anyone trying to. But just density isn't enough, based on the observed patterns in the wild. and is the only option that does so. Serving images in our new multi-device / responsive design world *is* a much harder problem and the complexity of src-N is simply a reflection of that.. Sticking our heads in the sand and pretending that this is not the case, or punting the problem down the road (as we've already done for the past few years), is not a sound strategy. If we wait for agreement about how to address the other use cases, we won't ship anything for a long time. I'd rather ship something that's useful today and iterate to improve it in the future than not ship anything for a long time. The RICG and related community has agreed on src-N, and the relevant Blink and FF devs have as well. The only holdout is WebKit, but they haven't expressed any technical objections, just aesthetic ones. (And, not to be rude, but I don't trust the aesthetic judgement of C++ hackers when applied to the web platform; at least, not over the judgement of actual JS and HTML hackers, who are generally fine with the look of src-N. People who write the web rather than write *in* the web have a long history of liking terribly-shaped APIs because they're more familiar to C++ coders.) (IE hasn't expressed an opinion one way or the other, as usual.) I believe you're applying an inappropriately high standard of required agreement to this proposal, compared to what the usual required level is for something to be accepted. ~TJ
Re: [whatwg] The src-N proposal
On Nov 10, 2013 11:39 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sun, Nov 10, 2013 at 10:46 AM, Adam Barth w...@adambarth.com wrote: On Sun, Nov 10, 2013 at 9:29 AM, Ilya Grigorik igrigo...@gmail.com wrote: On Sun, Nov 10, 2013 at 8:59 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: It's easy to look at something more complex than what you're used to and dismiss all the excess as unneeded, but it's really, seriously not in this case. The things I'm addressing are the things that RICG research found were common and necessary, no more and no less. Big +1 to that -- src-N addresses all the RICG use cases in a consistent and coherent way.. I don't think that's a valuable goal. My preference would be to address only the device-pixel-ratio use case in this iteration. Can you explain why? It's for the reason in the second paragraph of my previous email: I don't think we'll get agreement about how to address the other use cases in the near term and I view the device-pixel-ratio use case as important to address in the near term. I believe the RICG's identified use-cases are both reasonable and minimal. If we address *only* the density case right now, significant fractions of *existing* responsive images code won't be able to migrate to the standardized solution, and will be stuck with hacks. We'll obviously never be able to satisfy 100% of use-cases, nor is anyone trying to. But just density isn't enough, based on the observed patterns in the wild. and is the only option that does so. Serving images in our new multi-device / responsive design world *is* a much harder problem and the complexity of src-N is simply a reflection of that.. Sticking our heads in the sand and pretending that this is not the case, or punting the problem down the road (as we've already done for the past few years), is not a sound strategy. If we wait for agreement about how to address the other use cases, we won't ship anything for a long time. I'd rather ship something that's useful today and iterate to improve it in the future than not ship anything for a long time. The RICG and related community has agreed on src-N, and the relevant Blink and FF devs have as well. The only holdout is WebKit, That's exactly the problem. The WebKit community has been clear they don't want to ship src-N. but they haven't expressed any technical objections, just aesthetic ones. (And, not to be rude, but I don't trust the aesthetic judgement of C++ hackers when applied to the web platform; at least, not over the judgement of actual JS and HTML hackers, who are generally fine with the look of src-N. People who write the web rather than write *in* the web have a long history of liking terribly-shaped APIs because they're more familiar to C++ coders.) (IE hasn't expressed an opinion one way or the other, as usual.) You might not find their reasons compelling, but that's largely beside the point. What's relevant is that they aren't willing to ship src-N. Maybe through additional discussion we could find a mutually agreeable approach for addressing the remaining use cases, but that appears unlikely to happen in the near term. I believe you're applying an inappropriately high standard of required agreement to this proposal, compared to what the usual required level is for something to be accepted. If Blink ships src-N and WebKit ships srcset, we'll have a mess on our hands. Authors will end up using both. If they do, they're likely to have different behavior in different browsers, which is an interoperability problem. The best solution I see to the above constraints is to ship device-pixel-ratio switching via srcset today and to continue to discuss how to address the remaining use cases in the future. Adam
Re: [whatwg] Viewing situations - Re: The src-N proposal
Am 10.11.2013 19:48 schrieb Jukka K. Korpela:
2013-11-10 19:36, Markus Ernst wrote:
Having a look at the proposal, and reading the thread especially with
regard to complexity and verbosity, I got the impression that @src-n
shares a main objection with @srcset and picture, that it mixes up
content and design to some extent.
That would be my main concern, too. But I would rather say that it
really mixes up content and presentation, moving to HTML something that
belongs to the scope of styling and can currently be handled in CSS.
That is what I wanted to say - sorry my English is poor sometimes.
Thus I suggest a modified approach which moves the distinction of
viewing situations, or breakpoints, to the head of the document,
creating some variable-like references to be used instead of numbers.
Some kind of src-var instead of src-N. Therefore, a new element for the
head would be necessary; I call it situations, it could also be
breakpoints or whatever is considered more appropriate:
Adding new elements is questionable, especially if they have content
(which would be rendered as-is by current user agents).
I see. So let's use an existing, void element :-)
meta name=situations content=
small: (max-width: 400px),
medium: (max-width: 1000px)
img src-small=pic-small.jpg
src-small2x=pic-medium.jpg
src-medium=pic-medium.jpg
src-medium2x=pic-large.jpg
src-large2x=pic-x-large.jpg
src=pic-large.jpg
alt=Obama talking to a soldier in hospital scrubs.
This, too, would mix content and presentation. Admittedly, the line
between them isn't always crystal clear, even if most of HTML5 pretends
that it is. But here the approach should let an author specify an img
element in markup and separately specify, in a style sheet language,
that in some cases the src attribute value is to be overridden.
If people think that current CSS media queries are inadequate for the
purpose (and I'm not convinced that they are), then the first question
should be whether CSS can be suitably enhanced. Failing that, it would
seem natural to define a new, restricted style language. Something like
this:
style type=text/is
@media(max-width: 400px) { #pic { src: url(pic-small.jpg); } }
...
/style
...
img id=pic src=pic-large.jpg alt=
title=Obama talking to a soldier in hospital scrubs.
That would mean to maintain one or several style declarations per
content image, separated in the style element; looks horrible to me.
The topic we are discussing involves both content and presentation, as
we try to serve different content (image files) when the presentation
changes. As an author, I'd favorite a solution that keeps the content
section as clean, simple and intuitive as possible.
I think that my approach does provide the most simple and intuitive
syntax for the image element, and take all the complicated stuff out
into the head section. This may not be pure separation of content and
presentation, but it sure goes further in that direction than the other
approaches discussed at the time, and it makes maintaining and updating
the content easier than other approaches.
Re: [whatwg] The src-N proposal
On Sun, Nov 10, 2013 at 12:58 PM, Adam Barth w...@adambarth.com wrote: I believe you're applying an inappropriately high standard of required agreement to this proposal, compared to what the usual required level is for something to be accepted. If Blink ships src-N and WebKit ships srcset, we'll have a mess on our hands. Authors will end up using both. If they do, they're likely to have different behavior in different browsers, which is an interoperability problem. The best solution I see to the above constraints is to ship device-pixel-ratio switching via srcset today and to continue to discuss how to address the remaining use cases in the future. srcset is a cul de sac with respect to these goals. Let's look at our options: (1) + srcset addresses resolution-switching. (2) + in theory, srcset provides basic facilities for viewport-switching - although none of the current implementations support it. (3) - srcset viewport-switching syntax is a disaster for real-world scenarios [1] (4) - srcset does not provide any easy way to extend itself for art direction By contrast, src-N is a superset: it covers (1) and (2), with same syntax even; it addresses (3); it enables (4). Viewport-switching is just as important as res-switching: ultimately both are about saving bytes, and both have similar footprint in terms of pixels and bytes shipped. Further, they're not independent problems. After all, the outcome is that we ship a single file based on both parameters, hence the two must work together well (-1 for srcset). Finally, UX matters too (art-direction) and this case must work together with the previous two (-1 for srscet). In short, whatever solution we adopt, it must address all three points in the long run -- this is not a problem with three independent pieces that can be solved by three independent specs. We have three inputs, and we have one output: download X... and I just don't see srcset addressing these criteria. If someone can show me how srcset can, in fact, do this in future, then I'd love to hear it. We have Mozilla and RICG behind src-N, and I hope Blink can put its weight behind it also.. I hope we can all work with Webkit team to address their concerns and solve this problem once and for all. So far, as Tab has pointed out, the src-N concerns we've heard are all cosmetic, and I think those discussions are distracting us from the real conversation we should be having, which is... how is srcset planning to address its shortcomings in a better way than src-N? [1] http://www.xanthir.com/b4Su0
Re: [whatwg] Viewing situations - Re: The src-N proposal
Am 10.11.2013 18:53 schrieb Tab Atkins Jr.: This proposal does not address Variable-Sized Images; handling the difficulty and verbosity of that is indeed centralized to the situations element, but that doesn't make it much better. I omitted variable-sized images indeed. The syntax you propose is very lean and elegant and powerful, but it looks rather unintuitive to me. Many websites are built by highly-skilled professionals, and later maintained by editors with less technical knowledge. They can learn how to export an image in 3 or 5 different sizes, but you can't expect them to apply the correct syntax (nor figure out which values to insert into any future CMS UI to generate the img tag). Also, I am afraid that this shortcut syntax can be quite harmful if applied incorrectly, e.g. by copy-pasting authors. This is why I'd prefer verbosity in this case.
Re: [whatwg] Viewing situations - Re: The src-N proposal
Am 10.11.2013 18:36 schrieb Markus Ernst: Moving the distinction of viewing situations to the head would have some advantages IMO: - Verbosity is centralized, thus has not to be repeated in every img element - The UA does not need to evaluate the same MQs again for every img in the content - In order to achieve a consistent handling of responsivity, the situation variables may be reused in other content elements, such as video, and also in the link element as an alternative to todays @media attribute - Easier handling of redesigns when breakpoints change; no modifications needed in the page content While writing answers to Yucca's and Tab's messages, I got aware of one more interesting point: Many websites are maintained by editors who have no deep knowledge of HTML. They use CMS systems that provide more or less intuitive UIs for content editing. Now, every respImg solution that uses MQs inside the img element will be quite hard to create an useable UI for. In the image selection dialog, it would need to handle an unknown number of sources with the respective MQs. And the editors will need to consult a manual each time they insert an image, to know the values they have to enter for the MQ. OTOH, handling a predefined set of viewing situations could be easily implemented in the image picker of a CMS. Once the system knows the situation variables (by parsing the template's head, or configured in the preferences), it can show a dialog that asks for the exact set of required sources.
Re: [whatwg] The src-N proposal
On Sun, Nov 10, 2013 at 1:53 PM, Ilya Grigorik igrigo...@gmail.com wrote: On Sun, Nov 10, 2013 at 12:58 PM, Adam Barth w...@adambarth.com wrote: I believe you're applying an inappropriately high standard of required agreement to this proposal, compared to what the usual required level is for something to be accepted. If Blink ships src-N and WebKit ships srcset, we'll have a mess on our hands. Authors will end up using both. If they do, they're likely to have different behavior in different browsers, which is an interoperability problem. The best solution I see to the above constraints is to ship device-pixel-ratio switching via srcset today and to continue to discuss how to address the remaining use cases in the future. srcset is a cul de sac with respect to these goals. Let's look at our options: (1) + srcset addresses resolution-switching. (2) + in theory, srcset provides basic facilities for viewport-switching - although none of the current implementations support it. (3) - srcset viewport-switching syntax is a disaster for real-world scenarios [1] Agreed. I recommend removing viewport switching from srcset and addressing only the device-pixel-ratio use case. (4) - srcset does not provide any easy way to extend itself for art direction That's ok. We'll just need to add another mechanism in the future to address art direction. By contrast, src-N is a superset: it covers (1) and (2), with same syntax even; it addresses (3); it enables (4). Unfortunately, src-N is no-go because WebKit refuses to implement it. Now, it's possible you'll convince them that it's not a grotesque perversion of the HTML language (which does seems a bit hyperbolic), but that seems unlikely to happen in the near term. Given the tenor of that discussion, I'd expect we'll need to come up with a new approach and involve stakeholders from the WebKit community earlier in the design process. We have Mozilla and RICG behind src-N, and I hope Blink can put its weight behind it also.. There's certainly interest in src-N from the Blink community, but we're unlikely to ship something here that WebKit refuses to implement. I hope we can all work with Webkit team to address their concerns and solve this problem once and for all. Me too. However, I don't want to wait for that to happen. I want to ship something that addresses the device-pixel-ratio use case in the near term and continue discussing how to address the remaining use cases. So far, as Tab has pointed out, the src-N concerns we've heard are all cosmetic, and I think those discussions are distracting us from the real conversation we should be having, which is... how is srcset planning to address its shortcomings in a better way than src-N? It's not. The only use case srcset will address is the device-pixel-ratio use case. Adam
Re: [whatwg] The src-N proposal
On Nov 11, 2013, at 5:53 AM, Ilya Grigorik igrigo...@gmail.com wrote: On Sun, Nov 10, 2013 at 12:58 PM, Adam Barth w...@adambarth.com wrote: I believe you're applying an inappropriately high standard of required agreement to this proposal, compared to what the usual required level is for something to be accepted. If Blink ships src-N and WebKit ships srcset, we'll have a mess on our hands. Authors will end up using both. If they do, they're likely to have different behavior in different browsers, which is an interoperability problem. The best solution I see to the above constraints is to ship device-pixel-ratio switching via srcset today and to continue to discuss how to address the remaining use cases in the future. srcset is a cul de sac with respect to these goals. Let's look at our options: (1) + srcset addresses resolution-switching. (2) + in theory, srcset provides basic facilities for viewport-switching - although none of the current implementations support it. (3) - srcset viewport-switching syntax is a disaster for real-world scenarios [1] (4) - srcset does not provide any easy way to extend itself for art direction By contrast, src-N is a superset: it covers (1) and (2), with same syntax even; it addresses (3); it enables (4). Viewport-switching is just as important as res-switching: ultimately both are about saving bytes, and both have similar footprint in terms of pixels and bytes shipped. Further, they're not independent problems. After all, the outcome is that we ship a single file based on both parameters, hence the two must work together well (-1 for srcset). Finally, UX matters too (art-direction) and this case must work together with the previous two (-1 for srscet). In short, whatever solution we adopt, it must address all three points in the long run -- this is not a problem with three independent pieces that can be solved by three independent specs. We have three inputs, and we have one output: download X... and I just don't see srcset addressing these criteria. If someone can show me how srcset can, in fact, do this in future, then I'd love to hear it. We have Mozilla and RICG behind src-N, and I hope Blink can put its weight behind it also.. I hope we can all work with Webkit team to address their concerns and solve this problem once and for all. So far, as Tab has pointed out, the src-N concerns we've heard are all cosmetic, and I think those discussions are distracting us from the real conversation we should be having, which is... how is srcset planning to address its shortcomings in a better way than src-N? We can modify the parsing algorithm so that it can support delimiters for example. - R. Niwa
Re: [whatwg] The src-N proposal
On Nov 10, 2013, at 12:20 AM, Adam Barth w...@adambarth.com wrote: On Fri, Nov 8, 2013 at 11:46 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 8 Nov 2013, Rafael Rinaldi wrote: It looks complex because it tries to solve something complex. I think there’s no way to avoid verbosity to solve such thing. The way you avoid complexity in such things is that you don't solve the overall problem, you solve small segments of the problem (e.g. in script or CSS), then pick the solution you want. So for example, we could have a script to handle image grids, another to handle simple cases where as the window gets wider you display more context in the image, etc. If all these scripts have some common features they all need (e.g. the ability to work with pre-parsing to say which image they need first, so it can be fetched early) then we can provide that common core. This is similar to AppCache vs Alex's ServiceWorkers. AppCache addresses a small set of use cases, probably not enough. ServiceWorkers provides the tools to address a lot of use cases, but isn't directly itself a solution; you use it to build solutions. Another example would be the WebForms2 repetition model, vs Rafael's template. The repetition model idea solved some specific use cases, but trying to make it solve all use cases would be a hugely complicated endeavour and would be really ugly. template provides a tool with which you can build specific solutions, but isn't itself a direct solution. I basically agree with Ian. Let's address the simple use cases first (i.e., device-pixel-ratio switching) and worry about the more complex use cases in the future. I agree with this too. It just needs to be noted that there isn't an obvious choice of simple primitive to solve the somewhat more complex cases, assuming they are common enough that we care about preload scanning working for them. So we may have to come back to them at some point. Regards, Maciej
