RE: [css3-images] simplifying radial gradients

On Wednesday, October 12, 2011 1:44 PM Brad Kemper wrote:
> 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?

The x-gradient() functions are NOT equivalent to url() they are actually equivalent to the image (PNG/GIF/JPG) itself. The *-gradient() functions is creating an image just like you create in Photoshop. We just allow you to define the image using CSS syntax.

> >
> > 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>".

In reading all of your examples I also got the impression that you were arguing to limit gradients to 'background-image'. If that is not the case then please try all of the examples that have been given using list-style-image. You will find that some of the suggestions you gave for simplification just aren't possible unless we use the syntax that we have defined in the spec today. Some of your examples were using background-position and there is no equivalent for list-style-image. So right there that example isn't valid for a pure image replacement and that just reinforces the fact that the spec solution that we have now is the one we should stick with. Any example that uses more than just the property that specifies image (e.g. background-image, list-style-image, etc...) is breaking the rules so to speak in this argument.

--
Thanks,
Arron Eicholz

Received on Wednesday, 12 October 2011 21:36:31 UTC