Re: Gradient syntax proposal

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.

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

Received on Sunday, 16 August 2009 22:27:29 UTC