>> >> 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.