- From: Doug Schepers <schepers@w3.org>
- Date: Mon, 13 May 2013 21:18:29 -0400
- To: David Dailey <ddailey@zoominternet.net>
- CC: 'SVG public list' <www-svg@w3.org>, 'Kevin Lindsey' <kevin@kevlindev.com>
Hi, David- On 5/13/13 7:51 PM, David Dailey wrote: > > In fact similar things have been posted intermittently over many > years on svg-developers, with the use of extant methods to allow SVG > to pass cubic Beziers through user-defined points. Providing a > history of such posts would merely point to the recurrence of and > interest in the use-case. I thought this one was particularly elegant. > I would agree that having a method to allow the user-defined points > to intuitively correspond to the points that appear in the markup > makes sense. I'm not quite sure how Catmull-Rom does it better than > other approaches, Well, I just explained that Catmull-Rom has minimal impact to changes to the overall shape when you change a single control point; it only changes the segments immediately adjacent. To me, that's a huge benefit over e.g. the approach I just pointed to. > although one does need script to augment the SVG > curves to do this at present. > > It seems like the current approach to SVG is to just use script to do > everything and not to enhance SVG in any significant way, so I'm not > sure how helping script-challenged authors should be leveraged here > and not in other ways. The number, variety, and consistency of use cases is what makes the difference, tempered by the difficulty of implementation, and balanced by the difficulty and performance in doing it in script versus a native implementation. You just pointed out that this has many use cases, with many people asking for some solution along these lines. (No pun intended.) So, I think you answered your own question. > I feel a need to fuss from time to time, else SVG will be grown only > by people who work for browser developers. We're always interested in use cases from the wider community, and even specific solutions. We can't do everything, of course, but if we find a lot of demand for a new feature, and an elegant solution, we'll add it, regardless of where it comes from. Obviously, we won't add things to the spec that implementers flat-out won't implement, because that is a disaster to interoperability. Regards- -Doug
Received on Tuesday, 14 May 2013 01:18:48 UTC