- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 23 Nov 2010 13:14:54 -0800
- 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 UTC