W3C home > Mailing lists > Public > www-svg@w3.org > May 2011

Re: agenda+ SVG 2 Features and Approach

From: Jeff Schiller <codedread@gmail.com>
Date: Thu, 5 May 2011 10:40:27 -0700
Message-ID: <BANLkTimnk6tdj8z1Yjj4erd03tg1+=W7sg@mail.gmail.com>
To: Patrick Dengler <patd@microsoft.com>
Cc: Doug Schepers <schepers@w3.org>, www-svg <www-svg@w3.org>
On Thu, May 5, 2011 at 9:13 AM, Patrick Dengler <patd@microsoft.com> wrote:

> The impediments to wide spread SVG adoption are (in order)
>        Integration
>        Performance
>        Education
> Our responsibilities as a working group should be rooted in solving the
> first two problems, and then tangentially solving the last.  Ideas on how to
> improve core SVG mean very little for the web if very few use them.   We
> must establish and agree upon our priorities.
> My recommendation is that we focus on a short, modularized "SVG
> 2.0=integration" specification, which should include how to, at the
> specification level, provide a declarative and programmatic path for high
> performing vector graphics that apply to key scenarios.  I thought we had
> agreed on this.

I whole-heartedly agree with the Performance impediment.

But I think another reason people go crazy for canvas is that it ultimately
can be much easier working directly in JS with your own data structures than
to deal with the DOM in all its verbosity and inconsistencies across
browsers.  Continuous improvements and support by modern browsers have made
inconsistencies better, but verbosity is still a huge problem.  I agree that
if SVG integrated better with HTML then we might see the situation improve
by libraries like jQuery automatically gaining support for SVG elements.

So I agree with Patrick on two of those impediments.

But I really think the W3C should attack the DOM as an API and make it suck
so much less.  There were many ideas thrown about for improvements in this
area a couple years ago but nothing seemed to come of it to my knowledge
(constructors? hello?).  There are a lot of graphics-specific things that
the SVG WG can work on here.  getIntersectionList() is only the tip of the

Here's a very simple example.  Why does my browser know how to convert "red"
into a RGB triple, but I have to write a conversion function in JS and carry
a huge-ass 147-entry map around with me?

Oh yeah, I could do this, I guess:

  var r =
   var g =
   var b =

which will work...

in some browsers...

Though the spec is deprecated...

And yes, I am prepared to be shamed into learning something new here, so
please fire away if something new has come along.  I can take it :)

Just my two cents,
Received on Thursday, 5 May 2011 17:41:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:24 UTC