I think this discussion might be more fruitful at a vendor neutral forum, so I've started a thread out on the WHATWG: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-November/041369.html
On Fri, Nov 8, 2013 at 6:06 PM, John Mellor <joh...@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 <d...@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." <jackalm...@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@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
