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 16:37:21 +0000
Message-ID: <CAMCRKiJfKXXeBfxiskxE-NqkUfzyYUqyOCnbRhUCZNqqO5n7Dg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: WHATWG List <whatwg@whatwg.org>
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@gmail.com> wrote:
> On Mon, May 14, 2012 at 5:34 PM, Matthew Wilcox <mail@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
Received on Monday, 14 May 2012 20:39:47 UTC

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