- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Wed, 18 Jan 2006 10:14:21 +0100
- To: Jeff Schiller <codedread@gmail.com>
- Cc: www-svg@w3.org
On Jan 17, 2006, at 19:59, Jeff Schiller wrote: > I am not an implementor, I am a web developer who has had a little > experience developing with SVG 1.1. Can I ask the SVG WG or others > who may know the answer why the SVG 1.1 DOM was not brought into > SVGT 1.2? Will the SVG 1.1-style DOM be brought into SVG Full > 1.2? Given that the SVG 1.1 DOM provided strong typing, access to > individual components and avoided string parsing why was the new > Trait mechanism developed? > > Why is > > a) someCirc.cx.baseVal.value += 5.4; > > better than > > b) someCirc.setFloatTrait("cx", someCirc.getFloatTrait("cx") + 5.4); I think you meant "worse than" (or "not as good as"). The problem that people (not necessarily myself) had with (a) was the sheer number of classes required to represent it. First someCirc needs to be an SVGCircleElement (or failing that you need cx accessors on all SVGElements), which in turn means you now need to have a large bunch of SVGFooElement classes. Then you need a class for cx: SVGAnimatedLength. This also translates to an explosion of other classes, first all the SVGAnimatedFoo for each data type, and then the SVGFoo for the non-animated versions. And then in a number of cases (as in fact the above) baseVal needs to have its class, one for each non-simple type that can be animated. Even assuming Tiny, that's a big ugly bunch of classes that you've got to try to fit on a small phone. The footprint will be noticeable, especially since you're not on your own but part of a larger stack. The idea that all of the above could be of type "SVGMagical" and auto- generate the proper access by catching the default message was floated for a while, but it doesn't work because we have to also work on Java, which doesn't support object-orientation :(. Javascript doesn't either but it can be emulated by the back-end. Strawman (not necessarily representing my opinion): =================================================== Maybe there's a mid-point whereby we can drop Traits in Tiny 1.2, and just leave it as an advantage of the folks who use JSR-226. Of course, we don't lift anything from the full SVG DOM either, as that would be too heavy. Instead, we stick to getAttributeNS and setAttributeNS but specify require (or very strongly recommended) normalisation of the values so that what is returned is easiest to process and scripts don't have to handle the endless variety of options that may be available to them. That, and perhaps a few helpers, e.g. to parse a colour into an SVGColor. This sort of meets the requirement for typed access midways (data is normalised and can be upgraded to type easily) while reusing mostly what already exists. It has the default of inefficiency (you'll be converting to and from string every other line of code). Thoughts? Answers on a postcard. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Received on Wednesday, 18 January 2006 09:14:33 UTC