RE: [css3-images] simplifying radial gradients

I've lost track of which assertions are about the WD syntax and which are speaking to new proposals.

I think sample pages with "current syntax is __ to render xyz.png; I would prefer ___ syntax" might help.

I hope Tab is following this.  Perhaps he can repackage the current path of debate in a way that I'm able to consume.


On the larger discussion...

The impression I have from this latest branch is that now your concern is that the syntax isn't "rich enough" (allowing contain/cover to behave differently or have more options for off-center gradients) whereas the original proposal was to trim back the syntax as "too rich".


I think the current WD is a Goldilocks fit.  You can do off-center gradients to cover many scenarios.  You can use keyword ("implicit") sizing to react/adjust to aspect ratio to cover many scenarios.  If you combine "extreme off-center" gradients (the center point *on* a side), some of the keywords become less powerful / less interesting.  That doesn't make either capability bad.  It also doesn't mean that we have to choose between "remove them because they don't cover all use cases" and "expand them to cover all use cases".


-Brian


-----Original Message-----
From: Brad Kemper [mailto:brad.kemper@gmail.com] 
Sent: Tuesday, October 11, 2011 12:38 PM
To: Brian Manthos
Cc: Tab Atkins Jr.; Sylvain Galineau; Alan Gresley; L. DavidBaron; www-style@w3.org
Subject: Re: [css3-images] simplifying radial gradients



On Oct 11, 2011, at 11:13 AM, Brian Manthos <brianman@microsoft.com> wrote:

>> From: Brad Kemper [mailto:brad.kemper@gmail.com]
>> If I wanted a 'cover' gradient with a color stop at 50% of the height
>> and width, I would have to do similarly silly calculations. I think it
>> would actually be more useful for 50% to always mean 50% of the way to
>> the side, even if the gradient gradates to the corners.
> 
> I disagree.
> 
> For all 4 CSS gradient flavors today, color stop locations are relative to the gradient line (segment) length.  Changing it to something different is undesirable and confusing, IMO.

It's not changing how color stops work. For a contain gradient, 100% is to the sides, and 50% is half the distance to the nearest side. Having color stops greater than 100% are still allowed, and you can see them still in the corners if they are less than 141%. That doesn't change the gradient line, and with 'contain' the 50% point is still 50% of the gradient length, which is based on the width & height (until you start adding other parameters). 

> If you can accomplish what you want by changing the gradient line (segment) length for radial gradients, that might be interesting to consider.

Right now we have two different ways to change the gradient line length to get the exact same results. That's twice as many as needed. 

> Figuring that out with the current syntax can be very convoluted
>> because of this, and also because of the way every other parameter
>> (except color stops) affects the gradient length, often in unintuitive
>> ways.
> 
> I'm not sure I understand what you're getting at here.

I describe it in another email I sent this morning. Sorry I don't have quick access to the Lino to paste in here. 

> Position and size/shape parameters define the size and location of the ellipse (which is sometimes a circle) and thus the gradient line.  The color stops are placed along that gradient line.
> 
> The paragraph above (as I read it) suggests that gradient stops should be inputs to the gradient line (segment) length calculations, rather than applied after that length is determined.  I don't even know how that would work without introduce math cycles and other craziness.
> 
> I'm probably just misreading it.

Yes, you are.

Received on Tuesday, 11 October 2011 20:12:29 UTC