- From: Ernest Cline <ernestcline@mindspring.com>
- Date: Fri, 14 May 2004 01:25:07 -0400
- To: "Anne van Kesteren (fora)" <fora@annevankesteren.nl>
- Cc: "W3C CSS List" <www-style@w3.org>
> [Original Message] > From: Anne van Kesteren (fora) > > One question, why not something like: > > gradient() > > To be a part of <color> > > Some examples: > > color:gradient(bt,#000,#fff); > > background-color:gradient(lr,red,lime); > > border-top:thin solid gradient(rl,#333,#999); > > Etc. > > This would reduce the amount of properties that are introduced, > while making it "forward compatible" with new instances of <color>. There are several reasons why I did not use this approach. First, it would require something which I believe has not yet been done in CSS, namely permit functions as arguments to functions. e.g. gradient(tb,rgba(50%,50%,50%,0.8),hsla(60%,40%,75%,0.5)) Secondly, there are source languages such as SVG that adding gradients to <color> would complicate life for while giving them no new functionality. SVG makes the not unreasonable assumption that the value of a <color> will not vary depending upon the position. By making them a separate property, source languages such as SVG can ignore CSS gradients, while supporting any future monochromatic additions to <color> Third, directionality is specified for some linear gradients but not others. Adding it to border gradients would cause potential problems of how it would interact with the border radius properties, and given the potentially irregular nature of outlines, there is no good way to apply directionality to outline gradients. Altho, it is not specified in the proposal, these gradients are tied into the box model. When a source language completely or mostly ignores the box model, as does SVG, these gradients don't make sense.
Received on Friday, 14 May 2004 01:40:15 UTC