Re: srcN - Alternative to picture and srcset

I believe a dataset()-like API would be pretty natural to add, if the need
arises later on.


On Mon, Oct 7, 2013 at 4:37 PM, matmarquis.com <mat@matmarquis.com> wrote:

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