[whatwg] <picture> redux

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

On blink-dev, Adam Barth brought up an older objection he had to the
original <picture> proposal.  (This also applied to src-N, but Adam
didn't realize that it applied.)

At the time (back in April), we in Blink were considering moving our
preloader to another thread, and by now we've actually done it.

However, in general, MQ parsing and resolving is complex and relies on
data structures on the main thread.

Note, though, that some types of information that MQs can express,
such as resolution, width, or height, are a requirement of *every*
proposed solution.  We obviously need to be able to use this
information in the preloader in order to get *any* responsive images
solution working.

Luckily, these pieces of information are fairly static, and John
Mellor confirms that they should be trivial to copy the info over to
the preloader thread.  Combine this with a simple parser for media
features (simple to do alongside the other parsing), and you can do
several of the most necessary MQs without a problem.

This then brings up the question of what to do with "unfriendly" MQs
that rely on more complex information that can't be reasoanbly shipped
over to the preloader thread, like (pointer).  I suggest that the
preloader simply treat these as unknown (and thus false).  In some
cases this won't matter; the correct choice'll be taken even with the
other ones ignored.  In cases where it does matter, and the preloader
ends up skipping an MQ for a source that it should have chosen if it
had all the information, oh well, it'll kick off a wasted download.
The main thread can verify this sometime later and select the correct
source, so the right image gets selected, just a little late.

This lets us avoid normatively specifying which MQs are compatible
with the preloader, as it's just an optimization (though we should
definitely *informatively* provide a list of common ones), and it
avoids constraining the future design of either preloaders or MQs.

~TJ