[webkit-dev] The SrcN responsive images proposal
rniwa at webkit.org
Fri Nov 8 09:21:57 PST 2013
On Friday, November 8, 2013, Dean Jackson wrote:
> [And the holy book sayeth cursed is she who participates in standards
> email, doomed forever to receive email in CC and being unable to sleep at
> night. ]
> >> A proposal for a new paradigm of using multiple attributes deserves
> some resistance, careful consideration and exploration of alternatives. I
> feel my factual example of <path d> was flippantly tossed aside. So I
> responded in jest.
> > Apologies if you believed my response was flippant; it was short, but
> > serious and to the point. I explained why the <path d> example wasn't
> > very good - it's a single (albeit way overcomplicated) list of
> > commands. The src-N attributes already contain lists, so they're
> > comparable. I'm objecting to combining the src-N attributes into a
> > single attribute because that produces a *list of lists*, which is a
> > significant step further in mental complexity.
> one of the things I liked about srcset is that in the most urgent case it
> is simply one extra attribute with one higher resolution image.
> once we get into structure and ordering and multiple options and art
> direction any of these attribute solutions looks horrible. I don't care
> whether it is one attribute or 99, it's a pain to understand. if you want
> structure, use markup. I'm tempted to think the <picture> element is a
> better solution for these advanced cases.
I completely agree. I know at least other browser vendors have complained
about the implementation complexity of source element, microsyntax in
srcset and src-N attributes aren't that much better due to their unnatural
Given browser vendors already had to implement audio/video elements,
I don't buy the argument that it'll simplify their implementations either.
- R. Niwa
- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev