RE: Gradient syntax proposal

Tab Atkins Jr. wrote:
| A scripting issue?  No, I doubt it.

Really? Changing a known simple color spec to something that looks like a function (as Andrew F. suggests) could be an issue, especially for those using script libraries they don't understand. Background animation can be an issue when background-position becomes a comma-separated list instead of a single value. (I'm sure I'm not the only one to animate background-position of a parent element with padding to achieve an animated border.)

| I'm gradually coming around to Webkit's approach, which appears to be
| that "background" becomes a generic consumer for paint-servers, and
| can be applied to anything.  That's why Webkit has
| background-clip:text, which makes a background only fill the area that
| text normally does.  You could also add the value "border" to
| background-clip if you wanted to just fill the border region with a
| gradient.

Functionally, that sounds desirable. But background-clip: text implies you are clipping the background within the edges of the text. Since the text does not have a background and is above the background, this effect would simply hide the background unless the text is transparent. I doubt that's what you have in mind as it would not degrade well.

| 
| > (Of course, if you had text overlapping a border you'd have to 
| put it in a child element for contrast, but text getting lost 
| when overlapping a border is an issue with color, so what the hey?)
| 
| What I just proposed up above would avoid that.

And, if I read your intent correctly, change the general principles of color applying to text and borders, and background applying to a box, and text being in front of a background. Other than that, it's good.

David Perrell

Received on Saturday, 15 August 2009 22:51:41 UTC