Re: Filling text with a gradient/image

Extending text-fill was how I wanted to fix this issue. background- 
clip: text is not a good solution (and is just in the code now for  
backwards compatibility).

dave

On Aug 15, 2009, at 6:08 PM, Tab Atkins Jr. wrote:

> 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 Sunday, 16 August 2009 19:26:02 UTC