April 29, 2004
SVG spec madness
It was claimed to me that the SVG 1.2
spec authors were mad. The evidence that was introduced was the SVGWindow interface
and the socket API.
Based on this evidence, especially on the lack of a way to specify in which
exact encoding that nice UTF-16 string is suposed to be sent to that socket
(should it be sent as UTF-16? this is to be implemented
interoperably?), on the attempt to expose the UA sheet (which need
not even exist as a real CSS stylesheet!) to the page, on the addition of
"window.evt" with its disastrous consequences for event handlers that trigger
other events, on the addition of document.window, something that no UA
implements, and with good reason, I have to agree that the SVG working group is
Stop reinventing the wheel to justify your own existence, folks, and focus
on what SVG should be—a (possibly scriptable) vector graphics format.
That's what the "VG" part is for, no? No need for sockets there. Let's not
have SVG suffer the fate of MNG, lying unimplemented or very partially
implemented because no one wants to drag about all the baggage it requires.
I would like to thank Ian for the illustrative examples of madness.
[Update: Ian points out that there
is in fact a way to specify some sort of encoding on the socket thing. The
spec doesn't say what happens if it's set, and setting it is optional. The
spec doesn't say what happens if it's not set, of course.]
Posted by bzbarsky at April 29, 2004 5:26 PM
Words fail me, and you're one month too late for April fools.
What raw socket APIs and DOM Level 0 APIs are doing in a vector graphics spec is so far beyond my understanding that I have great difficulty reading that draft. Not to mention all the lovely CSS properties they are introducing with names so generic that they'll almost certainly clash with CSS names down the road and make it impossible to implement SVG generically in a CSS UA.
One thing though, it looks like they do have a character set API thingy on the sockets interface.
They do, but it's not required and it's not specified what happens if it's not called... For that matter, it's not specified what happens if it _is_ called.
Oh my god, what a mess. I sometimes find myself wondering if the specification authors ever look at, or even know of, other specifications inside of W3C. Does the SVG authors know that CSS exists, and have they looked at it? What about talking to the CSS WG and have their input on the draft? And what about the DOM WG? Are they talking to them?
The communication inside of W3C seems non-existant in some cases, perfectly proven with SVG. Can they please just take a strole down the specification lane of W3C and have a look at what's there, talk to the other WG's, and not be so much in a bubble it seems as if they are now? Please?
As far as I can tell, the SVG spec authors have effectively forked CSS. So they do know it exists, they just feel they should control it.
Ian, how about requiring SVG properties and values to have -svg- until they've been approved and CR-ed by the CSS WG? :)
It is not all bad, is it?
At least they've chosen to use XBL, instead of Yet Another Binding Language.
Still wondering how the new spec is gonna affect Mozilla's XBL implementation though.
> It is not all bad, is it?
> At least they've chosen to use XBL
What they're calling XBL and what Mozilla implements bear only a passing resemblance to each other.
Hey, guys, it is mildly amusing to read all this stuff in the blog, but the better way to tell SVG spec authors that they are "mad" is firstname.lastname@example.org and to a lesser extent http://groups.yahoo.com/group/svg-developers/messages. (Of cousre reading these lists would answer some of the questions asked). Sorry if it meant to be purely private conversaion between people who like complaining, but have no intention to participate in the process.
(one of the "mad" guys).
P.S. Ian, at least you could have forwarded this exchange to your fellow group members ;-)
Well, the first thing that can be said is that it's a WD (ie. work in progress), and there's a list for comments. It's a bit strange to see people complaining that "communication inside of W3C seems non-existant" when they aren't themselves willing to make the effort to communicate. In the list of people that have posted comments thus far, I can see Ian who's a member of the SVG WG, and both him and fantasai were at an SVG WG meeting a bit over a month ago. I don't remember hearing either one of them complain there, or during the rest of the week.
In fact, the SVG WG communicates with the CSS WG, and I don't think I've ever seen the CSS WG express any of the concerns raised here.
As for talking with the DOM WG... what DOM WG? The DOM WG closed down. We coordinate with the DOM IG, but they can't publish Recommendations. Yet, the features are needed and someone has to get the work done. It is likely that those APIs will be handed over to the WebApp WG if there is one, but that's too far off. In the meantime, coordination with interested groups (both inside and outside the W3C) is taking place.
Some members of the WG feel that the "application" chapters should be required by SVG 1.2 but published separately. If that is your feeling, you are welcome to send feedback to that effect. But using a blog in that goal is going to be randomly successful at best.
Exposing the User/Client Stylesheet is an absolute requirement for SVG user agents, it is an impossibility to create an accessible SVG document if the user or client are not using a known stylesheet without having access to it. (and even then it's not really suitable since that requires scripting something which is not appropriate, but the non-scripting part is still inaccessible) Ideally we have no user stylesheets, and user agents constrained to use a specific UA sheet.
Ideally the _optional_ CSS in SVG should be dropped entirely, it does nothing but harm SVG.
The window object, that needs standardising, it's clear that wholly Document centric events have failed - we can see that, there's not a single UA implementation anywhere that does not use a window object - SVG User Agents should have an agreed standardised one, there's no point requiring an ECMAScript engine, if it doesn't require a known environment.
SVG is already a Scriptable Vector Graphics environment, and SVG 1.2 may not be where you want to go with that environment, but it is where most people who actually author documents in it do. Network interfaces are required, and the ridiculous Document Centric view of the DOM WG needs to be escaped.
Lets hope a Web-Apps WG gets created and can do this more sensibly, so far it seems the W3 deciding to create a seperate XBL standard has severely damaged implementation. XBL has no public draft available for discussion, it seems to me that the SVG WG's approach of having drafts in public where people can (and do!) discuss the flaws is a successful one. Of course it needs the comments to go to the right places.
> is email@example.com
I've read the archives of this mailing list, and it looks to me like posting to it would be a complete waste of my time -- I'd just get ignored. The blog comment was just a momentary frustration venting before going on to stop thinking about SVG (which I note has been conveniently renamed without changing the acronym).
To clarify, lest people accuse me of just making up reasons not to communicate, what I sort of expected out of the SVG WG is what the SVG WG charter < http://www.w3.org/2003/07/svgwg-charter.html > describes -- a "modular XML tagset usable in mixed-namespace documents" that "is a graphics format" and that allows "greater integration with other W3C specifications".
Instead, the SVG WG has been coopted to create a language for "graphical applications". More precisely, it has been coopted as a means of specifying a complete multimedia application development platform, whence come the various requirements that people feel are absolutely necessary (like network access) but are totally inappropriate in what SVG is supposed to be -- a graphics format.
Perhaps the SVG WG feels that SVG 1.0 and 1.1 already fulfill the need for a graphics format and there is no further need to work on that. Then the logical thing to do would be to disband and work on forming this WebApps WG which would have a somewhat more inclusive membership, instead of, as I said in my initial post, trying to justify the group's existence by working on a project utterly unrelated to what SVG 1.0 and 1.1 were (and worse yet, having the same name!).
Given such fundamental disagreements on the underlying goals of the WG, I fail to see how any post I made to the mailing list could possibly be taken seriously by them; certainly if I were in their position I would ignore people posting complaints about fundamental direction issues that have long since been decided.
P.S. I call bullshit on "Scriptable Vector Graphics," until you have the guts to update http://www.w3.org/Graphics/SVG/ and the charter to say so. The acronym can be expanded to all sorts of things, but the fact remains that scriptability is not a primary goal as described in the charter.
> I've read the archives of this mailing list,
> and it looks to me like posting to it would
> be a complete waste of my time -- I'd just
> get ignored.
Somehow your logic is the other way around. Until you post to firstname.lastname@example.org you will get ignored and if you post there you probably will get some replies on the substance of your post (as opposed to the comments on the venue you've chosen). Your choice of course.
Boris, can't you please summarize and post your comments to email@example.com? Then we'll see what the replies are, and can act and comment on those. I very much agree with the points you make in this thread, and hope the SVG WG listens to you and those that agree with you.
You just made it very clear to me that what the SVG WG is doing with the current versions of SVG is in breach with the charter, and it's wierd that the WG hasn't noticed this themselves. Either, the charter should be edited, or a new WG should be founded. The original goal of SVG is not being fulfilled by the work the SVG WG is doing now.