- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Wed, 2 Jun 2010 17:50:44 +0200
- To: public-fx@w3.org, kliegs@chromium.org
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. Olaf
Received on Wednesday, 2 June 2010 15:53:58 UTC