- From: Brian Manthos <brianman@microsoft.com>
- Date: Wed, 12 Oct 2011 17:29:31 +0000
- To: Brad Kemper <brad.kemper@gmail.com>, "L. David Baron" <dbaron@dbaron.org>, Tab Atkins Jr. <jackalmage@gmail.com>
- CC: Sylvain Galineau <sylvaing@microsoft.com>, Alan Gresley <alan@css-class.com>, "www-style@w3.org" <www-style@w3.org>
> From: Brad Kemper [mailto:brad.kemper@gmail.com]
> One of my goals, as with the changes that were made to linear-gradient,
> was to not have a lot of duplication between background properties and
> gradient parameters. For one, we don't need to recreate backgrounds
> within the image, when background is by far the most common way to use
> images. Secondly, it is a recipe for confusion when there are multiple
> ways to create the exact same effects. It is much more clear and easy
> to learn when there is one "normal" way to create a given effect (not
> including unit conversions, extra spaces/tabs, etc.). It can be
> especially confusing when using background shorthand and the same or
> equivalent keywords and measurements are used inside and outside the
> measurement part for no good reason (other than, perhaps, for
> intentional obfuscation, as Brian suggested).
>
> I think if other uses of images ('content' property, filters, etc.)
> don't have ways to move, size, or clip an image, then they should get
> them, if that is important. It is no less important for raster images
> and SVG than it is for this flavor of generated images.
If "gradients as <image>" is intended to be a replacement for BMP/JPG/PNG downloaded files, this mindset is a barrier to that.
I think the (W3C) priority of providing that replacement trumps the (personal) goal you keep asserting of limiting it to "gradients as <background-image>".
Received on Wednesday, 12 October 2011 17:29:59 UTC