W3C home > Mailing lists > Public > www-svg@w3.org > May 2012

Re: solidColor

From: Cameron McCormack <cam@mcc.id.au>
Date: Sun, 20 May 2012 13:35:38 +1000
Message-ID: <4FB8668A.9050600@mcc.id.au>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, SVG public list <www-svg@w3.org>
Bjoern Hoehrmann:
> Yes, and if everything that has a draft and an implementation in Webkit
> had a test suite and a Recommendation and would work in all the latest
> relevant implementations as you would expect from Recommendation and the
> test suite, we would be a lot better off. Note in particular that Webkit
> had an implementation of a CSS Variables proposal four years ago already
> and, as I recall it, dropped it due to lack of interest. If solidColor
> is working good currently, and if the SVG WG indeed plans to complete
> SVG 2.0 in half a year from now, CSS Variables do not really affect what
> should become of solidColor in SVG 2.0.

solidColor is implemented in Opera (because it was in Tiny 1.2) but not 
in other browsers.  It's much easier to implement than CSS Variables of 
course.  I think there is a lot of will to get CSS Variables or 
something like it up, and I don't know whether it's worth having a new 
SVG paint server element when CSS Variables also can do pretty much the 
same thing.  You wouldn't be able to target CSS Variables with SVG 
animation elements, but for that you could rely on the existing 
technique of a one-stop linearGradient:

   <linearGradient id="c">
     <stop stop-color="red"/>  ==  <solidColor id="c" solid-color="red"/>

which to be honest I don't find such a burden if you want to have a 
single point of definition for a colour in SVG right now.
Received on Sunday, 20 May 2012 03:36:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:35 UTC