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