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

Mon May 14 09:31:23 PDT 2012

All good points, thanks. Sorry I'd missed you saying <style> rather
than <link/>, my bad!

I had assumed that we would be able to take the logic for resolving
media query applicability directly from that in CSS, which is why I
have not given it any further thought. It seemed like a solved issue.

I ought to point out I've been updating the main post today, and have
also added a "prior art" thing about how this works for JavaScript -
the Conditional CSS technique is already doing what I am proposing
here, but using pesudo content rather than a meta tag.

:)

On 14 May 2012 16:55, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Mon, May 14, 2012 at 5:34 PM, Matthew Wilcox <mail at matthewwilcox.com> wrote:
>> 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.
>
> I don't know of this having any traction within actual browsers.  It
> might be a good idea, I dunno.
>
>> 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.
>
> That's why I mentioned an inline <style> at the top of the <body> -
> I'm not sure if browsers skip past that when building the tree or not,
> but it's *potentially* available.
>
>> 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 don't necessarily disagree.  I wasn't arguing from a theoretical
> standpoint, just supporting Anne's point that, from a practical
> standpoint, putting things into <head> isn't always easy for authors.
>
>> 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/
>
> Yeah, you can't assume that.  They're conditions, and a page can
> potentially match multiple of them at once.  For example, if your MQs
> are "min-width: 1000px" and "min-width: 300px", a 1200px wide screen
> will match both of them.  You can *make* them exclusive by adding a
> max-width declaration as well, but we can't depend on that happening,
> so the behavior has to be specified somewhere.
>
> Similarly, we can't depend on *any* of them matching, so there should
> be a default case that is used when nothing else matches.
>
> ~TJ