SVG Working Group Teleconference -- 15 Jan 2009

<trackbot> Date: 15 January 2009

<scribe> Scribe: anthony

Sydney F2F update

<ed> AG: f2f wikipage updated

AG: I've updated the wiki page with location and where it will be hosted

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/SydneyF2F2009#Sydney_SVG_F2F_Meeting.2C_Feb_16-20_2009

AG: I sent an email to the list

<ed> CL: will there be a phonebridge?

<ed> AG: will try to get that sorted out with the hotel

ISSUE-2201

ISSUE-2201?

<trackbot> ISSUE-2201 -- Return value of SVGAnimationElement.getStartTime unclear -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2201

ED: We got an email to the public list
... this is from the Mozilla team

<ed> http://lists.w3.org/Archives/Public/www-svg/2009Jan/0023.html

CL: It should throw an exception if it hasn't got a value
... what happens if you have multiple start times
... It needs to return a list doesn't it?

<ChrisL> should it return a list?

DS: In that case we shouldn't change it in SVG 1.1 and change it in Core
... just a thought

CMC: I don't know if it's best to change it to a list a this point

DS: We could add a new method

ED: I'd probably say we return the current start time of the first interval

DS: That's good

ED: Sort of makes it more useful
... that's the current interval you'd expect

CMC: Opera seems to return a couple of values
... Brian seems to think that it's not as useful to return the previous interval
... It should return the start time of current or start time of next if that's available

ED: I can have a look at the Opera code to see what it's doing

DS: I like your suggestion Erik

ED: Dunno how useful it is to have a set of start times/begin times
... we should probably try to clarify it for SVG 1.1
... we should investigate if that is adequate for future specs
... like return all the times
... the thing is you can't resolve all the times always

CL: If you can't resolve the times you could thrown an exception

ED: Probably most common when you have event based triggers

DS: Could return NAN

CMC: That's what we do in Batik

DS: Is this defined completely by us or SMIL?

CMC: I think it's by us

ED: Yes this is by us

<ed> http://www.w3.org/TR/SVG11/animate.html#InterfaceSVGAnimationElement

ED: So adding an exception when you can't compute a start time or when there is no start time
... does that seem like a good idea to add to errata?

CMC: I feel like returning a value of some sort

DS: Like NAN

CMC: I doubt there is much code that relies on this

ED: Sure, seems fine with me
... Are we fully agreed at what we should put in the errata item?

CL: So you propose returning the current interval value?

ED: Yes

CL: I agree to that

CMC: You can have end times as being indefinite, but maybe not begin times
... what about duration?
... do you think leaving duration is ok as it is or should it return a value?

ED: I would rather keep it as it is in that case
... it does say that it raises an exception if it is undefined
... I'd rather avoid it if we can
... so that probably argues for having an exception for getStartTime as well then

DS: Even if we introduced a new method to return values later we shouldn't worry about that now
... the only thing we need to resolve then is that it returns the current interval at the moment

<ed> "getStartTime: Returns the start time in seconds for this animation." -> "getStartTime: Returns the start time in seconds of the current interval for this animation."

RESOLUTION: We will create an errata that introduces an exception when the start time is unresolved but returns the start time in seconds of the current interval for this animation when resolved

<scribe> ACTION: Cameron to Create an errata item for getStartTime that it introduces an exception when the start time is unresolved [recorded in http://www.w3.org/2009/01/15-svg-minutes.html#action01]

<trackbot> Created ACTION-2401 - Create an errata item for getStartTime that it introduces an exception when the start time is unresolved [on Cameron McCormack - due 2009-01-22].

SVG 1.1 errata

ACTION-2362?

<trackbot> ACTION-2362 -- Erik Dahlström to backport the zero length path wording from 1.2T to this "Reword F.5 Tangents" erratum -- due 2008-12-04 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2362

ED: That action was on me

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0038.html

ED: I did some investigations and had some conclusions that I mailed to the list
... one of which was we haven't addressed zero length path issues that we raised
... the implementation notes say that it's path rendering only
... that it only applies for animation if there is a path to follow
... and there isn't any wording to back port

CMC: You said yesterday that there was an action on Andrew

ED: Yes, there was an action but it was never completed
... so we never got that wording
... comparing the wording there were some small changes
... but no substantial differences
... we could add a section that relates to animate motion and text path

CMC: So do you think we should take up that old action and make changes to both?

ED: It would seem a bit strange to add an errata to 1.1 and not address it in Tiny
... we should reword it slightly?
... it wouldn't be a very large change I guess
... and can perhaps be simplified to use the same code for all the different directionality handling?

CMC: Are we sure that the same behaviour is was we want?

ED: I think that was part of the action that Andrew had to change

CMC: I wonder if there are any tests that address this change?

ED: Perhaps

CMC: Do you think it needs investigation or just assume it?

ED: I think it might be best to test it first
... perhaps for text path
... I could take an action to make some tests for this
... I will close action 2632 given that there is no wording to back port

CL: May have already been back ported

DS: I do recall Andrew was going to look into a number of things for this action and that a number of resolutions were made
... can't remember what they were though

ED: It does say in the spec that you can go forward or backwards in the data until you find directionality

DS: It says that in 1.1?

ED: I think so, just reading it here

<ed> http://www.w3.org/TR/SVG11/implnote.html#PathElementImplementationNotes

ED: Second major bullet point
... the second bullet point under that
... and that bullet point is very similar to 1.2 Tiny

<ed> the bulletpoint that starts with "Certain line-capping and line-joining situations and markers"

DS: I think another related issue is arc segments that begin on the end point. Currently we say don't render anything
... smarter way of doing it is either have something arbitary or scan back and forth through the path data
... or scan back through the time
... might be a bit unrealistic

<scribe> ACTION: Erik to Go through the 1.2 Tiny test suite to check if there are any tests for zero length paths that test for directionality and add those to the 1.1 Full test suite [recorded in http://www.w3.org/2009/01/15-svg-minutes.html#action02]

<trackbot> Created ACTION-2402 - Go through the 1.2 Tiny test suite to check if there are any tests for zero length paths that test for directionality and add those to the 1.1 Full test suite [on Erik Dahlström - due 2009-01-22].

ACTION-2370?

<trackbot> ACTION-2370 -- Erik Dahlström to go through the e-mailing thread for errata item "Sizing of the outermost svg" and update the item discussion -- due 2008-12-08 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2370

<ed> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#bzwidth

ED: Errata item was empty I think
... I did add a few links to discussions
... I fixed XSL to fix a bug where if no author was listed it would omit the links
... I also added a few discussion links to this errata item

<ed> http://www.w3.org/TR/SVGMobile12/coords.html#IntrinsicSizing

ED: it seems we have fixed a few of the items that were asked about in 1.1
... one being intrinsic sizing

<ed> http://www.w3.org/TR/SVGMobile12/coords.html#InitialViewport

ED: and wording on viewPort
... so here is a case where w could back port wording if we wanted to
... we don't have any resolution, I couldn't find any in the minutes
... there was only some discussion on mailing lists and an action to create the item
... and also Boris seemed to be happy with what we had in 1.2 Tiny regarding this
... there doesn't seem to any minuted discussion this

AG: Did we want to discuss this at the F2F?

ED: We could, the wording could be taken across from 1.2 Tiny
... not sure if that's as easy as it sounds
... JWatt it would be good if you could take a look at the discussions

JW: I'd be happy to

ED: If you can give your comments on this for the F2F that's be great

<ChrisL> trackbot, staus?

<trackbot> Sorry, ChrisL, I don't understand 'trackbot, staus?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<ChrisL> trackbot, staus

<trackbot> Sorry, ChrisL, I don't understand 'trackbot, staus'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<ChrisL> trackbot, status

<scribe> ACTION: Jonathan to Take a look at the discussions in the errata item 2370 before the SYD F2F [recorded in http://www.w3.org/2009/01/15-svg-minutes.html#action03]

<trackbot> Created ACTION-2403 - Take a look at the discussions in the errata item 2370 before the SYD F2F [on Jonathan Watt - due 2009-01-22].

ACTION-2386?

<trackbot> ACTION-2386 -- Jonathan Watt to investigate the "SVGZoomEvent - Interface" errata item further -- due 2008-12-25 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2386

JW: Not very clear on what needs to be done there on that one

ACTION-2368?

<trackbot> ACTION-2368 -- Doug Schepers to propose wording for the change that addresses the errata item Current Translate Current Scale on nested SVG -- due 2008-12-08 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2368

DS: I sent an email about this

<shepazu> http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0040.html

DS: There are two alternatives, put it in the current defintion or at the top of the interface add some text

JW: I don't really like that wording
... having alot of nested SVG elements and then having zoom on one makes it tricky

ED: Having an SVG with a foreignObject that reference an SVG root

<ed> (and html around the svg elements in foreignObject)

DS: This is something we need to solve this general problem for foreignObject
... it acts as a barrier

JW: The foreignObject in Mozilla doesn't really act as a barrier

CL: If it's all in the one DOM then I agree there is no barrier then

DS: That was the action I had was to state that
... throwing an exception is also acceptable

ED: We could simply say it's undefined if you do that

<ChrisL> yes its different by inclusion and by reference

ED: and just define it for the root most SVG element

JW: I guess for me it's not very clear what interface would separate Zooming and Panning in a document

CL: The example to have Zooming and Panning on a document is you have a map
... in practice you may not want to do built in Zooming and Panning. But build in your own Zooming and Panning

DS: If we have our own defined behaviour it might get used more
... I'm also with Erik here and say it's undefined

JW: This is probably a good topic for the SYD F2F

ED: My suggestion is to define it for rootmost SVG elements then for nested it's undefined

JW: There is a distinction for SVG rootmost which is not the document element?

DS: Correct

JW: I'd say it's only defined for SVG document element

DS: again this is an issue that we are going to talk alot about
... If we are going to have this discussion we should go with Erik's suggestion

JW: That's what I'm saying is that we should say defined for document element

CL: In a standard SVG file the document element and the rootmost are the same

DS: I think that's what JWatt is saying is we can define it for standard SVG and leave it open for HTML
... but I wouldn't want to leave it open for that case

ED: It wouldn't effect the surrounding language though?
... you'd expect to affect the SVG only

CMC: I dunno if we've thought about it

DS: We shouldn't mandate what happens in other languages

CMC: I agree with what JWatt is saying that if you have SVG in HTML

JW: For what it's worth Mozilla will ignore it if it's not the document element

DS: So if you have an inline SVG in HTML and you change the current scale and current translate in that SVG it has no effect?

JW: Correct

DS: I would find that not very useful
... for example if have an SVG map in HTML and I had HTML controls for zooming and panning then I'd like to do that

ED: Seems like a good topic for a F2F

DS: I will make an amended version
... then we can discuss whether want rootmost and document element
... We had a discussion about the errata on root overflow
... but it looks like I didn't add that to the errata
... I would like to see it in the released errata

JW: Which one is this?

DS: The errata on root overflow

ED: I agree with what was agreed on

<shepazu> ACTION: add errata item for root overflow [recorded in http://www.w3.org/2009/01/15-svg-minutes.html#action04]

<trackbot> Sorry, couldn't find user - add

<shepazu> ACTION: shepazu to add errata item for root overflow [recorded in http://www.w3.org/2009/01/15-svg-minutes.html#action05]

<trackbot> Created ACTION-2404 - Add errata item for root overflow [on Doug Schepers - due 2009-01-22].

ACTION-2380

<ed> AG: probably no breakage from merging approved and accepted

<ed> ...the XSLT that generates the report needs to be checked though

- DRAFT -

SVG Working Group Teleconference

15 Jan 2009

Attendees

Contents

Sydney F2F update

ISSUE-2201

SVG 1.1 errata

ACTION-2380

Summary of Action Items

Scribe.perl diagnostic output