[whatwg] An alternative to <picture> and srcset, is this realistic?
mail at matthewwilcox.com
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
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
> 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
> 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.
More information about the whatwg