- From: Brian Birtles <birtles@gmail.com>
- Date: Sat, 31 Jan 2009 22:28:15 +1100
- To: www-svg@w3.org
- Message-ID: <65fa1620901310328x5b6faa8dm353af0a93e2780fa@mail.gmail.com>
Hi, Ok, I think this resolution is satisfactory. I suspect getting the start time of the "next" interval (as proposed) could be more useful than the "previous" interval as I believe the start time of the previous interval can be recorded through TimeEvents, although admittedly registering for and recording events is more cumbersome. At the same time, we'll need to ensure that implementations resolve the "current" interval in the same fashion, particularly when complex syncbase relationships are involved. For example, given the following situation: <animate id="a" begin="5s"... /> <animate id="b" begin="a.begin+2s" ... /> Does a call to b.getStartTime() at the document begin return 7s, or throw an exception? My understanding of SMIL is that it should return 7s as section 3.6.3 says, "For a begin or end time to be resolved, any referenced syncbase value must also be resolved."[1] As a.begin, is resolved, so should be b.begin. Anyway, someone else here has surely looked into this more recently than I and may care to correct me, but in any case I would like to see a scenario involving syncbase timing in the test case. Perhaps we could also have a similar situation such as: <animate id="a" begin="click"... /> <animate id="b" begin="a.begin+2s" ... /> Where b.getStartTime() should throw an exception as it is unresolved? Thanks Cameron and Erik! Brian [1] http://www.w3.org/TR/smil-animation/#Unifying 2009/1/29 Erik Dahlström <ed@opera.com> > On Thu, 29 Jan 2009 07:00:07 +0100, Cameron McCormack <cam@mcc.id.au> > wrote: > > > > > Hi Brian. > > > > Brian Birtles: > >> I would like to revisit the specification of > >> SVGAnimationElement.getStartTime. As noted by Cameron McCormack in > January > >> 2006[1] the SVG 1.1 specification simply states that this method: > >> > >> Returns the start time in seconds for this animation.[2] > >> > >> However, it does not specify which start time in the case of multiple > start > >> times. Is it the start time of the current active interval? And if there > is > >> no current active interval is it the start time of the next interval or > the > >> previous interval? > >> > >> I have produced a small test of this behaviour[3] and note that Opera > 9.62 > >> appears to return the start time of the current interval, or failing > that > >> the start time of the next interval, or failing that the start time of > the > >> previous interval. > >> > >> I think it is necessary to define this behaviour more adequately. > >> Unfortunately Cameron McCormack's previous query went unanswered. Is it > >> possible to add an erratum specifying this behaviour? > > > > The Working Group discussed this and settled on the method returning the > > begin time of the current interval, where "current interval" is defined > by > > SMIL to be the active interval, if one exists, otherwise the next > > interval that will begin, if such an interval is known. If called when > > there is no current interval, then an INVALID_STATE_ERR DOMException is > > thrown. > > > > The erratum is here: > > > > > http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#getStartTime-return-value > > > > and will be published to the official SVG 1.1 errata page soon. The > > link to the test case is broken, but the test is at: > > > > http://dev.w3.org/SVG/profiles/1.1F2/test/svg/animate-dom-01-f.svg > > > > though note that it hasn't been reviewed yet. > > Having thought about this some more, and having looked at our code to see > what we do and why... > > Opera is currently returning start time for the current interval if it > exists, failing that the most recently ended interval if that exists, > failing that we return 'undefined'. > > The reasoning is that it's sometimes useful in script to know the last used > start time, even if there is no current interval. > > Some comments on the test: > - it would be nice if there were subtests for multiple begin values, with > and without 'indefinite' > - perhaps use 'lime' instead of 'blue' for pass? > > Cheers > /Erik > > -- > Erik Dahlstrom, Core Technology Developer, Opera Software > Co-Chair, W3C SVG Working Group > Personal blog: http://my.opera.com/macdev_ed > > >
Received on Saturday, 31 January 2009 11:28:53 UTC