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

Re: [whatwg] Simplified <picture> element draft

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 08 Jan 2014 09:18:25 -0800
Message-id: <A00AF9A9-7652-43CB-8C78-9585FC5926A2@apple.com>
To: Yoav Weiss <yoav@yoav.ws>
Cc: whatwg <whatwg@whatwg.org>, Timothy Hatcher <timothy@apple.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Adam Barth <w3c@adambarth.com>

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.

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

Regards,
Maciej
Received on Wednesday, 8 January 2014 17:19:20 UTC

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