Filling text with a gradient/image

On Sat, Aug 15, 2009 at 5:50 PM, David Perrell<davidp@hpaa.com> wrote:
> 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.)

Ok, at this point I have to admit that I don't understand what you
mean by "scripting issue", then.  Can you give an example?

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

Well, that's precisely what webkit does - you *do* have to make the
text transparent to see the effect.

I didn't actually give the issue a lot of thought in my first email,
but I've done so now.  You're completely right in that it's a sucky
way to deal with the issue.  If we want to hit this case, then what
we're really looking for is a way to allow text to be painted by an
arbitrary paint-server, just like background can be right now.

Your "stroke" property almost does that, but it's polluted by the
strange effect that it also automatically changes the display of the
border.  What you want instead is to take webkit's "text-fill"
property but extend it to accept an identical syntax to background
(right now it only accepts a color).

Borders are just strokes on the box, and SVG strokes can *also* accept
paint-servers, so if you want that effect, the way is clear.

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

Correct, that's why it's sucky.

~TJ

Received on Saturday, 15 August 2009 23:09:51 UTC