[webkit-dev] The SrcN responsive images proposal

[Tab Atkins Jr.]

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?  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