W3C home > Mailing lists > Public > www-style@w3.org > October 2014

[css-images] Extending image-set() to be equal-power with current srcset/<picture>

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 24 Oct 2014 16:25:41 -0700
Message-ID: <CAAWBYDBopzzZxz37aHA31yfr2Sa9dhua7ZT7YAjWi-YpEA+5qQ@mail.gmail.com>
To: www-style list <www-style@w3.org>
The image-set() function was originally designed to emulate the
functionality of the srcset attribute on <img>, back when it was first
proposed by Apple.

Today, though, the srcset syntax and functionality has been expanded,
and the <picture> element offers further elaboration on the concept.
It would be nice if CSS matched the functionality of HTML in this
regard.

There are four basic abilities offered by <picture>:

1. Let the browser choose which of several images it wants to
download, based on resolution.
2. Same as #1, but rather than specifying the resolution directly, you
specify the size of the image file and let the browser figure out the
effective resolution based on the size it'll be displayed at.
3. Different images based on MQs.
4. Supply images in multiple formats, with browsers ignoring ones they
don't understand.

Currently, image-set() satisfies #1, and MQs in CSS satisfy #3.  We're
left with #2 and #4 as things HTML can do but CSS can't.  I suggest we
fix this with two small additions to the image-set() syntax:

1. Allow, instead of a <resolution> value, an <image-size> value,
which is a dimension with a "w" or "h" unit, expressing how large the
image is in image pixels.  (The HTML image selection algorithm does
not yet use "h" data, but it will in the future, and it explicitly
ignores "h" descriptors without dropping the whole candidate, so that
in the future it can pay attention to them.)  It's resolved into an
effective <resolution> based on running the Object Sizing Algorithm
with no intrinsic dimensions, to find the rendered size of the image.

2.  Allow a format() function, same as @font-face/src, in each
candidate, taking a string argument specifying either a mime type or a
short name for an image type (defined in a table in the spec). If the
browser doesn't support or doesn't understand the given type, it
ignores the candidate.

Thoughts?

~TJ
Received on Friday, 24 October 2014 23:26:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:25 UTC