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

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
moved.

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
http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/#comment-752
)

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