- From: David Perrell <davidp@hpaa.com>
- Date: Sat, 15 Aug 2009 13:03:45 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "Andrew Fedoniouk" <news@terrainformatica.com>, "Brad Kemper" <brad.kemper@gmail.com>, "www-style list" <www-style@w3.org>
Tab Atkins Jr. wrote: | > Seems reasonable. Besides the issue with remote CSS, it could | be frustrating if linear-gradient is not directly modifiable via the DOM. | | It's exactly as modifiable as any other CSS property. OK, not a killer issue. Not "exactly as modifiable...", but added complexity is from multiple background layers, not gradients per se. | 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? 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. (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?) 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). David Perrell
Received on Saturday, 15 August 2009 20:04:47 UTC