W3C home > Mailing lists > Public > www-style@w3.org > April 2014

Re: [css-images] gradient midpoints

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 17 Apr 2014 11:07:36 -0700
Message-ID: <CAAWBYDBVeFZrPPVuwM3idMNXk78TgguX5hX_i1XYS-Pt6=su9Q@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: www-style list <www-style@w3.org>
On Thu, Apr 17, 2014 at 10:58 AM, Rik Cabanier <cabanier@gmail.com> wrote:
> At the CSS F2F in Seattle, we decided to use exponential interpolation
> function to calculate the color ramps when there is a gradient midpoint. [1]

Don't worry, I've got this tracked to edit in:
https://github.com/tabatkins/specs/issues/29  ^_^

> Right now the spec [2] states:
> Similarly, the color of a color stop can be omitted. The causes the color to
> be automatically computed to halfway between the two surrounding stops, so
> that the "midpoint" of a transition can be easily adjusted.
> which specifies linear interpolation that results in banding.
> Could we add the right formula here?
> To calculate a color C between:
> C0 = color stop on the left
> C1 = color stop on the right
> N = value between 0 and 1 describing the distance of the midpoint between C0
> and C1
> X = value between 0 and 1 describing the distance of the C between C0 and C1
> The formula is: C = C0 + pow(x, log(.5)/log(X)) * (C1 - C0)

This formula isn't correct, but I know what you mean. ^_^  (Your
CodePen had useful code in it.)

> The spec also has this wording:
> If multiple stops in a row lack a color, they space themselves out equally
> in "color space", giving more control over the smoothness of the transition.
> Is this to add multiple midpoints?

It has nothing to do with the conception of "midpoints" that you
proposed at the f2f.  The current state of the spec (since I haven't
yet edited in the f2f resolution) has the behavior of a color stop
being symmetrical between missing a position and missing a color -
either way, you just fill in the missing values by spacing them out
between the surrounding specified values.

Received on Thursday, 17 April 2014 18:08:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:21 UTC