Re: [css3-images] Proposed Gradients changes

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 Monday, 29 November 2010 22:31:32 UTC