Re: Reconsider SVG 1.2

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