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
