[webkit-dev] The SrcN responsive images proposal

Tue Oct 22 15:19:12 PDT 2013

On Oct 22, 2013, at 1:50 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

> On Sat, Oct 19, 2013 at 7:00 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> My initial impression is that it seems a bit overengineered.
> 
> Can you elaborate on these concerns?

- The syntax is effectively a list of lists, the outer level being implicit in the numbers in the attribute names, and the inner being an explicit comma-separated list. That seems complicated.

- Media queries are much more general than is actually needed for the use cases as outlined in the spec (even if reduced to only allowing a single clause). Granted, the useful subset of media queries is easier to read than w/h.

- Even if you want to use only the inner level of list, you still need to acknowledge the implicit outer level (in which case having "src-1" or whatever in your markup seems weird). To be fair, this could be addressed by still supporting "srcset" and giving it a defined place in the resolution order, as proposed by the spec itself in "ISSUE 5".

- The proposal defines a rather complicated structured microsyntax.

That's from skimming the spec. My opinion could change on closer reading.

Regards,
Maciej

>  I tried to find the simplest set
> of features that solves the use-cases I was presented with in a good
> way:
> 
> * lists of urls and resolutions, like basic srcset
> * use of familiar MQs rather than the new and, from developer
> feedback, rather confusing 100w terminology.
> * a variant of the above for handling cases where the image's sizes is
> variable, rather than known at authoring time, without needing to
> repeat yourself a ton.
> 
> The FF and Blink implementors, several RICG folk, and a number of web
> authors have told me that they like src-n quite a bit.  That's not
> conclusive, of course (we can definitely find people who dislike it,
> too), but it's not something I'm trying to push without any support.
> ^_^

> 
> On Sun, Oct 20, 2013 at 3:31 AM, PERIER Romain <romain.perier at gmail.com> wrote:
>> srcset is not complicated enough for a web developer?  why do you want to
>> add complexity for the developer ? The srcset specification already convers
>> DRP switching and viewport (not implemented yet, but it is planned, it is in
>> my todo list)
> 
> The src-n proposal is nearly a superset of srcset.  For the simple,
> and expected to be most common, case of just delivering an image at
> various densities, the syntax is *identical* to srcset.
> 
> The two other tweaks are just a modification to the viewport-switching
> from a brand syntax to a more familiar MQ-based syntax, and a shortcut
> syntax to make it possible to specify a variable-sized image without
> requiring the author to repeat their urls or do non-obvious math to
> discover where the best breakpoints are.
> 
> That last one, in particular, is pretty important I think.  Handling a
> variably-sized image in full srcset syntax is *possible*, but doing it
> well is quite a lot of work, and I don't think most authors will do
> so.  Instead, they'll do the minimum amount of typing to get stuff to
> work on the devices they have, and I don't blame them for that.
> However, this means that monitor sizes outside the range they thought
> about aren't served well, nor are future higher densities: why would
> anyone purposely add a 3x or 4x image when such devices don't exist
> yet; why would anyone spend the effort to provide <1x density images
> for low-bandwidth connections when *their* bandwidth is just fine?
> 
> If you last read the spec more than a week ago, I rewrote the section
> concerning this last grammar branch to make it much easier to
> understand what it's for, and added more example.  Please give it a
> whirl and see if you understand my point a little better.
> 
>> why don't you propose improvements to the original
>> specification/implementation instead of  reinventing the wheel ?
>> Syntaxically-speaking, it's not smart.
> 
> srcset cannot be reasonably extended into something that solves the
> problems as well as I think that src-n does.  I apologize for coming
> up with this idea relatively late in the process, but there's not much
> I can do about that now.
> 
> That said, the processing algorithm already handles src as a fallback
> value, and there's an issue logged there talking about how srcset can
> be used as a fallback as well.  While it would be ideal if we dropped
> our initial srcset implementations in favor of src-n, it's not killer
> if we end up keeping it and src-n both.
> 
> On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto <koivisto at iki.fi> wrote:
>> Ignoring other aspects of this, the idea of making attribute name an
>> enumeration is somewhat distasteful. It will require ugly special parsing.
>> The platform has plenty of attribute values that are lists already.
> 
> The parsing aspect isn't particularly new - parsing data-* attributes
> presents the same problem.  You just need to filter the list of
> attributes on the element to look for things with a src- prefix.  I've
> heard direct feedback from Yoav, implementing in Blink, that it's not
> a big problem.
> 
> As to the design concern, the platform certainly does already have
> lists, but putting this stuff into a single attribute would make it a
> list of lists, which is hard to read, write, and maintain.  I felt
> that the pain of having lists of lists was worse for authors than the
> cost of understanding multiple attributes.  I think it's similar to
> data-* - it *could* have been designed as a single "data" attribute,
> with either a microsyntax or maybe just JSON to allow you to specify
> multiple key-value pairs, but it was easier to read and write as
> separate attributes.
> 
> The other approach to this is to use multiple elements, like
> <picture>/<source>.  Several implementors have expressed concern with
> this approach from an implementation-difficulty perspective; there
> have been suggestions about how <source> processing could be tweaked
> to make it easier, but then we have the fairly bad situation of
> <source> acting differently in <video>/<audio> and <picture>.  This
> approach also means you have to introduce new elements, rather than
> using the existing ones; this has both upsides and downsides, and I
> think ends up being about a wash.
> 
> The numbering, too, serves an interesting purpose.  Because the
> algorithm processes the src-n attrs in numerical order, you can write
> them in whatever order you wish.  Mat Marquis, for example, finds it
> most convenient to use min-width MQs and arrange them in ascending
> order, as it's easier to read, but that's the opposite of the order
> they need to be evaluated in, so he can correct this by just writing
> the src-n attrs in descending order.  He's given several examples of
> this when discussing this proposal.
> 
> On Sun, Oct 20, 2013 at 2:08 PM, Benjamin Poulain <benjamin at webkit.org> wrote:
>> On 10/20/13, 9:07 AM, Antti Koivisto wrote:
>>> Ignoring other aspects of this, the idea of making attribute name an
>>> enumeration is somewhat distasteful. It will require ugly special
>>> parsing. The platform has plenty of attribute values that are lists already.
>> 
>> I was thinking the same thing last night. In addition to weirdness on
>> the engine side, it looks like a nightmare for authoring/tooling.
>> 
>> Is there a precedent for this strange notation?
> 
> Yes, data-* is somewhat of a precedent.  This is, however, the first
> set of attributes that vary numerically, rather than by an arbitrary
> user-provided string.
> 
> On Sun, Oct 20, 2013 at 3:29 PM, Antti Koivisto <koivisto at iki.fi> wrote:
>> Also CSS selectors only support matching exact attribute names. There is no
>> way to write universal "elements with some srcN attribute" query for
>> example. This might not be important for practical uses here but it does
>> demonstrate that the approach is a poor fit to the platform.
> 
> If this becomes important, we should extend CSS to do this.  We have
> lots of attribute-matching functions for *values*, doing the same for
> *names* is likely possible.
> 
> I think this *is* a generic problem, as I've heard similar complaints
> about the ability to style certain XML languages before.
> 
> On Mon, Oct 21, 2013 at 3:15 AM, Michael[tm] Smith <mike at w3.org> wrote:
>> To give a specific example: I work on the code for the W3C validator and I can
>> tell you that implementing validator support for the srcN proposal would require
>> adding a not-insignificant amount of new special-casing code that nothing else
>> has ever required, along with some greater-than-normal (though still relatively
>> small) runtime cost. And the way I'd have to implement it seems hacky and
>> ugly and I'd really rather not do it unless there's no other alternative we
>> can get agreement on for solving the responsive-images problem.
> 
> As I've argued before, I think "making validators easy to write" is a
> concern that's very, very low on the priority of constituencies.  Only
> a few people ever write validators in the entire web, so it's okay to
> saddle them with extra engineering effort if it helps the other
> constituencies.  Further, the problem you've described with validating
> these has nothing to do with src-n itself, but rather is a consequence
> of the particular technology the W3C's validator currently uses.  Many
> possible validator architectures would have no problem at all with
> handling attributes like this.
> 
> ~TJ