Re: [css3-images] simplifying radial gradients

On Oct 12, 2011, at 10:29 AM, Brian Manthos <brianman@microsoft.com> wrote:

>> 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 don't see how. I am giving 'linear-gradient()' equal standing to 'url()'. CSS does not include ways for BMP/JPG/PNG images to be cropped, moved, and sized within 'url()', So why does radial-gradient have to have ghat?

> 
> I think the (W3C) priority of providing that replacement trumps the (personal) goal you keep asserting of limiting it to "gradients as <background-image>".

I am in the WG. It is not personal. And it is a huge exaggeration to say that I am limiting it to "gradients as <background-image>".

Received on Wednesday, 12 October 2011 20:44:32 UTC