W3C home > Mailing lists > Public > www-svg@w3.org > October 2007

[Bug 5191] Does SVGViewSpec track changes to the original SVGSVGElement?

From: <bugzilla@wiggum.w3.org>
Date: Sun, 14 Oct 2007 05:27:53 +0000
To: www-svg@w3.org
Message-Id: <E1Igw13-0004DX-D0@wiggum.w3.org>


           Summary: Does SVGViewSpec track changes to the original
           Product: SVG
           Version: SVG 1.1 Full
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: SVG Document Object Model (DOM)
        AssignedTo: schepers@w3.org
        ReportedBy: eseidel@apple.com
         QAContact: www-svg@w3.org

Does SVGViewSpec track changes to the original SVGSVGElement?


Does not make it clear if "currentView" returns an SVGViewSpec object which
tracks changes to the original (such as all the SVGAnimated* classes must do:
e.g. var width = rect.width; rect.width.baseVal.value = 10;
alert(width.baseVal.value); // expect 10), or if it is a normal "plain old
data" object which is a copy of what SVGSVGElement had and never changes?

Either way is fine, it just needs to be clarified.  if SVGViewSpec is just a
copy of the original and never changes once copied, that's easier to implement.

One possible implementation problem if it tracks changes to SVGSVGElement, is
what happens when that SVGSVGElement is removed from the document?  Do then all
of the viewPort, targetElement, preserveAspectRatio accessors then go

var svg = document.getElementById("mysvg");
var currentView = svg.currentView;
var svgParent = svg.parentNode;


alert(currentView.targetNode); // does this still work?

One particularly thorny side effect of them *not* changing to undefined is that
targetElement could be used to re-insert the SVGSVGElement, example:


Or equally fun to implement, I assume targetNode should at least update when
nodes come and go from the document/change ids?

Just looking for some guidance from you spec folks, thanks.
Received on Sunday, 14 October 2007 05:28:04 UTC

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