- From: Jeff Schiller <codedread@gmail.com>
- Date: Thu, 5 May 2011 10:40:27 -0700
- To: Patrick Dengler <patd@microsoft.com>
- Cc: Doug Schepers <schepers@w3.org>, www-svg <www-svg@w3.org>
- Message-ID: <BANLkTimnk6tdj8z1Yjj4erd03tg1+=W7sg@mail.gmail.com>
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 iceberg. 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 = someCircle.getPresentationAttribute("fill").rgbColor.red.getFloatValue(1); var g = someCircle.getPresentationAttribute("fill").rgbColor.green.getFloatValue(1); var b = someCircle.getPresentationAttribute("fill").rgbColor.blue.getFloatValue(1); 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, Jeff
Received on Thursday, 5 May 2011 17:41:14 UTC