W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2014

Re: [whatwg] Simplified <picture> element draft

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 8 Jan 2014 09:46:42 -0800
Message-ID: <CAAWBYDDd8uLi5HuqtNhU5vQ9Fabvt8iVfKNQc3eGCSGwF-C7Pg@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: whatwg <whatwg@whatwg.org>, Yoav Weiss <yoav@yoav.ws>, Timothy Hatcher <timothy@apple.com>, Adam Barth <w3c@adambarth.com>
On Wed, Jan 8, 2014 at 9:18 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Dec 31, 2013, at 7:17 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>> On Mon, Nov 25, 2013 at 5:33 PM, Adam Barth <w3c@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/
> This approach seems cleaner than src-n. I'll try to read it in more detail, but a few initial comments:
> - Is there any reason not to allow the sizes="" attribute and the extended definition of srcset="" on <img> as well as <source>? It seems like the <picture> wrapper is not helpful in cases where you only use one <source> element.

Nope, no reason other than I was trying to minimize initial changes in
the spec.  I'm totally happy to add it, for the reason you list, and
so that an early implementation of just <img srcset> will be
compatible with a fuller <picture> implementation.

> - It seems this draft allows arbitrary media queries, with only a subset expected to give best performance (by correctly informing the preload scanner). In my opinion, this is worse than the alternative of only supporting the media queries that could plausibly be integrated with preload scanning. Creating a programming interface with a "performance cliff" - a point beyond which performance suddenly gets significantly worse for what seems like a small incremental change - is generally a bad idea. And the use cases for fully general media queries seem much more speculative than the ones for the simplified subset.

The set of MQs that can be done on the preloader thread seems
ill-defined and potentially growing.  Even within the set that the
spec currently requires, we've gotten feedback that those MQs are
possible in some cases but not others (within an iframe you can't tell
what the viewport dimensions are until the outer document has finished
initial layout).

Received on Wednesday, 8 January 2014 17:47:27 UTC

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