[whatwg] Simplified <picture> element draft

Adam Barth w3c at adambarth.com
Fri Jan 3 22:36:27 PST 2014


On Tue, Dec 31, 2013 at 7:17 AM, Yoav Weiss <yoav at yoav.ws> wrote:
> On Mon, Nov 25, 2013 at 5:33 PM, Adam Barth <w3c at adambarth.com> wrote:
>>  Is there an editor's draft or some other relatively self-contained
>> write-up that I could review?
>
> Tab has rewritten the picture spec to match the latest proposal. You could
> review it at http://picture.responsiveimages.org/

Thanks.  I'm still concerned about the issue I raised with the
original <picture> proposal in April 2012:

---8<---
In order for the HTMLPreloadScanner to issue preload requests for
<picture> elements, the HTMLPreloadScanner would need to be able to
evaluate arbitrary media requests.  That's difficult to do without
joining the main thread because the media query engine works only on
the main thread.
--->8---

https://groups.google.com/a/chromium.org/d/msg/blink-dev/MlE9vYVUlzg/lohBvySEIegJ

The proposal tries to address this issue in
http://picture.responsiveimages.org/#preloader by providing a
whitelist of media queries that must be recognized by the preload
scanner and giving implementations license to evaluate other media
queries incorrectly.

In principle, we could implement these requirements in Blink, but my
guess is that we won't be able to implement them anytime soon.  For
example, today we can't even parse media queries on the preload
scanner thread.  We're likely to improve our ability to process CSS on
background threads in order to make existing content faster.  It's
possible in several years once we've developed fancier technology this
design will look more feasible.

In the meantime, if you're interested in seeing implementations ship
in the near term, I would focus on designs that don't require
evaluating media queries in the preload scanner, even if that means we
aren't able to address all the use cases that <picture> addresses.

Adam



More information about the whatwg mailing list