Re: [whatwg] <picture> redux

On Wed, Nov 20, 2013 at 9:25 AM, Tab Atkins Jr. <jackalmage@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.

~TJ

Received on Wednesday, 20 November 2013 21:28:37 UTC