- From: Jeff Schiller <codedread@gmail.com>
- Date: Wed, 4 Apr 2007 19:50:20 -0500
- To: www-svg@w3.org
- Cc: "Chris Lilley" <chris@w3.org>, "Doug Schepers" <doug.schepers@vectoreal.com>
Chris/Doug, In reference to http://www.w3.org/2003/01/REC-SVG11-20030114-errata.html#Mention%20live%20values thank you for clarifying this. I had one question about SVGXXXList::initialize() that I don't think was addressed - does initialize remove the segment/item from any list that it was in previously? See the SVG WG's response here: http://lists.w3.org/Archives/Public/www-svg/2007Feb/0030.html Thanks, Jeff On 2/8/07, Doug Schepers <doug.schepers@vectoreal.com> wrote: > Hi, Jeff- > > This is your official response from the SVG Working Group. > > Jeff Schiller wrote: > > > > It's nearing the one month anniversary of this email - I have not yet > > received a response from the WG. > > Apologies for the delay, and thanks for the reminder. > > > > On 1/11/07, Jeff Schiller <codedread@gmail.com> wrote: > >> In the spec http://www.w3.org/TR/SVG11/paths.html#InterfaceSVGPathSegList > >> the insertItemBefore(), replaceItem(), and appendItem() methods all > >> mention that any item inserted into the list must be removed from any > >> previous list. However, a similar statement is not present for the > >> initialize() methods, which seems odd to me. > >> > >> Was this intentional or something missed in the SVG 1.1 spec? > > It was the decision of the SVG WG that this was merely an oversight, and > we could not see any reason the "initialize()" methods should not behave > in a similar manner to the other such methods. We have resolved to add > this to the errata for SVG 1.1. > > You may be happy to hear that we are making progress on the SVG 1.1 > Errata document, as well, and expect to publish a partial errata very soon. > > > >> Also, in SVGT 1.2, unless I missed something, the SVGPath interface > >> (http://www.w3.org/TR/SVGMobile12/svgudom.html#svg__SVGPath) is less > >> useful than SVGPathSegList (cannot insert, replace or remove segments > >> from SVGPath). Will the SVGF 1.2 be extending this interface ? > > By contrast, this was intentional. The SVG Tiny 1.2 SVGPath interface > was intended to be a serial, lightweight method of path construction > intended for small-profile devices. There is no current intention of > extending it in SVG Full 1.2, as that functionality will already be > available via SVGPathSegList. > > Regards- > -Doug, on behalf of the SVG WG > > Research and Standards Engineer > 6th Sense Analytics > www.6thsenseanalytics.com > mobile: 919.824.5482 >
Received on Thursday, 5 April 2007 00:50:26 UTC