W3C home > Mailing lists > Public > www-style@w3.org > November 2010

[css3-images] Color as an image type

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 23 Nov 2010 13:14:54 -0800
Message-ID: <AANLkTimdfCxysTgtk4oM8-Dy0T4Xcb0Zan0OK-nPOZcJ@mail.gmail.com>
To: www-style list <www-style@w3.org>
I have a final issue I want to try and get feedback on before I think
I'm ready to request that Image Values be published as a Working
Draft.

Image Values defines the <image> type, which is essentially a
full-featured paint server a la SVG.  There is one significant lack
between <image> and paint servers, though, which is that a color is a
paint server but not an <image>.

It makes sense to be able to treat a color as an (solid-color, no
intrinsic dimensions) image, and may simplify some filter usage in the
future (for example, using rgba(0,0,0,.5) as the mask image in an
opacity-mask filter to just turn an image half-transparent everywhere,
or tinting an image by providing a color as one of the inputs to a
cross-fade filter).

Right now there are two ways to fake such a thing.  Originally, you
could create a color-image using the gradient functions - for example,
linear-gradient(yellow,yellow)" would create a solid yellow image with
no intrinsic dimensions.  Now, we have the image fallback function
which can also serve this purpose somewhat more cleanly - if you just
provide a fallback color and no images, it'll return an image of that
color - image(yellow).

The latter may be sufficient to pronounce this "not a problem", but
the extra function is just kind of gratuitous, especially if you're
already using one of the color functions - "image(rgba(0,0,0,.5))"
looks uglier than necessary.

The upside of this is that anything that wants to accept an <image>
can just do that; fellow spec writers don't have to think about
whether they want to accept colors as well, complicating up their
syntax slightly with an extra term.  It also ensures that things stay
consistent - it wouldn't be very good if *some* properties accepted
both an <image> and a <color>, but others accepted only an <image>.

The only downside I can see is that this makes the background
shorthand ambiguous if two colors are provided.  This is an easy fix,
though - we can just say that the first color seen in a background
shorthand is a <color> and goes to background-color, and if you see a
second color it's taken as an <image> and assigned to
background-image.  Hopefully this is minimally disruptive to parsing,
as you can still assign a color to a property immediately; you don't
have to wait around and see if there are more colors or something.
The only compat impact is that if there are currently background rules
with two colors and no image, they'll start being respected instead of
ignored.  I doubt this will be a problem in practice.

I don't consider this proposal a requirement, but I think it would be
nice to have for both site authors and spec authors in the future.

Thoughts?  If there are no objections, I'll add it sometime next week.

~TJ
Received on Tuesday, 23 November 2010 21:15:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:34 GMT