Re: Proper handling of SVG and rgba()

Is this a problem, if this rgba syntax is noted as a CSS property,
or is it a problem, if noted as a presentation attribute?
The first would be a task for the CSS3 draft to provide the new syntax
with the old rgb syntax as a fallback.

Because CSS has no version indication, there is no way for an author 
to indicate, that CSS3 syntax is in use anyway. 
Therefore for current SVG documents always CSS2.0 applies.
For CSS2.0 rgba syntax is invalid, I think the proper handling is to 
ignore it?

Well, for SVG presentation attributes this is not defined currently, indeed.
If an author notes this, this is a bug in the document.
And SVG 1.1 and SVG tiny 1.2 have different rules, what is to do with
errors in documents.
Therefore in general it is defined, what to do with it (even if many viewers
do not necessarily care much about error handling as defined
in different versions of a format ;o)

SVG tiny 1.2 has already the solidColor element with similar behaviour
and can be used as a paint server with both color and opacity information
together, but still both is animated separately.
Maybe it is more useful to implement, what is already specified and to
discuss rgba syntax for a future SVG 2.0 version instead of creating
new problems by enabling authors to use invalid syntax in older versions
creating correct (!) error messages in viewers familiar with the current
standards ;o)

Therefore maybe the reported 'bug' for WebKit could be counted as 
or mutated to  a vote to implement SVG tiny 1.2 and to discuss,
how useful rgba values are for SVG 2.0.


Received on Wednesday, 2 June 2010 15:53:58 UTC