[webkit-dev] The SrcN responsive images proposal

Yoav Weiss yoav at yoav.ws
Fri Nov 8 10:10:06 PST 2013

I think this discussion might be more fruitful at a vendor neutral forum,
so I've started a thread out on the WHATWG:

On Fri, Nov 8, 2013 at 6:06 PM, John Mellor <johnme at chromium.org> wrote:

> Most discussion so far seems to be bikeshedding the syntax. To make this
> more productive, can we focus on the core issues?
> srcN brings two things to the table, compared to srcset:
> 1. It handles viewport-switching better (easier to author, avoids
> repetition of image urls, allows bandwidth-driven decisions).
> 2. It handles art direction.
> Does everyone agree that these are useful and long-overdue problems to
> solve, and that the high-level approach of srcN (with <viewport-urls>
> syntax to handle viewport switching, and a layer of media queries above
> that) is the best (only) known solution to these?
> On Fri, Nov 8, 2013 at 3:24 PM, Dean Jackson <dino at apple.com> 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> 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.
>> fwiw path d is an attribute because we expected thousands of values in
>> that and structure would have been too unwieldy.
>> dean
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131108/afa43039/attachment.html>

More information about the webkit-dev mailing list