W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] <picture> redux

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 20 Nov 2013 14:32:40 -0800
Message-ID: <CAAWBYDBx3Xscq5nS7NjJw75+k=bJUhPP9KQ4bcqNFQ3H-oOcKQ@mail.gmail.com>
To: Markus Ernst <derernst@gmx.ch>
Cc: WHATWG List <whatwg@whatwg.org>
On Wed, Nov 20, 2013 at 2:21 PM, Markus Ernst <derernst@gmx.ch> wrote:
> I am still very much concerned about centralizing MQs, and - without
> knowledge about the preload scanner - I just wondered whether centralization
> could be beneficial for the preload scanner, too. If we had some kind of CSS
> constants available, this could look somehow like (adapting the constant
> syntax suggested by fantasai years ago, just for the sake of illustration):
> <head>
> <style type="text/css">
> @define mediaqueries {
>   small: (max-width:479.99px);
>   medium: (min-width:480px) and (max-width:999.99px);
>   large: (min-width:1000px)
> }
> </style>
> </head>
> ...
> <source media="small" src="small.jpg 1x, small2.jpg 2x">
> ...
> Like this, MQs could be evaluated before the preload scanner is started, I
> assume?
> I am aware of the facts that the CSS aspects will have to be suggested in
> the CSS WG list, and that no CSS constants are available so far. But it
> would be nice if the respImg spec would be the way that it will support
> centralized MQs, once they will be possible from the CSS side.
> Thus my suggestion for the spec of the @media attribute in <source>: "It
> must contain a media query, or a value that represents the result of an
> evaluated media query."

As I've argued before, and you acknowledge here, we should not tie
this into the responsive images proposal.  It's separate and useful
for plenty of other things outside of responsive images.

Let's make sure that our responsive image solution is friendly towards
planned future MQ variables, but let's leave it off to the side while
we deal with the core problem.  Hooking too many things together just
makes the entire assemblage more fragile and slower to spec and

Received on Wednesday, 20 November 2013 22:33:24 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:14 UTC