W3C home > Mailing lists > Public > www-style@w3.org > October 2011

RE: [css3-images] simplifying radial gradients

From: Brian Manthos <brianman@microsoft.com>
Date: Tue, 11 Oct 2011 18:13:07 +0000
To: Brad Kemper <brad.kemper@gmail.com>, Tab Atkins Jr. <jackalmage@gmail.com>
CC: Sylvain Galineau <sylvaing@microsoft.com>, Alan Gresley <alan@css-class.com>, "L. DavidBaron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <9710FCC2E88860489239BE0308AC5D17F03494@TK5EX14MBXC266.redmond.corp.microsoft.com>
> 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.

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

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

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.
Received on Tuesday, 11 October 2011 18:13:38 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:05 UTC