[whatwg] An alternative to <picture> and srcset, is this realistic?

Mon May 14 07:50:48 PDT 2012

On Mon, May 14, 2012 at 10:55 AM, Matthew Wilcox <mail at matthewwilcox.com> wrote:
> Hi all,
>
> have any of you seen this proposal for an alternative solution to the problem?
>
> http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
>
> I like the general idea and from an author perspective this seems
> great; but I know nothing of the browser/vendor side of the equation -
> is this do-able?

Several critiques, in more or less random order:

I'm not sure why it's billed as an alternative to @srcset as well - it
has nothing to do with that functionality.  It's purely a way to stuff
your media queries (which, as already established, can't be used to
serve different resolutions well) into a variable, and then abstract
your url-rewriting into a single place.

I do like the idea of abstracting your MQs - the post makes a good
point that between CSS and JS you're already duplicating your
breakpoints, and if <picture> or a similar solution is adopted, you'll
be doing it a lot more.  Unfortunately, Media Queries aren't
immediately amenable to CSS Variables (moving from global vars to
tree-scoped vars means that things that aren't part of the element
tree can no longer see the vars), so we either need something like
this, or I need to add to Variables so that they're friendly to this
use-case (and can interact with the URL-rewriting mechanism proposed).

I share Anne's concern that the contents of <head> are often not
trivially authorable.  This isn't killer, but it's something to keep
in mind.  Moving the definition to CSS might help here, as it could be
put in an inline CSS block at the top of <body> then.

This approach implies that all of your images (at least, all of them
with [case] in their URL) must respond to *all* of your breakpoints.
If an image doesn't change between certain breakpoints, it still needs
to exist in two places on your server (or you need to manually alias a
single file) and the browser will make an extra useless request if you
cross those breakpoints.

>From a technical purity standpoint, this introduces a new
URL-rewriting mechanism, but specialized for only a single purpose.  I
suspect there are other uses that URL-rewriting could potentially be
put to; we should think about this and make sure that this approach
doesn't close the door to future uses.  (It doesn't need to be
magically infinitely extensible - that way lies madness - but making
reasonably sure that it doesn't close the door to other URL-rewriting
use-cases is just good sense.)

I mentioned above that this solution has nothing to do with @srcset.
It's actually slightly worse - this ends up being *hostile* to
@srcset, such that you can't combine the two.  At least, not without
reworking @srcset into a parallel URL-rewriter.

The proposal doesn't explain what to do when multiple MQs match.
Normally, the CSS cascade takes care of this - if you apply the same
property under multiple MQs that all match, specificity determines the
winner.  It wouldn't be difficult to define how this worked -
last-wins is probably the sanest - but still, it's a detail to be
specified.

Note, though, that if we want this to hook into a more generic
variables-in-MQ sort of thing, one may indeed want multiple axises of
variables that can match together.  I suspect this is especially
useful with the new media queries that will show up in MQ4 to help
target different kinds of devices.  So, it may be good to look into
widening this to accomodate different variable names, where within a
variable only a single case can "win" at a time.  Related - it would
probably be good to be able to define a "default" case to fall back to
when none of the others match.

~TJ