Re: [whatwg] Correcting some misconceptions about Responsive Images
On Wed, May 16, 2012 at 12:13 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: I've been doing a lot of work today correcting misconceptions about the Responsive Images proposal that Hixie put into the spec today. I was pretty astonished at how much misinformation was flying around; what's worse, this sort of misinformation was actually making people *angry*, which doesn't exactly make people willing to calmly listen to corrections. So, hopefully this email finds everyone in calmer moods, so we can get everyone on the same page. Any others that people can think of? I have a question regarding Tim Kadlec's summary of the order of events in all of this [1]: 1. Developers got involved in trying to standardize a solution to a common and important problem. 2. The WHATWG told them to move the discussion to a community group. 3. The discussion was moved (back in February), a general consenus (not unanimous, but a majority) was reached about the picture element. 4. Another (partial) solution was proposed directly on the WHATWG list by an Apple employee. 5. A discussion ensued regarding the two methods, where they overlapped, and how the general opinions of each. The majority of developers favored the picture element and the majority of implementors favored the srcset attribute. 6. While the discussion was still taking place, and only 5 days after it was originally proposed, the srcset attribute (but not the picture element) was added to the draft. His account has been quoted [2] elsewhere, and while Tim's order of events seems mostly accurate, Jeremy Keith has clarified [3] that the WHATWG never suggested a CG be created and that Ted's 'srcset' solution wasn't as completely out of the blue as it seemed. However, it still looks like the most upsetting implication of his timeline, namely that the WHATWG is prioritizing implementors over authors, remains unclarified. Is it a misconception to say that the levels of priority outlined in the W3C HTML design principles [4] are not being followed here? Especially since it seems that we can extend Tim's timeline with: 7. Authors react negatively to the addition of 'srcset' in the draft. 8. The 'living' draft is not changed and the authors' anger eventually fades into hopeless acceptance because once something goes in to the draft, it is set in stone forever and for all time. Ok, so 8 is both hyperbolic and in the future, but a lot of people seem to think that this is where we are headed. Personally, I'm not angry about this and I'm willing to calmly listen to corrections, I'm just trying to wade through all the misinformation here. -Brenton Strine [1] http://timkadlec.com/2012/05/wtfwg/ [2] http://adactio.com/journal/5474/ [3] http://www.goodreads.com/author_blog_posts/2463167-secret-src [4] http://www.w3.org/TR/html-design-principles/
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Mon, May 21, 2012 at 4:03 PM, brenton strine brenton.str...@gmail.com wrote: However, it still looks like the most upsetting implication of his timeline, namely that the WHATWG is prioritizing implementors over authors, remains unclarified. Is it a misconception to say that the levels of priority outlined in the W3C HTML design principles [4] are not being followed here? Yes, it's a misconception, since @srcset and picture are roughly equally easy for an implementor to implement. The prioritizing language is about valuing the *needs* of one group over another. For example, if we rejected a suggestion because it was slightly harder to implement despite being better to author, that would be prioritizing impls over authors. What happened here is simply that Hixie thought that one syntax (which happened to be close to one suggested by someone on the Safari team) was better than another syntax (which happened to be suggested by the CG). The picture proposal presented by the CG was insufficient to address all the use-cases, as well. (In particular, the resolution-negotiation use-case.) It can easily be extended to address that, of course. (For example, by adding a @res attribute.) If you did this, though, then you're back to two equally-powerful syntaxes, and choosing one or the other based on personal taste. This is what we *did* end up with, in reality, and @srcset was chosen there. Especially since it seems that we can extend Tim's timeline with: 7. Authors react negatively to the addition of 'srcset' in the draft. 8. The 'living' draft is not changed and the authors' anger eventually fades into hopeless acceptance because once something goes in to the draft, it is set in stone forever and for all time. As far as I can tell, the majority of the anger over @srcset was due to bad initial information. A lot of people thought at first that @srcset was less functional than picture, and didn't understand the functionality that it did present. Once all that misunderstanding was cleared up (due to threads like this one), a lot of that anger evaporated as well. Now we're back to a much simpler I like syntax A instead of syntax B argument. ~TJ
Re: [whatwg] Correcting some misconceptions about Responsive Images
Well, if nothing else, I can certainly speak to the Community Group’s frustration on this subject — and to a lesser extent, the development community in general. However, it still looks like the most upsetting implication of his timeline, namely that the WHATWG is prioritizing implementors over authors, remains unclarified. Is it a misconception to say that the levels of priority outlined in the W3C HTML design principles [4] are not being followed here? Especially since it seems that we can extend Tim's timeline with: 7. Authors react negatively to the addition of 'srcset' in the draft. For myself at least, much of the frustration came from an eagerness to work with the WHATWG on solving this issue only to be met with sentiment to the tune of “that’s okay; we’ve pretty much solved this already.” `srcset` went from an initial proposal to addition to the draft within a handful of days, during which time we were told that we hadn’t followed the proper processes for proposing `picture`, and were lacking for proof, citations, and documentation. We were asked to furnish use cases, polyfills, a more formal proposal, and proof of developer sentiment on their preferred markup pattern. While we we working to provide these, `srcset` went from http://junkyard.damowmow.com/507 to a draft based largely on conversation in the IRC channel. Speaking for myself, one can’t help but feel as though we were given a separate set of rules and a process of our own. During this time, the most common argument was that some variation of `srcset`—or simply forgoing media queries altogether—would be easier for implementors, and that the `picture` markup contained too many characters. Where there’s no shortage of evidence that authors prefer the more verbose syntax, well, we were left with only one initial conclusion. 8. The 'living' draft is not changed and the authors' anger eventually fades into hopeless acceptance because once something goes in to the draft, it is set in stone forever and for all time. I don’t think this is the case. The public has largely resigned this to “`srcset` is happening because the WHATWG said so,” for certain, and that doesn’t seem entirely false—but I don’t think “hopeless acceptance” is the situation at present. I’ve been off the grid for a few days, but as I catch up on the conversation it seems as though a number of the RICG’s members have been contributing to the incremental improvement of the `srcset` proposal. I’m all for it, of course, as the goal was never _this or that_ solution so much as a solution that covers our use cases in the most developer-friendly way possible—and above all else, a solution with the most benefit to users. The goal now—as ever—is the best possible solution. If we’re limited to `srcset`, then the goal is to make that as useful as possible. However, I’d be lying if I said it isn’t frustrating, feeling as though we’re all working from a forgone conclusion. Ok, so 8 is both hyperbolic and in the future, but a lot of people seem to think that this is where we are headed. Personally, I'm not angry about this and I'm willing to calmly listen to corrections, I'm just trying to wade through all the misinformation here. -Brenton Strine [1] http://timkadlec.com/2012/05/wtfwg/ [2] http://adactio.com/journal/5474/ [3] http://www.goodreads.com/author_blog_posts/2463167-secret-src [4] http://www.w3.org/TR/html-design-principles/
Re: [whatwg] Correcting some misconceptions about Responsive Images
I don't wish to get into he said/she said discussions, but your email contains some incorrect characterizations. The mailing list contains all the relevant history of the discussion for anyone wishing to verify it for themselves. On Mon, May 21, 2012 at 5:05 PM, Mathew Marquis m...@matmarquis.com wrote: Well, if nothing else, I can certainly speak to the Community Group’s frustration on this subject — and to a lesser extent, the development community in general. However, it still looks like the most upsetting implication of his timeline, namely that the WHATWG is prioritizing implementors over authors, remains unclarified. Is it a misconception to say that the levels of priority outlined in the W3C HTML design principles [4] are not being followed here? Especially since it seems that we can extend Tim's timeline with: 7. Authors react negatively to the addition of 'srcset' in the draft. For myself at least, much of the frustration came from an eagerness to work with the WHATWG on solving this issue only to be met with sentiment to the tune of “that’s okay; we’ve pretty much solved this already.” `srcset` went from an initial proposal to addition to the draft within a handful of days, during which time we were told that we hadn’t followed the proper processes for proposing `picture`, and were lacking for proof, citations, and documentation. We were asked to furnish use cases, polyfills, a more formal proposal, and proof of developer sentiment on their preferred markup pattern. While we we working to provide these, `srcset` went from http://junkyard.damowmow.com/507 to a draft based largely on conversation in the IRC channel. Speaking for myself, one can’t help but feel as though we were given a separate set of rules and a process of our own. I think the majority of this was some confusing argumentation in the IRC channel. Don't take that anything official - a lot of the people in the channel that were talking about this weren't very familiar with the CG's work. *Some* were quite familiar, particularly Hixie, who used the CG's work in defining use-cases to inform the eventual design of the feature. During this time, the most common argument was that some variation of `srcset`—or simply forgoing media queries altogether—would be easier for implementors, and that the `picture` markup contained too many characters. Where there’s no shortage of evidence that authors prefer the more verbose syntax, well, we were left with only one initial conclusion. This is a mischaracterization. Using MQ instead of the @srcset microsyntax is not easier or harder for implementors. However, using MQ is *impossible* for solving some of the use-cases, as I explain in my blog post at http://www.xanthir.com/blog/b4Hv0. The initial picture proposal, which only used MQs, thus couldn't be used directly. The verbosity argument is very relevant when choosing a solution to put into HTML. For example, the verbosity of many existing DOM APIs is widely considered a design flaw - even something as relatively small as document.querySelector() versus document.find() is important. We should similarly consider this when designing HTML itself. A verbose solution can often seem okay at first sight, and only reveal how painful it is after being used for a while. 8. The 'living' draft is not changed and the authors' anger eventually fades into hopeless acceptance because once something goes in to the draft, it is set in stone forever and for all time. I don’t think this is the case. The public has largely resigned this to “`srcset` is happening because the WHATWG said so,” for certain, and that doesn’t seem entirely false—but I don’t think “hopeless acceptance” is the situation at present. I’ve been off the grid for a few days, but as I catch up on the conversation it seems as though a number of the RICG’s members have been contributing to the incremental improvement of the `srcset` proposal. I’m all for it, of course, as the goal was never _this or that_ solution so much as a solution that covers our use cases in the most developer-friendly way possible—and above all else, a solution with the most benefit to users. The goal now—as ever—is the best possible solution. If we’re limited to `srcset`, then the goal is to make that as useful as possible. However, I’d be lying if I said it isn’t frustrating, feeling as though we’re all working from a forgone conclusion. It's unfortunate that there was an expectation set early in the RICG that their purpose was to produce spec-ready text to be included into HTML. Hopefully we'll do a better job in the future communicating that what's necessary is use-cases to design a feature around, so we don't run into similar expectation mismatches. ~TJ
Re: [whatwg] Correcting some misconceptions about Responsive Images
I don’t think this is the case. The public has largely resigned this to “`srcset` is happening because the WHATWG said so,” for certain, and that doesn’t seem entirely false—but I don’t think “hopeless acceptance” is the situation at present. I’ve been off the grid for a few days, but as I catch up on the conversation it seems as though a number of the RICG’s members have been contributing to the incremental improvement of the `srcset` proposal. I’m all for it, of course, as the goal was never _this or that_ solution so much as a solution that covers our use cases in the most developer-friendly way possible—and above all else, a solution with the most benefit to users. The goal now—as ever—is the best possible solution. If we’re limited to `srcset`, then the goal is to make that as useful as possible. However, I’d be lying if I said it isn’t frustrating, feeling as though we’re all working from a forgone conclusion. It's unfortunate that there was an expectation set early in the RICG that their purpose was to produce spec-ready text to be included into HTML. Hopefully we'll do a better job in the future communicating that what's necessary is use-cases to design a feature around, so we don't run into similar expectation mismatches. ~TJ You’re certainly right that it’s not worth bickering about, and I apologize if I came across that way. I only hope that “we’ll do a better job in the future” has no reflection on the current discussions — mis-matched processes are no reason to throw away useful data, after all, and the Community Group has no shortage of that.
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Mon, May 21, 2012 at 5:38 PM, Mathew Marquis m...@matmarquis.com wrote: I don’t think this is the case. The public has largely resigned this to “`srcset` is happening because the WHATWG said so,” for certain, and that doesn’t seem entirely false—but I don’t think “hopeless acceptance” is the situation at present. I’ve been off the grid for a few days, but as I catch up on the conversation it seems as though a number of the RICG’s members have been contributing to the incremental improvement of the `srcset` proposal. I’m all for it, of course, as the goal was never _this or that_ solution so much as a solution that covers our use cases in the most developer-friendly way possible—and above all else, a solution with the most benefit to users. The goal now—as ever—is the best possible solution. If we’re limited to `srcset`, then the goal is to make that as useful as possible. However, I’d be lying if I said it isn’t frustrating, feeling as though we’re all working from a forgone conclusion. It's unfortunate that there was an expectation set early in the RICG that their purpose was to produce spec-ready text to be included into HTML. Hopefully we'll do a better job in the future communicating that what's necessary is use-cases to design a feature around, so we don't run into similar expectation mismatches. ~TJ You’re certainly right that it’s not worth bickering about, and I apologize if I came across that way. I only hope that “we’ll do a better job in the future” has no reflection on the current discussions — mis-matched processes are no reason to throw away useful data, after all, and the Community Group has no shortage of that. Not at all. The current discussion, and the data produced by the work preceding it, is indeed very useful. ~TJ
Re: [whatwg] Correcting some misconceptions about Responsive Images
Tab, Thanks for going to effort of providing some clear and detailed notes about this. I think the rest of the committee could learn from this account, and perhaps consider theres a lot more to communication than editing a live-spec and dumping it into the mailing list. On 22/05/2012, at 10:38 AM, Mathew Marquis wrote: I don’t think this is the case. The public has largely resigned this to “`srcset` is happening because the WHATWG said so,” for certain, and that doesn’t seem entirely false—but I don’t think “hopeless acceptance” is the situation at present. I’ve been off the grid for a few days, but as I catch up on the conversation it seems as though a number of the RICG’s members have been contributing to the incremental improvement of the `srcset` proposal. I’m all for it, of course, as the goal was never _this or that_ solution so much as a solution that covers our use cases in the most developer-friendly way possible—and above all else, a solution with the most benefit to users. The goal now—as ever—is the best possible solution. If we’re limited to `srcset`, then the goal is to make that as useful as possible. However, I’d be lying if I said it isn’t frustrating, feeling as though we’re all working from a forgone conclusion. It's unfortunate that there was an expectation set early in the RICG that their purpose was to produce spec-ready text to be included into HTML. Hopefully we'll do a better job in the future communicating that what's necessary is use-cases to design a feature around, so we don't run into similar expectation mismatches. ~TJ You’re certainly right that it’s not worth bickering about, and I apologize if I came across that way. I only hope that “we’ll do a better job in the future” has no reflection on the current discussions — mis-matched processes are no reason to throw away useful data, after all, and the Community Group has no shortage of that.
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Fri, 18 May 2012 01:16:52 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: I believe the CG rules would not allow an employee of a W3C Member company to be a free agent though. It appears not. I tried to join the responsive images CG as just me as I'm interested, but not representing Opera, and don't like to give people the impression that my interest or support of any suggestion means Opera will implement it next Thursday. But I couldn't; I had to join as an Opera rep, and get permission internally. That's time-consuming and process laden.
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Fri, May 18, 2012 at 6:01 PM, Bruce Lawson bru...@opera.com wrote: On Fri, 18 May 2012 01:16:52 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: I believe the CG rules would not allow an employee of a W3C Member company to be a free agent though. It appears not. I tried to join the responsive images CG as just me as I'm interested, but not representing Opera, and don't like to give people the impression that my interest or support of any suggestion means Opera will implement it next Thursday. But I couldn't; I had to join as an Opera rep, and get permission internally. That's time-consuming and process laden. I believe that is the case for all participation in the W3C. Unfortunately, I was not able to join a WG as a private invited expert and a different one as a Google representative (in my role as a Google contractor). I think that is a problem at the W3C that they don't allow you to have multiple different forms of representation per person. I even tried with different email addresses and that wasn't allowed either. Silvia.
Re: [whatwg] Correcting some misconceptions about Responsive Images
On May 16, 2012, at 10:39 PM, Jonas Sicking jo...@sicking.cc wrote: I agree that there's no obligation. And I agree that if people here didn't know about the existence of the CG then of course it's not surprising that we didn't engage with the work that was happening there. However I was under the impression that that wasn't the situation here. So while I agree that there was no obligation, it also doesn't seem surprising to me that the people in the CG were unhappy/upset with the resulting outcome. I didn't know about the respimg CG until a few days ago (after a couple of days of discussion of responsive image proposals, and months after Ted first posted his image-set proposal to www-style). Checking after the fact, I could find no mention of the term respimg or anything else uniquely identifying the community group in the archives of wha...@whatwg.org or public-html, and no one from the CG that I asked had a recollection of announcing it here. That's the basis for my assumption that most people here didn't know about the CG while it was working on its proposal. Do you have a basis for assuming otherwise? REgards, Maciej
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Wed, 16 May 2012, Glenn Maynard wrote: On Wed, May 16, 2012 at 8:35 PM, Maciej Stachowiak m...@apple.com wrote: The downside of the CG as executed is that it was much less successful in attracting browser implementor feedback (in part because it was apparently not advertised in places frequented by browser standards people). So the implementor feedback only got applied later, and without full knowledge and understanding of the CGs efforts. It's not useful to have a standards process that doesn't include all the essential stakeholders. This isn't a new suggestion, but worth repeating: starting a CG is fine, but *do not make a new mailing list*. Hold discussions on a related monolithic list (like here or webapps), with a subject line prefix. Making lots of isolated mailing lists only ensures that the people you'd want paying attention won't be, because the overhead of subscribing to a list (for a subject people may only have passive interest in) is much higher than skimming a thread on whatwg or webapps-public that people are already on. FWIW I think that forming community groups that are limited in scope to gathering and distilling the relevant use cases could be a functional way of working. For example if, in this case, people had said we will form a group that will spend 4 weeks documenting and prioritising all the use cases that a responsive images feature needs to cover and then the results of that work had been taken to a forum where browser implementors are engaged (e.g. WHATWG), I think we would have had a relatively smooth ride toward a universially acceptable solution. Of course there are disadvantages to this fragmentary approach compared to having one centralised venue, but it has the advantages too; notably people are more likely to subscribe to a low-traffic mailing list that just covers one feature they care about then subscribe to the WHATWG firehose. It also wouldn't require the unscalable solution of having vendors subscribe to one list per feature (fragmentation in this direction is already a huge problem at e.g. W3C and means that obvious problems with specs get missed until late in the game because people with the right expertise aren't subscribed to the correct lists).
Re: [whatwg] Correcting some misconceptions about Responsive Images
Non announcement _here_ is one thing, sure; but as those aiming to plan, test and measure different approaches, it's your role to research other developments out side of the WHATWG bubble. WHATWG does not exist to be a closed society. On 17/05/2012, at 6:46 PM, Maciej Stachowiak m...@apple.com wrote: On May 16, 2012, at 10:39 PM, Jonas Sicking jo...@sicking.cc wrote: I agree that there's no obligation. And I agree that if people here didn't know about the existence of the CG then of course it's not surprising that we didn't engage with the work that was happening there. However I was under the impression that that wasn't the situation here. So while I agree that there was no obligation, it also doesn't seem surprising to me that the people in the CG were unhappy/upset with the resulting outcome. I didn't know about the respimg CG until a few days ago (after a couple of days of discussion of responsive image proposals, and months after Ted first posted his image-set proposal to www-style). Checking after the fact, I could find no mention of the term respimg or anything else uniquely identifying the community group in the archives of wha...@whatwg.org or public-html, and no one from the CG that I asked had a recollection of announcing it here. That's the basis for my assumption that most people here didn't know about the CG while it was working on its proposal. Do you have a basis for assuming otherwise? REgards, Maciej
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Thu, May 17, 2012 at 4:32 AM, Ben Schwarz ben.schw...@gmail.com wrote: Non announcement _here_ is one thing, sure; but as those aiming to plan, test and measure different approaches, it's your role to research other developments out side of the WHATWG bubble. As you must know, the srcset design did take the other proposals into account; the picture proposal was rejected for clearly-stated reasons. That's not what we're talking about. WHATWG does not exist to be a closed society. (Is this a joke? This is probably the most open and approachable spec development community in existance today.) -- Glenn Maynard
Re: [whatwg] Correcting some misconceptions about Responsive Images
WHATWG does not exist to be a closed society. (Is this a joke? This is probably the most open and approachable spec development community in existance today.) This is probably the best square wheel there is today does not make it a good wheel, even if it's better than all the other square wheels. If there was only one thing taken from the RICG I'd hope that it was the observation that it got a *lot* more feedback from general authors than any of the mailing lists do. It's simply much easier to access and read than the mailing lists - it's not about the people running either group, it's about the medium it is in.
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Thu, May 17, 2012 at 2:18 AM, James Graham jgra...@opera.com wrote: FWIW I think that forming community groups that are limited in scope to gathering and distilling the relevant use cases could be a functional way of working. For example if, in this case, people had said we will form a group that will spend 4 weeks documenting and prioritising all the use cases that a responsive images feature needs to cover and then the results of that work had been taken to a forum where browser implementors are engaged (e.g. WHATWG), I think we would have had a relatively smooth ride toward a universially acceptable solution. Yup. This is basically what the CG *did*, in practice, and it was very useful. There was an unfortunate expectation that their goal was to write spec text that would be simply adopted into the spec, though. Making sure the expectations are clearer in the future would be a good move. ~TJ
Re: [whatwg] Correcting some misconceptions about Responsive Images
On 17 May 2012 16:07, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, May 17, 2012 at 2:18 AM, James Graham jgra...@opera.com wrote: FWIW I think that forming community groups that are limited in scope to gathering and distilling the relevant use cases could be a functional way of working. For example if, in this case, people had said we will form a group that will spend 4 weeks documenting and prioritising all the use cases that a responsive images feature needs to cover and then the results of that work had been taken to a forum where browser implementors are engaged (e.g. WHATWG), I think we would have had a relatively smooth ride toward a universially acceptable solution. While this is true in some form, in order to be useful we had to consider different approaches and get the feedback about those approaches. It wasn't just get use cases so much as get use cases, decide whether a pattern we are suggesting answers them, and then canvas authors to see if they actually understand it and react well to it?. If the WHATWG are not willing to join CG's in order to give their input then the route would effectively end up being: 1) Spin off a CG to gather use cases 2) grab info and apply back to WHATWG mail list 3) WHATWG mail list decides on possible approaches 4) Spin the approaches off to CG and gather wider feedback 5) goto 2 I don't mind that approach, but the problem is once you involve a wider community you *will* get that community discussing technical stuff there - divorced from the WHATWG members. The fact of the matter is that the wider public find a website in the format of the CG far easier to access and engage than mail lists. That's neither a good or bad thing, it just is. How it should be managed is where it gets difficult. Yup. This is basically what the CG *did*, in practice, and it was very useful. There was an unfortunate expectation that their goal was to write spec text that would be simply adopted into the spec, though. Making sure the expectations are clearer in the future would be a good move. That would have been a hugely beneficial thing. ~TJ
Re: [whatwg] Correcting some misconceptions about Responsive Images
As a UA implementor, this seem to me to be purely a success story for the single reason that it drew so much developer participation. Regardless of what makes it into the spec, the worst possible outcome would be if the developer community learned the lesson that UA implementors are hostile to/dismissive of their problems, ideas and solutions. It seems to me like there's a problem of walking a mile in someone else's shoes in both directions, but ultimately developers are our customers -- not vice versa. If it's required for either camp to go the extra mile to accomodate the other -- it seems to me that it ought to be us. On Thu, May 17, 2012 at 8:07 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, May 17, 2012 at 2:18 AM, James Graham jgra...@opera.com wrote: FWIW I think that forming community groups that are limited in scope to gathering and distilling the relevant use cases could be a functional way of working. For example if, in this case, people had said we will form a group that will spend 4 weeks documenting and prioritising all the use cases that a responsive images feature needs to cover and then the results of that work had been taken to a forum where browser implementors are engaged (e.g. WHATWG), I think we would have had a relatively smooth ride toward a universially acceptable solution. Yup. This is basically what the CG *did*, in practice, and it was very useful. There was an unfortunate expectation that their goal was to write spec text that would be simply adopted into the spec, though. Making sure the expectations are clearer in the future would be a good move. ~TJ
Re: [whatwg] Correcting some misconceptions about Responsive Images
On 17 May 2012 17:00, Rafael Weinstein rafa...@chromium.org wrote: As a UA implementor, this seem to me to be purely a success story for the single reason that it drew so much developer participation. Regardless of what makes it into the spec, the worst possible outcome would be if the developer community learned the lesson that UA implementors are hostile to/dismissive of their problems, ideas and solutions. It seems to me like there's a problem of walking a mile in someone else's shoes in both directions, but ultimately developers are our customers -- not vice versa. If it's required for either camp to go the extra mile to accomodate the other -- it seems to me that it ought to be us. It's been a series of unfortunate things to be honest. 1) First off many members of the CG have been working on the adaptive images problem for close to a year at this point. 2) When a few went to the mailing lists some months ago, we were met with the realisation that Hixie was not even aware there was a problem (at this point it had already had months of outspoken and loud attention in the wider community, including a few publications in major web sites and magazines). That the 'lead' of the WG was ignorant of the issue left a few of us incredulous. 3) Then because the mail lists are not friendly to newcomers members of the group were mis-directed to form a spin off group. 4) Then the more recent communication fiasco with regard to srcset and picture The problem of miscommunication and poorly documented newcomer-unfriendly channels is not new. The rub on this one is *just how much work* has been put into the subject - as I say, close to a year - and then the realisation of so much seemingly being a waste. Or at least not seen to be valued, used, or openly discussed by the WHATWG, before some other (apparently random, to us) idea got pushed forward. As I say, the CG have discussed all of this openly, published in prominant magazines, done our due diligence research into any number of existing solutions etc. To see srcset appear from the shrouded mists of the WG mailing list was a shock.
Re: [whatwg] Correcting some misconceptions about Responsive Images
It's easy to see how the experience you describe below would be frustrating. FWIW, I routinely feel frustration at seemingly wasted time. Unfortunately, it's inescapable that reaching consensus can be exhausting, especially via email -- and doing so always requires re-explaining the same thing multiple times in multiple ways. This is true for everyone. In fairness to Hixie -- being an editor is fairly thankless and he does a remarkable job of keeping up even just with whatwg, webapps and a few others (I gave up long ago). If you need someone to understand something, it's best to directly bring it to their attention. The internet is a big place =-). I agree with both Jonas and Maciej's points above about lessons for the future. It seems like the basic problem is that a feature which needs lots of work collecting use cases and developer feedback requires a setting which isn't intimidating for developers -- but ultimately, if it wants to land in a spec, it needs the perspective and experience of implementors and editors. A few humble thoughts -Have the CG recruit an experienced implementor or editor to participate more or less from the beginning. This may short-circuit time spent on solutions that won't work for esoteric reasons, and there will be at least one person with one foot in both worlds. -Cross-post significant outputs decisions to whatwg, public-webapps, etc... E.g. collected use cases, strawman proposals, recommendations, etc... Even with the help of an implementors/editor, the ideas that survive are those that withstand the scrutiny of the entire community and getting that scrutiny early is nearly always better. On Thu, May 17, 2012 at 9:18 AM, Matthew Wilcox m...@matthewwilcox.com wrote: On 17 May 2012 17:00, Rafael Weinstein rafa...@chromium.org wrote: As a UA implementor, this seem to me to be purely a success story for the single reason that it drew so much developer participation. Regardless of what makes it into the spec, the worst possible outcome would be if the developer community learned the lesson that UA implementors are hostile to/dismissive of their problems, ideas and solutions. It seems to me like there's a problem of walking a mile in someone else's shoes in both directions, but ultimately developers are our customers -- not vice versa. If it's required for either camp to go the extra mile to accomodate the other -- it seems to me that it ought to be us. It's been a series of unfortunate things to be honest. 1) First off many members of the CG have been working on the adaptive images problem for close to a year at this point. 2) When a few went to the mailing lists some months ago, we were met with the realisation that Hixie was not even aware there was a problem (at this point it had already had months of outspoken and loud attention in the wider community, including a few publications in major web sites and magazines). That the 'lead' of the WG was ignorant of the issue left a few of us incredulous. 3) Then because the mail lists are not friendly to newcomers members of the group were mis-directed to form a spin off group. 4) Then the more recent communication fiasco with regard to srcset and picture The problem of miscommunication and poorly documented newcomer-unfriendly channels is not new. The rub on this one is *just how much work* has been put into the subject - as I say, close to a year - and then the realisation of so much seemingly being a waste. Or at least not seen to be valued, used, or openly discussed by the WHATWG, before some other (apparently random, to us) idea got pushed forward. As I say, the CG have discussed all of this openly, published in prominant magazines, done our due diligence research into any number of existing solutions etc. To see srcset appear from the shrouded mists of the WG mailing list was a shock.
Re: [whatwg] Correcting some misconceptions about Responsive Images
On 17 May 2012 18:49, Rafael Weinstein rafa...@chromium.org wrote: It's easy to see how the experience you describe below would be frustrating. FWIW, I routinely feel frustration at seemingly wasted time. Unfortunately, it's inescapable that reaching consensus can be exhausting, especially via email -- and doing so always requires re-explaining the same thing multiple times in multiple ways. This is true for everyone. Agreed, there will always be an element of this - although in the case of the CG this got to the point that we addressed it with a FAQ page. That helped us and people visiting. It didn't seem to help the WG, for whatever reason? In fairness to Hixie -- being an editor is fairly thankless and he does a remarkable job of keeping up even just with whatwg, webapps and a few others (I gave up long ago). If you need someone to understand something, it's best to directly bring it to their attention. The internet is a big place =-). I can see both sides of this. When you're busy, you're busy, and Hixie is busy. On the other hand, this was a long drawn out multi-month problem that was talked about quite literally everywhere. It's the fact that the scope of awareness everywhere else was so large that makes it so surprising it was missed in the one group that it ought to have been forefront of that subject. I agree with both Jonas and Maciej's points above about lessons for the future. It seems like the basic problem is that a feature which needs lots of work collecting use cases and developer feedback requires a setting which isn't intimidating for developers -- but ultimately, if it wants to land in a spec, it needs the perspective and experience of implementors and editors. I think we all agree on that :) A few humble thoughts -Have the CG recruit an experienced implementor or editor to participate more or less from the beginning. This may short-circuit time spent on solutions that won't work for esoteric reasons, and there will be at least one person with one foot in both worlds. This would be awesome. -Cross-post significant outputs decisions to whatwg, public-webapps, etc... E.g. collected use cases, strawman proposals, recommendations, etc... Even with the help of an implementors/editor, the ideas that survive are those that withstand the scrutiny of the entire community and getting that scrutiny early is nearly always better. Cross posting is always risky. If the items under discussion are still maliable then what happens is two discussions break out between two lots of un-related groups and things get messy. I'd be up for this route only if it was very clear of the role of each party, and lines could be drawn that properly segment the discussions. i.e., 1) CG: We have collected enough use cases from a wide spread of authors; we are now presenting this back to the WHATWG - if you wish to follow along with possible solutions, please take part there 2) WG: discusses possible solutions and *whenever* there is doubt about what an author would prefer to do or what they will understand, it gets bounced back to the CG 3) CG: present the WG's dilema in a succinct way that presumes no prior knowledge, and solicit feedback from authors outside of the WG list, which is then fed back to the WG. 4) WG: makes decisions based on that feedback. That to me would work best for both communities.
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Thu, May 17, 2012 at 11:12 AM, Matthew Wilcox m...@matthewwilcox.com wrote: A few humble thoughts -Have the CG recruit an experienced implementor or editor to participate more or less from the beginning. This may short-circuit time spent on solutions that won't work for esoteric reasons, and there will be at least one person with one foot in both worlds. This would be awesome. FWIW, I wanted to do this, but Google's policy of having us talk to the patents guys before joining CGs turned me off from actually joining. So, I just followed from the side and couldn't interact enough. :/ ~TJ
Re: [whatwg] Correcting some misconceptions about Responsive Images
On 17 May 2012 19:15, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, May 17, 2012 at 11:12 AM, Matthew Wilcox m...@matthewwilcox.com wrote: A few humble thoughts -Have the CG recruit an experienced implementor or editor to participate more or less from the beginning. This may short-circuit time spent on solutions that won't work for esoteric reasons, and there will be at least one person with one foot in both worlds. This would be awesome. FWIW, I wanted to do this, but Google's policy of having us talk to the patents guys before joining CGs turned me off from actually joining. So, I just followed from the side and couldn't interact enough. :/ Is this something that Google might be willing to bend somewhat? I.e., when you're on the CG you're a free-agent and not representing Google? Or, for the sake of politics, could it be worked around in that instead of joining the CG you keep track of things via the RSS feed (it is after all public) and post to the WHATWG mailing list with observations every once in a while - as long as core CG members know to keep an eye out that's not necessarily a huge problem. I dunno, politics complicates stuff. And patenting open-web stuff to me seems wrong on any number of levels.
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Thu, May 17, 2012 at 11:12 AM, Matthew Wilcox m...@matthewwilcox.com wrote: On 17 May 2012 18:49, Rafael Weinstein rafa...@chromium.org wrote: It's easy to see how the experience you describe below would be frustrating. FWIW, I routinely feel frustration at seemingly wasted time. Unfortunately, it's inescapable that reaching consensus can be exhausting, especially via email -- and doing so always requires re-explaining the same thing multiple times in multiple ways. This is true for everyone. Agreed, there will always be an element of this - although in the case of the CG this got to the point that we addressed it with a FAQ page. That helped us and people visiting. It didn't seem to help the WG, for whatever reason? In fairness to Hixie -- being an editor is fairly thankless and he does a remarkable job of keeping up even just with whatwg, webapps and a few others (I gave up long ago). If you need someone to understand something, it's best to directly bring it to their attention. The internet is a big place =-). I can see both sides of this. When you're busy, you're busy, and Hixie is busy. On the other hand, this was a long drawn out multi-month problem that was talked about quite literally everywhere. It's the fact that the scope of awareness everywhere else was so large that makes it so surprising it was missed in the one group that it ought to have been forefront of that subject. I agree with both Jonas and Maciej's points above about lessons for the future. It seems like the basic problem is that a feature which needs lots of work collecting use cases and developer feedback requires a setting which isn't intimidating for developers -- but ultimately, if it wants to land in a spec, it needs the perspective and experience of implementors and editors. I think we all agree on that :) A few humble thoughts -Have the CG recruit an experienced implementor or editor to participate more or less from the beginning. This may short-circuit time spent on solutions that won't work for esoteric reasons, and there will be at least one person with one foot in both worlds. This would be awesome. -Cross-post significant outputs decisions to whatwg, public-webapps, etc... E.g. collected use cases, strawman proposals, recommendations, etc... Even with the help of an implementors/editor, the ideas that survive are those that withstand the scrutiny of the entire community and getting that scrutiny early is nearly always better. Cross posting is always risky. If the items under discussion are still maliable then what happens is two discussions break out between two lots of un-related groups and things get messy. I'd be up for this route only if it was very clear of the role of each party, and lines could be drawn that properly segment the discussions. i.e., 1) CG: We have collected enough use cases from a wide spread of authors; we are now presenting this back to the WHATWG - if you wish to follow along with possible solutions, please take part there 2) WG: discusses possible solutions and *whenever* there is doubt about what an author would prefer to do or what they will understand, it gets bounced back to the CG 3) CG: present the WG's dilema in a succinct way that presumes no prior knowledge, and solicit feedback from authors outside of the WG list, which is then fed back to the WG. 4) WG: makes decisions based on that feedback. That to me would work best for both communities. I think the sentiment behind these to good, but I'd caution against relying on process and specified roles. The goal here shouldn't be to slice up areas of responsibility -- that seems likely to contribute to -- not mitigate -- people digging in their heels. It's a good feature that anyone can wear whatever hat they like. My observation is that when good stuff happens, it's because a set of people dedicate themselves dispassionately to doing whatever required to pursue a good outcome -- not because of any formal process which is ultimately unenforceable.
Re: [whatwg] Correcting some misconceptions about Responsive Images
On May 17, 2012, at 11:20 AM, Matthew Wilcox m...@matthewwilcox.com wrote: On 17 May 2012 19:15, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, May 17, 2012 at 11:12 AM, Matthew Wilcox m...@matthewwilcox.com wrote: A few humble thoughts -Have the CG recruit an experienced implementor or editor to participate more or less from the beginning. This may short-circuit time spent on solutions that won't work for esoteric reasons, and there will be at least one person with one foot in both worlds. This would be awesome. FWIW, I wanted to do this, but Google's policy of having us talk to the patents guys before joining CGs turned me off from actually joining. So, I just followed from the side and couldn't interact enough. :/ Is this something that Google might be willing to bend somewhat? I.e., when you're on the CG you're a free-agent and not representing Google? Or, for the sake of politics, could it be worked around in that instead of joining the CG you keep track of things via the RSS feed (it is after all public) and post to the WHATWG mailing list with observations every once in a while - as long as core CG members know to keep an eye out that's not necessarily a huge problem. I dunno, politics complicates stuff. And patenting open-web stuff to me seems wrong on any number of levels. CGs actually have very little patent obligation compared to W3C Working Groups, so Apple has lighter weight approval for those than for WGs. Perhaps Google could consider the same thing. I believe the CG rules would not allow an employee of a W3C Member company to be a free agent though. - Maciej
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Thu, May 17, 2012 at 12:12 PM, Maciej Stachowiak m...@apple.com wrote: CGs actually have very little patent obligation compared to W3C Working Groups, so Apple has lighter weight approval for those than for WGs. Perhaps Google could consider the same thing. I believe the CG rules would not allow an employee of a W3C Member company to be a free agent though. I can't speak for our lawyers, but I do plan to complain about the situation internally. It adds a pretty tremendous mental transaction cost to me joining a CG, and that's unfortunate. ~TJ
[whatwg] Correcting some misconceptions about Responsive Images
I've been doing a lot of work today correcting misconceptions about the Responsive Images proposal that Hixie put into the spec today. I was pretty astonished at how much misinformation was flying around; what's worse, this sort of misinformation was actually making people *angry*, which doesn't exactly make people willing to calmly listen to corrections. So, hopefully this email finds everyone in calmer moods, so we can get everyone on the same page. 1. The Responsive Images CG was completely ignored. I keep hearing this, and it's pretty annoying. The responsive images thing is a complete success story by any objective account: some people initially brought up an idea, it was rejected, they went away for a bit and developed the use-cases more fully, the idea was accepted and made it into the spec. That's *precisely* how the process should work - everything came up roses here. The CG's work on elucidating use-cases better was *invaluable* here. The current solution in the spec isn't precisely the same as what the CG proposed. That's perfectly normal; the CG wasn't paying attention to an important use-case (they either weren't paying attention to resolution, or thought that device-pixel-ratio or a hypothetical bandwidth media query would suffice, neither of which is true). If this sort of thing disillusions you, stay away from standards. ^_^ Having your ideas mutated into forms you didn't anticipate is commonplace, as others point out cases you missed and suggest easier or more elegant variants. It's probably good to learn early if you're not cool with this sort of thing - a *lot* of people don't have the right kind of patience to suffer through standards work. 2. @srcset doesn't solve all the use-cases. Yes, it does. There are currently two major classes of use-cases. The first is what the CG mostly focused on, which is varying the image you deliver based on breakpoints in your layout. This is handled by the NNNw and NNNh parts of the microsyntax - they specify that the image should only be used if the viewport is at least a certain width or height. This is almost the same thing as the min-width and min-height Media Queries, except it has better fallback behavior for when nothing matches. The second major class is serving the same image, but in different resolutions based on the device's pixel density. This is more complex than it sounds (see http://www.xanthir.com/blog/b4Hv0 ), but @srcset solves it pretty simply with the Nx part of the microsyntax, which tells the browser the resolution of the image. Browsers can handle all the complications themselves. 3. @srcset doesn't have good fallback behavior. Yup, it does. The simplest way is to just do the simplest thing: provide both a @src and a @srcset, and that's it. This has good behavior in legacy UAs, and in new ones. The only downside of this is that if you're polyfilling the feature in legacy UAs, you get two requests (first the @src, then whatever the JS changes it to). If this is problematic, there's a more verbose but still simple way to handle this (afaik, first suggested by Odin): img src=data: srcset=foo.jpg 1x, foo2.jpg 2x style=display:none;noscriptimg src=foo.jpg/noscript In modern UAs, JS just has to remove the @style. In legacy UAs, JS removes the @style and sets the @src appropriately (the data: url ensures that there's not an extra request before JS activates). If JS isn't turned on, the first image just never displays, but the second one does. This is more complicated and a bit more fragile than the previous solution, but it only ever sends a single request. Any others that people can think of? ~TJ
Re: [whatwg] Correcting some misconceptions about Responsive Images
img src=data: srcset=foo.jpg 1x, foo2.jpg 2x style=display:none;noscriptimg src=foo.jpg/noscript So we praise the terse syntax of it and then offer a NOSCRIPT for backwards compatibility? Now that is a real step back in my opinion.
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Wed, 16 May 2012 09:42:46 +0200, Chris Heilmann code...@gmail.com wrote: img src=data: srcset=foo.jpg 1x, foo2.jpg 2x style=display:none;noscriptimg src=foo.jpg/noscript So we praise the terse syntax of it and then offer a NOSCRIPT for backwards compatibility? Now that is a real step back in my opinion. Please, read Tab's full email. No need to willfully mislead people just to create a flame war like this. You know as well as we do as that the backwards compat story is: img src=foo.jpg srcset=foo.jpg 2x Extra noscript is only for a *Javascript* polyfill that will give you the behavior in current browsers. That means, only those who absolutely want switching to work with browsers not having implemented it, should use something like this. In fact, polyfilling other solutions will require the exact same, because you'd have to cater for people having Javascript turned off. However, you can also polyfill the simple version, but you would get two requests in some browsers if you do that. So you can optimize what you want. The only thing we're talking about -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Correcting some misconceptions about Responsive Images
Am 16.05.2012 um 09:13 schrieb Tab Atkins Jr.: I've been doing a lot of work today correcting misconceptions about the Responsive Images proposal that Hixie put into the spec today. I was pretty astonished at how much misinformation was flying around; what's worse, this sort of misinformation was actually making people *angry*, which doesn't exactly make people willing to calmly listen to corrections. So, hopefully this email finds everyone in calmer moods, so we can get everyone on the same page. Thanks for doing this effort it is really needed when I today saw some nasty conversations on twitter. I don't like the way (mis)communication had gone but we should not fight verbal at all about such topics. 1. The Responsive Images CG was completely ignored. I keep hearing this, and it's pretty annoying. The responsive images thing is a complete success story by any objective account: some people initially brought up an idea, it was rejected, they went away for a bit and developed the use-cases more fully, the idea was accepted and made it into the spec. That's *precisely* how the process should work - everything came up roses here. The CG's work on elucidating use-cases better was *invaluable* here. I was one of them saying that. I do not know who read the whole story of our way to the picture element but for me it still seems that there are none here in the mailing-list except Mat etc. I will come back to it later… The current solution in the spec isn't precisely the same as what the CG proposed. That's perfectly normal; the CG wasn't paying attention to an important use-case (they either weren't paying attention to resolution, or thought that device-pixel-ratio or a hypothetical bandwidth media query would suffice, neither of which is true). If this sort of thing disillusions you, stay away from standards. ^_^ Having your ideas mutated into forms you didn't anticipate is commonplace, as others point out cases you missed and suggest easier or more elegant variants. It's probably good to learn early if you're not cool with this sort of thing - a *lot* of people don't have the right kind of patience to suffer through standards work. Here we go. It seems many have scan and skimmed the CGs topics but no one read carefully the discussions. Of course we had the topics about bandwidth, browser's behavior on detecting and managing the MQ in the syntax. Also resolutions and other things were actually discussed. And that is my biggest concern: If important people would have read the CGs discussions (which IMO they have the responsibility if they are in the role to set up a new spec) they would have known many more use-cases, problems than they actually do. When we look at the topics going around here in mailing list, many many of them were already discussed in the CG. And I several times informed important people (I thought they were) that they should talk to the browser vendors (they are working for them!) about our problems, concerns and proposals. They never did or at least we never got a reply. I think the WHATWG should respect the W3C with its community groups more. Or what are they for? I mean we invested many hours of work into the topics and now we have to explain and discuss all again (sure with new valid arguments). This is sad and should be done better (maybe by both sides) next time… 2. @srcset doesn't solve all the use-cases. Yes, it does. There are currently two major classes of use-cases. The first is what the CG mostly focused on, which is varying the image you deliver based on breakpoints in your layout. This is handled by the NNNw and NNNh parts of the microsyntax - they specify that the image should only be used if the viewport is at least a certain width or height. This is almost the same thing as the min-width and min-height Media Queries, except it has better fallback behavior for when nothing matches. Surely it does. But I think the biggest problem is that the micro-syntax is not developer-friendly (for the masses). At least this is my only problem with the solution. The second major class is serving the same image, but in different resolutions based on the device's pixel density. This is more complex than it sounds (see http://www.xanthir.com/blog/b4Hv0 ), but @srcset solves it pretty simply with the Nx part of the microsyntax, which tells the browser the resolution of the image. Browsers can handle all the complications themselves. 3. @srcset doesn't have good fallback behavior. Yup, it does. The simplest way is to just do the simplest thing: provide both a @src and a @srcset, and that's it. This has good behavior in legacy UAs, and in new ones. The only downside of this is that if you're polyfilling the feature in legacy UAs, you get two requests (first the @src, then whatever the JS changes it to). If this is problematic, there's a more verbose but still simple way to handle this (afaik, first
Re: [whatwg] Correcting some misconceptions about Responsive Images
Thank you for the well written email. On Wed, 16 May 2012 09:13:01 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: 3. @srcset doesn't have good fallback behavior. Yup, it does. The simplest way is to just do the simplest thing: provide both a @src and a @srcset, and that's it. This has good behavior in legacy UAs, and in new ones. The only downside of this is that if you're polyfilling the feature in legacy UAs, you get two requests (first the @src, then whatever the JS changes it to). If this is problematic, there's a more verbose but still simple way to handle this (afaik, first suggested by Odin): img src=data: srcset=foo.jpg 1x, foo2.jpg 2x style=display:none;noscriptimg src=foo.jpg/noscript It was not first suggested by me, I shopped around in the RespImg CG and on different blogs and comments and articles and picked that up somewhere along the path. I think Scott Jehl's Some early thoughts on img@srcset in the real world might be the first place I saw it: https://gist.github.com/2701939 Although he said something to the effect that plausible, but may have some issues. Hence my proof of concept *demo* of a srcset polyfill that optimizes for few requests: http://odin.s0.no/web/srcset/polyfill.htm To show that it can work. The example I'm using is: img srcset=small.png 500w, big.png 1000w style=display:none noscriptimg src=small.png alt=Alt here/noscript It'll work without javascript, only showing one alt text. With javascript on, it'll copy the alt text to the real img and take away the display:none (which is only there to hinder IE showing a broken image icon when you have no Javascript). In modern UAs, JS just has to remove the @style. In legacy UAs, JS removes the @style and sets the @src appropriately (the data: url ensures that there's not an extra request before JS activates). If JS isn't turned on, the first image just never displays, but the second one does. This is more complicated and a bit more fragile than the previous solution, but it only ever sends a single request. Yes. I have a live test for something like that. It works in all devices and browsers I've got access to. Which is not really very much, but should cater for quite a large part of the internet. (:P) It's at the same page ( http://odin.s0.no/web/srcset/polyfill.htm ). -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Wed, May 16, 2012 at 12:13 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: I've been doing a lot of work today correcting misconceptions about the Responsive Images proposal that Hixie put into the spec today. I was pretty astonished at how much misinformation was flying around; what's worse, this sort of misinformation was actually making people *angry*, which doesn't exactly make people willing to calmly listen to corrections. So, hopefully this email finds everyone in calmer moods, so we can get everyone on the same page. 1. The Responsive Images CG was completely ignored. I keep hearing this, and it's pretty annoying. The responsive images thing is a complete success story by any objective account: some people initially brought up an idea, it was rejected, they went away for a bit and developed the use-cases more fully, the idea was accepted and made it into the spec. That's *precisely* how the process should work - everything came up roses here. The CG's work on elucidating use-cases better was *invaluable* here. The current solution in the spec isn't precisely the same as what the CG proposed. That's perfectly normal; the CG wasn't paying attention to an important use-case (they either weren't paying attention to resolution, or thought that device-pixel-ratio or a hypothetical bandwidth media query would suffice, neither of which is true). If this sort of thing disillusions you, stay away from standards. ^_^ Having your ideas mutated into forms you didn't anticipate is commonplace, as others point out cases you missed and suggest easier or more elegant variants. It's probably good to learn early if you're not cool with this sort of thing - a *lot* of people don't have the right kind of patience to suffer through standards work. I haven't been part of the discussion neither in the CG or in here, so I won't express strong opinions since I can very easily have misunderstood things. However, it seems to me that if a lot of discussion had happened in the CG, especially with a lot of expertize there around what authors want, then why put a proposal that goes against theirs into the HTML spec and announce this on the whatwg list? If their proposal wasn't deemed good enough, then the most appropriate action would seem to be engage in discussion in that CG and point out why their proposal is problematic! Simply reading their input and putting a different proposal into the spec is remeniscent of how various W3C groups work where they take input on their public list, then discuss amongst themselves on a private list and put what they thought was the best solution into the spec. That behavior has led to plenty of bad specifications and is something we've campaigned heavily against. Instead we've requested that all discussions happen on the same list so that everyone can participate. (The difference that the w3c lists were private is not really a meaningful difference if we're telling people to join CGs and do development there). Apologies if this did actually happen and I missed it. / Jonas
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Wed, May 16, 2012 at 1:59 PM, Anne van Kesteren ann...@annevk.nl wrote: I just wanted to correct one small thing here. On Wed, May 16, 2012 at 10:51 PM, Jonas Sicking jo...@sicking.cc wrote: (The difference that the w3c lists were private is not really a meaningful difference if we're telling people to join CGs and do development there). We have not done that, but unfortunately nobody called out the bad suggestion either :-( http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0194.html I'm not sure what you think it's a bad suggestion? I would say that the CG was more successful in attracting author feedback than WhatWG currently is. / Jonas
Re: [whatwg] Correcting some misconceptions about Responsive Images
On May 16, 2012, at 4:53 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, May 16, 2012 at 1:59 PM, Anne van Kesteren ann...@annevk.nl wrote: I just wanted to correct one small thing here. On Wed, May 16, 2012 at 10:51 PM, Jonas Sicking jo...@sicking.cc wrote: (The difference that the w3c lists were private is not really a meaningful difference if we're telling people to join CGs and do development there). We have not done that, but unfortunately nobody called out the bad suggestion either :-( http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0194.html I'm not sure what you think it's a bad suggestion? I would say that the CG was more successful in attracting author feedback than WhatWG currently is. The downside of the CG as executed is that it was much less successful in attracting browser implementor feedback (in part because it was apparently not advertised in places frequented by browser standards people). So the implementor feedback only got applied later, and without full knowledge and understanding of the CGs efforts. It's not useful to have a standards process that doesn't include all the essential stakeholders. The most important point though is that no one from the WHATWG recommended creating a CG. Saying that the existence of the CG obligates people to respond there is not really scalable, the logical conclusion would be that HTML standards discussion has to be spread among all future newly created groups that try to do anything HTML-related, even ones not advertised in the existing places. I don't see how that is a reasonable policy. It would be like if I made my own mozilla-feature-planning list and then got mad at Mozilla folks for not replying there when making release plans. Regards, Maciej
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Wed, May 16, 2012 at 8:35 PM, Maciej Stachowiak m...@apple.com wrote: The downside of the CG as executed is that it was much less successful in attracting browser implementor feedback (in part because it was apparently not advertised in places frequented by browser standards people). So the implementor feedback only got applied later, and without full knowledge and understanding of the CGs efforts. It's not useful to have a standards process that doesn't include all the essential stakeholders. This isn't a new suggestion, but worth repeating: starting a CG is fine, but *do not make a new mailing list*. Hold discussions on a related monolithic list (like here or webapps), with a subject line prefix. Making lots of isolated mailing lists only ensures that the people you'd want paying attention won't be, because the overhead of subscribing to a list (for a subject people may only have passive interest in) is much higher than skimming a thread on whatwg or webapps-public that people are already on. Every time I see we've started a new CG, everyone subscribe to our list!, I cringe; the result here was predictable ( http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2012Apr/0011.html). -- Glenn Maynard
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Wed, May 16, 2012 at 6:35 PM, Maciej Stachowiak m...@apple.com wrote: On May 16, 2012, at 4:53 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, May 16, 2012 at 1:59 PM, Anne van Kesteren ann...@annevk.nl wrote: I just wanted to correct one small thing here. On Wed, May 16, 2012 at 10:51 PM, Jonas Sicking jo...@sicking.cc wrote: (The difference that the w3c lists were private is not really a meaningful difference if we're telling people to join CGs and do development there). We have not done that, but unfortunately nobody called out the bad suggestion either :-( http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Feb/0194.html I'm not sure what you think it's a bad suggestion? I would say that the CG was more successful in attracting author feedback than WhatWG currently is. The downside of the CG as executed is that it was much less successful in attracting browser implementor feedback (in part because it was apparently not advertised in places frequented by browser standards people). So the implementor feedback only got applied later, and without full knowledge and understanding of the CGs efforts. It's not useful to have a standards process that doesn't include all the essential stakeholders. The most important point though is that no one from the WHATWG recommended creating a CG. Saying that the existence of the CG obligates people to respond there is not really scalable, the logical conclusion would be that HTML standards discussion has to be spread among all future newly created groups that try to do anything HTML-related, even ones not advertised in the existing places. I don't see how that is a reasonable policy. It would be like if I made my own mozilla-feature-planning list and then got mad at Mozilla folks for not replying there when making release plans. I agree that there's no obligation. And I agree that if people here didn't know about the existence of the CG then of course it's not surprising that we didn't engage with the work that was happening there. However I was under the impression that that wasn't the situation here. So while I agree that there was no obligation, it also doesn't seem surprising to me that the people in the CG were unhappy/upset with the resulting outcome. / Jonas
