[webkit-dev] The SrcN responsive images proposal

Ryosuke Niwa 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. ]
>
> On 7 Nov 2013, at 17:43, "Tab Atkins Jr." <jackalmage at gmail.com<javascript:;>>
> wrote:
>
> >> 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
construction.

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...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131108/783efb7d/attachment.html>


More information about the webkit-dev mailing list