Re: Gradient syntax proposal

On Sat, Aug 15, 2009 at 3:03 PM, David Perrell<davidp@hpaa.com> wrote:
> | For example, say you want text to be colored as a gradient.  Is that
> | on a per-glyph basis, a per-line basis, or a per-element basis?
>
> On a per-element basis, certainly. And if that's the only way to target in CSS, where's the ambiguity? Ambiguity exists where specifications aren't clear.
>
> So, how to specify gradient text? If linear-gradient were some special kind of color, then spec'ing would be simple. But wouldn't color functions create a scripting issue?

A scripting issue?  No, I doubt it.  It's just that there are
purposely few-to-no controls over how colors are used.  This is on
purpose - colors are extremely simple and you don't *need* that kind
of power.  But you *do* need those powers when you start adding
complexity, like gradients.  If you stretch and call gradients a
color, they're still different from 'normal' colors in that they have
a direction, and some notion of a length.  They're 1 or 2 dimensional,
compared to normal colors being 0-dimensional.  That's why it's best
to treat gradients as images - images are 2-dimensional, and so we
*already* have the sorts of controls you need in place.

> How about a new property 'stroke', a counterpart to 'background', that applies to everything ordinarily painted with 'color'. It would apply to borders AND text, with stroke-color, stroke-image, stroke-clip, etc. This would be simpler and more general than applying gradients specifically to individual border segments.

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.

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

> IMHO, all possible applications of every feature should be considered before finalizing any one. I'd hate to see CSS become an ad hoc patchwork of inconsistencies, like HTML became with Netscrape (which, of course, gave impetus to adoption of CSS).

I agree mostly.  It's no good when a feature gets poisoned by
finalizing it in a too-strict form.

~TJ

Received on Saturday, 15 August 2009 20:39:28 UTC