W3C home > Mailing lists > Public > www-style@w3.org > January 2015

Re: [css-images] imageset definition - too strict?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 12 Jan 2015 12:13:50 -0800
Message-ID: <CAAWBYDBtAAwQqbwCMQ4RHSn=DuKRi0WY0h5Je=t-n4Ms79JAhg@mail.gmail.com>
To: Axel Dahmen <brille1@hotmail.com>
Cc: www-style list <www-style@w3.org>
On Tue, Jan 6, 2015 at 6:18 PM, Axel Dahmen <brille1@hotmail.com> wrote:
> In ยง 2.3 the dev version of the spec reads: "Every <image-set-option> in a
> given image-set() must have a different <resolution>, or else the function
> is invalid."
>
> Shouldn't this be more forgiving? I mean, I don't see a reason why it
> shouldn't be sufficient to but apply the first image of an image-set
> matching a resolution precondition and ignore following images representing
> the same resolution.
>
> So, a CSS rule like this:
>
> background-image: image-set("foo-600.png" 600dpi, "foo-301.png" 300dpi,
> "foo-302.png" 300dpi, "foo-150.png" 150dpi);
>
> would have image #1, #2 and #4 applied as appropriate, but image #3 would
> but be ignored.
>
> Wouldn't a more forgiving algorithm like this be more in the spirit of this
> standard?

This matches the behavior of <img srcset>, and I don't see a
compelling reason to do otherwise.  The only possible foot-gun is
people using mutliple different resolution units, if they're not
directly comparable, but currently they all are (x/dppx, dpi, and dpcm
are all related by fixed ratios).

If we ever do grow a resolution unit that's not directly comparable to
the existing ones (dots per em?), we can relax the restriction to only
invalidate rules that have directly-comparable-equal resolutions.

CSS doesn't have a consistent treatment of small errors like this.  We
do tend to treat obvious authoring errors as an error making things
invalid, which is consistent with the current spec, but of course
that's not absolute.

~TJ
Received on Monday, 12 January 2015 20:14:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:50 UTC