[whatwg] <picture> redux

Wed Nov 20 14:21:46 PST 2013

Am 20.11.2013 22:27 schrieb Tab Atkins Jr.:
> On Wed, Nov 20, 2013 at 9:25 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>> Simon Pieters wrote up Kornel's earlier approach to a saner, more
>> palatable source selection algorithm for <picture> (rather than
>> copying <video>/<audio>).  This approach also has a new wrinkle:
>> <picture> *requires* an <img> child, and it's the <img> that still
>> actually displays the image.  The <picture> element is just a wrapper
>> for the <img>+<source> elements, and provides a context for the source
>> selection algorithm.  This makes testing substantially easier, as we
>> can limit ourselves to testing the source selection algorithm, and
>> probably makes implementation easier as well.
>
> Adam Barth brings up a wrinkle on blink-dev, based on an older
> objection he had to <picture>.
>
> At that time, Blink was considering moving its preload scanner
> off-main-thread, and Adam wanted to make sure that the design of
> <picture> didn't preclude that from happening.  Now, our preload
> scanner *is* on a separate thread, so we're definitely constrained in
> what we can do there.
>
> His basic concern is that MQs are too complex to be done
> off-main-thread, so it's hard/impossible to do MQs in the preload
> scanner.
>
> My response is that *some* MQs are perfectly fine to do off-thread, as
> they're basically just static properties of the display.  John Mellor,
> who's done some preliminary work around this in Blink, supports this.
> We can just hand the relevant data to the preload scanner and do
> simple MQ parsing.
>
> We don't need to actually limit the MQs which are allowed in
> <picture>.  The preloader is just an optimization in the first place;
> we *want* the image to be preloaded, but if it isn't, the image will
> still work, just slower.  We can provide a note about which types of
> MQs are likely to be recognized by the preloader.  Unrecognized MQs
> can just cause the preloader to ignore that <source>, and if that
> means an incorrect source is selected, that's just a wasted download,
> but back on the main thread, the source selection algorithm will pick
> the right picture a little bit later.
>
> Regardless of how we do this, though, *some* form of MQ or MQ-like
> functionality is part of *every* proposal that has been brought
> forward, as it's necessary for resolving several of the use-cases.

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