Re: Reconsider SVG 1.2

Ronan,
Thanks for making your points so that those people who have recently joined 
this forum "to help the SVG working group make the spec perfect", and who 
have themselves not yet had the opportunity to develop real-life SVG web 
sites, can be educated. It is good that you have stepped in to make these 
comments, given your multiple years experience as a full-time SVG solutions 
developer and prominent member of the community. (How many years -  five?)

I have heard what you say about the role of CSS to SVG from all of the SVG 
solutions developers I have encountered and experienced the same things 
myself. There probably are some real-world SVG solutions out there that use 
CSS stylesheets, but I can't remember of any. I have a unique perspective 
on the SVG industry because so many companies who do things with SVG end up 
coming to Adobe to talk about partnership, and I often end up in the room 
to watch these companies proudly demonstrate their SVG solutions. Also, 
Adobe does quite a bit of its own SVG content development. In addition to 
seeing large parts of the SVG community in action, I have also been in the 
trenches of the language definition process, particularly during the SVG 
1.0 phase when I was editor and most of the language was defined. Long ago, 
I was in the midst of the (sometimes very heated) discussion about whether 
SVG should use CSS at all.

My personal opinion is that:

1) It was a mistake for SVG 1.0 (with the emphasis on "1.0") to support CSS 
at all, even on an optional basis. Virtually no real-life SVG content uses 
CSS today. (As you point out, CSS is an optional feature in SVG, and the 
Tiny profile does not allow it at all.)

2) However, we should leave CSS support in SVG, at least for now (i.e., SVG 
1.2), because it might prove advantageous to the W3C within its Compound 
Document (CDWG) activity (just recently started). One of the goals of the 
Compound Document activity is to allow intermixing of different 
presentation namespaces within the same file (XHTML, SVG, XForms to name 
three) and to define the detailed processing model when this occurs. Since 
CSS is a necessity if you want to define the presentation of XHTML, 
therefore it is critical to define what happens to the SVG elements in the 
presence of CSS. It might help that the SVG working group already figured 
out how the cascade works in SVG and which properties from CSS apply to SVG 
elements.

Jon

At 05:26 PM 11/16/2004, Ronan Oger wrote:

>On Wednesday 17 November 2004 00.09, you wrote:
> >Ronan Oger wrote:
> >
> >> I have been hearing this css conflict noise for some days now and
> >> would like just one single example of a potential conflict.
> >>
> >> To be clear, a conflict is when a css snippet breaks an SVG snippet..
> >
> >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.
> >
>
>A conflict is not the same as redundant definition or a different way to do
>things. Please be careful with your terms.
>
> >
> >> Anyhow, if I had to choose between svg and css, I'd elect to have css
> >> bumped. It's a redundant, non-xml vocabulary that brings little to me
> >> except implementation headaches.
> >
> >I believe CSS is the most single sucessful thing the W3C ever standardized.
> >
>
>That's wonderful. And irrelevant. CSS is not XML. Period. It is not needed.
>
> >
> >> Not only do I have to support XML and scripting, but I also have to
> >> have another parser for css... I find that cool, but pointless.
> >> Whoever came up with the idea of adding css to svg should be forced
> >> to implement it in a browser themeselves.
> >
> >* Anne wonders who came up with the idea to let SVG do more than just
> >being a Scalable Vector Graphics specification.
> >
>
>I think it was adobe. And I appaud their decision which saved the SVG 
>standard
>from oblivion. The chief reason SVG is around today is its usefulness as a
>web application presentation layer, replacing the awkward html+css
>alternative.
>
>Anne, have you EVER written an SVG document? For someone so loud about the
>failings of SVG, I find little SVG content *offered* by you to back your
>strong points.
>
>Please leave the musings about what is needed and what is not needed in 
>SVG to
>the SVG experts and the SVG users.
>
>As an SVG developer of 5 years working with SVG for a living, I  would rather
>have SVG without CSS than SVG pointlessly constrained by CSS. SVG developers
>like the shortcuts that CSS provides, but SVG developers do not *NEED* css.
>
>What I *do* need, though, as a seller of SVG based solutions, is the wrap-up
>of the SVG-1.2 recommendation so I can stop waving my arms when promising
>"future support for x".
>
>--
>Ronan Oger
>http://www.roasp.com

Received on Wednesday, 17 November 2004 03:54:58 UTC