W3C home > Mailing lists > Public > www-style@w3.org > November 2010

Re: [css3-images] Proposed Gradients changes

From: Brad Kemper <brad.kemper@gmail.com>
Date: Mon, 29 Nov 2010 16:10:58 -0800
Message-Id: <1A0D17EB-0DC0-4475-829F-6122DD844ABE@gmail.com>
Cc: Rik Cabanier <cabanier@adobe.com>, www-style list <www-style@w3.org>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
If Filters are the primary benefit of duplicating background capabilities inside gradient images, then please enlighten me about how that works. Is there a Filters draft that explains how images are used in filters? I thought CSS Filters were going to use SVG functionality. Doesn't SVG have it's own way of generating gradients that is as complex as anyone could ever want?


Brad Kemper

On Nov 29, 2010, at 2:30 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Mon, Nov 29, 2010 at 10:09 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> On Nov 29, 2010, at 9:45 AM, Tab Atkins Jr. wrote:
>>> Not true.  At the very least, centering a radial gradient on the box
>>> corners semms common/useful enough that I want to address it.
>> 
>> It's not true "if you suppose that most radial gradients are going to be used in backgrounds", as I stipulated? Why couldn't you do that via 'background-position:-50% -50%; background-size:200% 200%' (or other sizes)? It is true.
>> 
>>> And you
>>> need the ability to express intermediate forms, so that immediately
>>> gets you the fully general centering ability.  (You could restrict it
>>> more, but it would be equal or greater complexity, so there's not much
>>> use.)
>> 
>> And you have that ability with 'background-position'.
> 
> Ah, I disagree with your basic premise, then.  Right now you can only
> use <image> in background-image, list-style-image, and border-image,
> and among those gradients will mostly be used in backgrounds.  But I
> believe that gradients will prove useful in the Filters module when it
> comes to fruition, and so I don't want to kill functionality that will
> prove useful there.
> 
> 
>>> (Returning to my earlier point about corner-centered gradients, you
>>> *could* do them by setting, say, "background-position:-50% -50%;
>>> background-size: 200% 200%;", but that's more complex and less obvious
>>> than just telling the original gradient "top left".)
>> 
>> How is it more complex? Everyone who works with backgrounds already knows the background syntax or is looking it up anyway. It is perfectly obvious that if you have an image of a centered radial gradient, then you would use background-position to move that center to the corner of the element. You don't need a special syntax to move it to the corner of the image instead.
>> 
>> You are just unnecessarily adding a bunch of stuff to the inside of the function that replicates what is already easily available. That is not a good thing. Keep background positioning within the background-position property; it isn't needed anywhere else. Then use whatever background-size you want. It seems like you want to discourage people from using the standard background properties to do what they were intended to do.
> 
> No, I just want to address use-cases in the simplest possible fashion.
> I believe it's more intuitive to generate a gradient at 30% than it
> is to generate a horizontal gradient and then rotate it 30%, and to
> generate a gradient that extends from the corner of a box to the
> opposite sides than it is to generate a gradient twice as large as
> needed and then position it into place.  In both cases I am more
> closely matching the type of workflow a designer would use with real
> images.  It is possible to embrace a new method of working with images
> when they're browser-generated and you don't need to worry about size
> over the wire or rotation computation expense, but why force people to
> do so?  The original concerns won't go away - people will still use
> ordinary images as well.
> 
> Plus, as I said above, I believe gradients will be useful with
> filters, where you don't have positioning/sizing/rotating controls (or
> if you do, they will be more cumbersome to work with, something you do
> in special circumstances, not something you use in the normal course
> of work).
> 
> 
>>>> * I would also propose that 'background-size:cover' would work a little differently for radial-gradient images, so that the gradient goes from center to corners ('background-size:contain' would go from center to edges).
>>> 
>>> That sort of interaction is why I prefer baking the controls into
>>> gradients themselves, rather than relying on hooks with other
>>> properties.  I think it results in an API that is slightly larger, but
>>> cleaner and simpler.
>> 
>> Nonsense. If I want to tile a background, I should be able to do it using the standard background image tiling properties.  I don't need another layer of complexity within the image generation, to multiply into where each color starts and stops. I just need a few tweaks to the background properties to handle a few special needs of gradients (specifically, those angles that don't repeat as seamlessly otherwise, and create bad results when used as-is).
> 
> I can possibly be convinced to embrace a background-repeat:gradient or
> similar, though I'd first have to see evidence of usefulness
> sufficient for me to reverse my earlier stance, and also be convinced
> that this would *not* be very useful for work with filters.
> 
> ~TJ
Received on Tuesday, 30 November 2010 00:11:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:34 GMT