W3C home > Mailing lists > Public > public-respimg@w3.org > February 2013

RE: CfC: to publish "The srcset attribute" specification as a First Public Working Draft (FPWD)

From: Paul Cotton <Paul.Cotton@microsoft.com>
Date: Wed, 27 Feb 2013 12:04:12 +0000
To: "Nathanael D. Jones" <nathanael.jones@gmail.com>, Edward O'Connor <eoconnor@apple.com>, Yoav Weiss <yoav@yoav.ws>, Marcos Caceres <w3c@marcosc.com>, Mathew Marquis <mat@matmarquis.com>
CC: "public-respimg@w3.org" <public-respimg@w3.org>, Fred Andrews <fredandw@live.com>
Message-ID: <AB5704B0EEC35B4691114DC04366B37F202B5FCB@TK5EX14MBXC297.redmond.corp.microsoft.com>
Would it be possible to send this to public-html@w3.org<mailto:public-html@w3.org> for discussion there by the HTML WG?


Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

From: Nathanael D. Jones [mailto:nathanael.jones@gmail.com]
Sent: Wednesday, February 27, 2013 6:24 AM
To: Edward O'Connor; Yoav Weiss; Marcos Caceres; Paul Cotton; Mathew Marquis
Cc: public-respimg@w3.org; Fred Andrews
Subject: Re: CfC: to publish "The srcset attribute" specification as a First Public Working Draft (FPWD)

A Unified solution to <picture>

Perhaps there's a very simple way to support both pre- and post-layout queries with <picture>, and sacrifice neither functionality or performance.

If sources specify the dimensions of the images (and more than one image matches the media queries), we delay image fetching until CSS is downloaded; otherwise fetching can occur immediately.

We can then apply sizing constraints to further filter the list of images (media queries are still king, but if more than 1 image 'matches', we use size constraints).

I've written up the details here: https://gist.github.com/nathanaeljones/5047077


I also propose the expansion of the Use Cases and Requirements document to include:

11 The solution SHOULD offer an method to leverage breakpoints defined in CSS.
12. The solution SHOULD support a simplified syntax to support primary use case 3.1 (preferably a list of images and their dimensions), in order to reach users of content management systems and those without detailed knowledge of CSS media queries.

This allows complexity to be moved from HTML to CSS, and removes the need for high-volume repetition of breakpoint logic.

Authors who wish to use responsive web design will be able to use a CSS framework or snippet and matching CSS classes on <picture> to achieve responsive images - a path much less intimidating than CSS media queries, and much easier for CMSes and authoring tools to support (how would a GUI for media queries be designed)?

I fear for adoption of <picture> unless we can make it CMS and 'non-coder' friendly.

On Wed, Feb 6, 2013 at 7:31 PM, Edward O'Connor <eoconnor@apple.com<mailto:eoconnor@apple.com>> wrote:
Hi Fred,

You wrote:

> If the 'picture' and 'srcset' proposals are limited to[…] using only
> information available pre-layout[…] it may not be proper for ambiguity
> in the RICG proposals to delay other development work in an area that
> needs urgent attention.
I'd like to clarify two things:

1) The srcset="" specification is not a proposal of the Responsive
   Images Community Group, although feedback from the members of that
   group have certainly contributed to the feature's design.

2) By working on the srcset="" nor <picture> specifications within this
   working group, those working on them are not delaying other work that
   you or other WG members may want to take on. In particular, if you
   would like to work on a proposal for an adaptive images feature that
   relies on layout information, please do so! I would be happy to
   review a draft in that area.

> It is not immediately obvious to me how the specialized 'picture' and
> 'srcset' solutions proposed by the RICG could fit alongside more
> general solutions and it is likely that more general solution would
> subsume the current proposals.
I think we can address such confusion within these drafts when and if a
more general solution is produced.


Received on Wednesday, 27 February 2013 12:05:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:08 UTC