- From: matmarquis.com <mat@matmarquis.com>
- Date: Mon, 7 Oct 2013 10:37:22 -0400
- To: Marcos Caceres <marcos@marcosc.com>
- Cc: François REMY <francois.remy.dev@outlook.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Shane Hudson <shane@shanehudson.net>, "public-respimg@w3.org" <public-respimg@w3.org>, Robin Berjon <robin@w3.org>
On Oct 7, at 10:26 AM, Marcos Caceres wrote: > > > > On Friday, September 27, 2013 at 6:59 PM, François REMY wrote: > >> >> Not saying this is the way to go, but I don't like the srcN part of the proposal either. It's not really script friendly either because you can't read or update them all at the same time. > It would be a bit of a nightmare to try to update the single attribute version without having a specific API to split everything into its component parts (if one tries to update this "by hand", doing anything wrong would invalidate the whole attribute - as the spec provides no error recovery). At least the multiple attribute version is a bit easier to work with, though it's fairly hard to reason about. Yeah—for what it’s worth, we picked an couple of fights over `srcset` and APIs already, and the result was being told that manipulating a single giant string was API enough. I agree that looping through attributes isn’t ideal (and looping through `source` elements seems a lot more natural), but it sure beats inscrutable string manipulation. > Regardless, there doesn't appear to be a lot of use cases for updating the attribute dynamically or for getting any kind of event (apart from what you already get with <img>). Those could be added down the line as needed… right now, src-n seems like a suitable evolutionary step that meets the "80% use cases" criteria. > > -- > Marcos Caceres > > > >
Received on Monday, 7 October 2013 14:35:07 UTC