- From: Matthew Wilcox <mail@matthewwilcox.com>
- Date: Fri, 18 May 2012 23:11:45 +0100
- To: Kornel Lesiński <kornel@geekhood.net>
- Cc: whatwg@lists.whatwg.org
>>> Make no mistake; this is not a pride or attachment thing, this is a >>> knowing the reasons thing. I personally don't think <picture> answers >>> things well enough, nor do I think srcset does. Not for general use >>> cases - but for specific one-off use cases, each has benefits. >> >> >> Absolutely. And from what I read (and I admit not reading the entire >> archive of messages, but still, prefer to say my piece anyway) the >> main concern about picture was the potencial verbosity. Instead of >> trying to solve this issue, it got discarded. > > > <picture> in its current form is unable to support bandwidth-based > negotiation well By all accounts no solution proposed can do this. This is not a <picture> only problem. > (and that's not simply a matter of adding bandwidth media > query) and has no mechanism to specify scaling factor for intrinsic sizes of > images. Not actually sure what "intrinsic sizes of images" means. > IMHO those are pretty serious drawbacks that limit its functionality, which > is much worse than "ugly, but gets job done" state of srcset. I see no difference between the end result of either syntax. Both approaches fail utterly in abstracting the query from the mark-up, which means both approaches are suited only to individual images. Should the design of the site change at any point, both solutions break completely. It's a major problem I pointed out with <picture> over in the CG. Srcset is no better in this regard. > There are two categories of use-cases ("art-directed" and > "dpi/optimization") and <picture> is suited for only one of them, so please > don't frame the decision as "discarding" of a perfectly good solution, as it > wasn't. Picture dealt with both of these by simple use of the pixel density media query - i.e, in exactly the same way CSS already does it. I do not understand your argument. > srcset addresses both dpi/optimisation and art-directed use-cases. It has > its own problems, such as confusing microsyntax, so suggestions how to > improve this are welcome. Agreed, and already underway. > Lamenting <picture> and accusing WHATWG of wrongdoing is not productive. With respect, finding out where there have been fuck-ups is in everyone's interest if we want to get the most out of the process and communities who are all trying to better the web. > If you'd like to see <picture> proposal succeed, then please help fixing its > drawbacks. I've said I don't. No part of my argument said I condone continued argument for supporting picture - I in fact said I don't like it and haven't liked it since it was in the CG. > Make selection and embedding of 2x images easier. > Give UA freedom > to use cached higher-quality images when it can. Give UA freedom to choose > images to minimize bandwidth or maximize quality. Reduce verbosity of most > common cases. > > I've tried to raise those issues on the Responsive Images group's > mailinglist, but got no constructive feedback. That last bit is annoying. Some of the key players in that group seem to ignore stuff since they decided <picture> was finished - I've had the same problem myself. > -- > regards, Kornel Lesiński
Received on Friday, 18 May 2012 22:12:17 UTC