> 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
This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:05 UTC