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.
