- From: Chris Lilley <chris@w3.org>
- Date: Wed, 13 May 2009 00:03:12 +0200
- To: Cameron McCormack <cam@mcc.id.au>
- CC: public-svg-wg@w3.org
On Monday, May 11, 2009, 4:01:40 AM, Cameron wrote: CM> Discussing the CSS ‘content’ property recently, and how a corresponding CM> presentation attribute may conflict with the RDFa-ish content="" CM> attribute introduced in SVG Tiny 1.2, made me wonder what our strategy CM> is for presentation attributes. A good question. I originally proposed that all presentation attributes be in their own namespace as global attributes. This would prevent clashes and make the meaning unambiguous when used on elements in other namespaces. CM> Is it our intention to introduce a presentation attribute for every CSS CM> property that SVG specifications define? Yes. CM> Is it our intention to introduce a presentation attribute for every CSS CM> property that CSS specifications define, for which SVG defines CM> particular behaviour when that property is applied to an SVG element? Not necessarily, but possibly. Even when there is no presentation attribute, the property can still be applied using selectors. Obviously this is more relevant and useful in cases where many elements have the same value (eg in HTML and other document-like languages). CM> What do we do when a presentation attribute we want to introduce CM> conflicts with an attribute we already have? You mean, like fill and fill? Or width and width? CM> CM> Is it acceptable to have a CM> presentation attribute with a name different from the property? See my earlier comment about making them global attributes. Failing that, some sort of hard-coded pseudo-prefix hack is another opton, i suppose. Either way I suspect that implementations will assume that any attribute which matches a name on their known property list refers to the corresponding property. -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Tuesday, 12 May 2009 22:04:03 UTC