Re: Gradient syntax proposal

On Sun, Aug 16, 2009 at 6:18 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Sun, Aug 16, 2009 at 4:53 PM, David Perrell<davidp@hpaa.com> wrote:
> > Brad Kemper wrote:
> > | ... You thinking you can just create a second
> > | background thats as small as that box? I was think of that too, but
> > | the gradation actually needs to keep going on all four sides of that
> >
> > I think I misinterpreted your comment (and you mine). I wanted
> confirmation
> > that, in an element with a background color but no border, it was agreed
> > that a gradient with these properties:
> >
> > background-size: calc(100%-200px) calc(100%-200px);
> > background-position: 50% 50%;
> > background-repeat: no-repeat;
> >
> > would be confined to its box and the background color (or an underlying
> > auto-sized gradient) would show as a 100px border. (At the time I was
> > thinking in terms of an argument about complexity, but I'm not recalling
> > what it was.)
>
> Yes, that's right.
>
> > (Interesting animation potential in being able to size a gradient box
> larger
> > than the clip box.)
>
> You mean like having a gradient slide just by changing the
> background-position?
>
> > Anyway, I'm all for simplicity, and it seems to me just this suffices for
> > <gradient-line>:
> >
> > [ <angle> | [ <bg-position> [ to <bg-position> ]? ] ]
> >
> > But this is just a valid subset of the current spec, right?
>
> Yeah, it just simplifies the <angle> production to remove the starting
> point and the inside/outside keyword.
>
> > I think that it would avoid possible confusion if <color-stop> stood for:
> >
> > [ <color> [ <percentage> | <length> ]? ]
> >
> > It just seems reasonable to have the required value come first.
>
> Ah, fine, I'll require that ordering.  It seems to be what we're all
> naturally using anyway.
>
> > <length> as an option is very important - how would I align a particular
> > band of gradient behind a headline without it?
>
> I agree.
>
> > Might be good to require <color-stop>s to be in ascending order. Less
> chance
> > for misreading someone else's stylesheet.
>
> Unfortunately, now that we allow <length>, it's impossible to actually
> require this.  Say you had "white, gray 16px, black 1em".  If the
> element has ordinary medium text and the user has normal font-size
> settings, the gray and black stop are on top of each other.  If the
> font-size is bigger or smaller than that, though, the gray will be
> before or after the black.
>
> > Or, since there is a difference
> > between blending two colors and overlaying one blend on a solid color,
> maybe
> > it does make sense to allow backtracking. Then you could call for
> rendering
> > a solid area, backtracking, and laying down a gradient. (Just a thought.)
>
> I really doubt backtracking is a desirable behavior in virtually any
> instance.  I'm comfortable with requiring you to use SVG to achieve
> that.
>
> However, having your stops change order is similarly disastrous.
>
> What I'm considering doing is requiring that your stops be in order,
> and saying that if a later stop specifies a position before an earlier
> stop, it's treated as being *on* the previous stop.
>
> That is, given colors like "white, yellow 20px, orange 30px, red 10px,
> black", the red stop would be moved to 30px.


If you are already requiring the the color-stops to be in order, what if we
said that when a <length> is used, it is a relative distance from the
previous color-stop?  This makes it possible to mix units without losing the
desired effect as would happen by collapsing color-stops as you propose.

In you previous example, it would mean that there was a 1em gradient to
black from the the previous gray color-stop, which was itself preceded by a
16px gradient from white.

I think this is quite reasonable as it is hard for me to understand why
anyone would want to express their color-stops out of order as it would be
quite a confusing case of obfuscation.


>
>
> This would also allow us to mix percentages and lengths again, as we'd
> remove the ability for the stops to switch order.  Say you set "white,
> yellow 100px, red 50%", and then the box shrunk to less than 200px
> width.  All that would happen is the blend from yellow->red would drop
> to instantaneous; you'd have 100px of white->yellow, then switch
> immediately to red for the rest of the image.
>
> I'd put in an advisory that it's usually a bad idea to mix unit types
> in color-stops, of course.
>
> This would also significantly clean up the language for determining
> the default value of the last stop.  I can just switch it back to
> being always 100%, and let the ordering rule take care of pushing it
> further out if necessary.
>
> I haven't made this change yet, but I think it may be a good idea.
>
> ~TJ
>