W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

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

From: Matthew Wilcox <mail@matthewwilcox.com>
Date: Mon, 14 May 2012 15:35:34 +0000
Message-ID: <CAMCRKiJUWZNEPC-RS-n0x3Fj1PYXULz7SddU2_H+EfhaxeMU1A@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: WHATWG List <whatwg@whatwg.org>
Thanks for the feedback. Please also forgive me not being too
technically aware of things at a browser level; so I'm not really sure
how valid my feedback can be:

The URI thing is actually using URI Templates, which are already
pretty far along? http://code.google.com/p/uri-templates/ I thought
this was a strong advantage of the idea.

Putting the variables into the CSS would break the advantage of them
being available to the browser *before* the browser starts trying to
pre-fetch images, right? Any solution has to avoid the prefetch
behaviour or else it fails; so I don't understand how they could be

I am of the opinion that media queries actually belong in the head
more often than they do elsewhere, both from a practical and semantic
standpoint (see

I had presumed that should multiple cases match the browser would
simply uses the last matching one. There's already a polyfil in JS
that does exactly that: http://jsbin.com/3/ecifaf/latest/

On 14 May 2012 15:50, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, May 14, 2012 at 10:55 AM, Matthew Wilcox <mail@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
Received on Monday, 14 May 2012 20:39:46 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:42 UTC