- From: Ronan Oger <ronan@roasp.com>
- Date: Wed, 17 Nov 2004 01:02:24 +0000
- To: Anne van Kesteren <fora@annevankesteren.nl>, www-svg@w3.org
On Wednesday 17 November 2004 00.09, you wrote: >I believe there is a conflict when the SVG specification is going to >specify new properties and change others without discussing this with >the CSS WG. This has been brought up to the mailing list before. Are you saying that the svg wg is changing the meaning of a CSS property? This *does* seem odd. If however you are, as I suspect, saying that SVG is using its own definitions to do something that css also does, you might do well to remember that svg does not *require* css. From my own experience, the svg community *tolerates* CSS as a cool shortcut for doing certain things, most of which it can do in a pure xml way. Fundamentally, imho, CSS belongs in SVG as much as SGML belongs in SVG. And raising too much of a pointless issue about the SVG community's desire to overlap some functionality also provided by css is begging to have people like me propose to remove CSS from the spec. css is not xml, and SVG is an XML dialect. The svg user community has had long discussions about the appropriateness of a non-xml language within an xml recommendation. The concensus was that css was worth keeping around in case it provides functionality we can not easily implement with SVG. This is in spite of it's clear inadequacies at the time, such as the difficultues with DOM-based style manipulations. As I see it, as long as CSS is not completely manipulatable from the DOM api, then it is not a *driving* issue for SVG 1.2. I have still not seen any examples of a "conflict" Please provide an example of a conflict that matches the strict definition of a definition that breaks the rendering of the svg. Ronan -- Ronan Oger http://www.roasp.com
Received on Wednesday, 17 November 2004 00:59:14 UTC