SVG Working Group Teleconference -- 12 Jun 2008

<trackbot> Date: 12 June 2008

<ed> hmm...

<shepazu> hmmm

<shepazu> I didn't

<shepazu> ooops... maybe I didn't send out the correction?

<shepazu> guess so

<scribe> Scribe: anthony

<leonardr> (I am STILL waiting for an operator to get me into the system :(

Nuremberg F2F (updated)

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Nuremburg_F2F_2008

ED: I got some information from Alex
... I added some information to me the meeting wiki page
... Alex said he'd find out more info for network, restaurants etc

<ed> http://www.w3.org/2002/09/wbs/19480/svgF2Fnuremburg2008/

ED: I've also opened up the attendance page
... most of the information has been taken from the SVG Open travel website

1.2 Testsuite

AG: I've generated the new testsuite
... which includes the minor Erik made
... I omit three tests
... two of them had zero sided reference images
... struct-use-06-t, struct-use-07-t
... and the third test I omitted is
... struct-common-201-t-debug

ED: with the struct-use ones couldn't we generate the reference images for them

AG: So they were but they had zero sized reference images
... I'm guessing this is still a beta release so we can sort those out next

ED: I see both still in draft
... So the next step is for Doug to push the changes out so they become public

DS: I will try to do that today or tomorrow

ED: I guess we should make it known that we published an updated version of the test suite
... might want to make the list of issues that's on the wiki known

AG: I agree

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_Overview#23_May_2008

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/View_the_list_of_known_issues

AG: Looks to me some of the require minimal effort to fix

ED: Yes some of them could have images patches for batik to render or png
... the revision numbers could be a bit tedious

<scribe> ACTION: Doug to publish the SVG test suite, announce its publication and the list of known issues [recorded in http://www.w3.org/2008/06/12-svg-minutes.html#action01]

<trackbot> Created ACTION-2062 - Publish the SVG test suite, announce its publication and the list of known issues [on Doug Schepers - due 2008-06-19].

SVG in HTML (cont.)

DS: We should finalise this and get it out into the public fairly soon

ED: I was just wondering if there was something left for us to discuss about the mail reply from last time
... just wondering about results and the rework

AG: So I've started converting the slides to HTML
... just haven't finished yet
... where should I commit it

DS: Contact me when you're ready and I'll try to have the structure done for CVS

ED: We can expect to have it in CVS by next week

AG: For sure

Pending errata items

http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0069.html

ED: We should go through these
... First one is about HKern
... it's a very minor change
... changing the grammar for the u2 attribute

http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#hkern_u2_definition_typo

ED: I think most implementations don't treat it as a number
... it is Category 3 because it may change stuff

AG: I don't have any problems with it

CM: I agree

RESOLUTION: We will move the hkern_u2_definition_typo to proposed status

<ed> http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#svgtextcontentelement_clarifications

ED: The next one is changing what exceptions we throw
... I also found after writing this
... it's kind of strange
... we have parameters that are unsigned long but for negative numbers they throw exceptions

CM: Seems like an easy thing to change while we are at it
... We should remove the exception

<ed> http://www.w3.org/TR/SVG11/text.html#InterfaceSVGTextContentElement

ED: For the text content element they all take unsigned long

CM: For the text interface they take character indexs
... they take unsigned

AG: conclusion

CM: Remove the exception

ED: So what ways is a negative value converted?
... guess it would depend on the unsigned long
... It's fine with me

AG: Are you going to make that change as part of the errata change?

ED: Sure I can do it
... we should probably change all the text methods as well
... so in that case we should keep it in draft for now
... so this will be part of ACTION-2010

<ed> http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#value_spacing_of_keySpline_syntax

ED: So next one is key spline syntax
... action is closed
... but open in the errata file

AG: It doesn't have a category either

ED: It's more a clarification
... I think this is a category 2 because it doesn't impact conformance
... the conformance is already in SMIL

AG: So I can add the category 2 and close the action item

RESOLUTION: Pending the changes to the value_spacing_of_keySpline_syntax we will move this errata item to proposed status

"keep <script> elements running only once"

ED: This was a thread on the group list

CM: This is me pointing out what Tiny says about script elements
... it's a bit different to what HTML says
... FF and Opera appear to be doing what HTML says
... even for SVG

DS: Is that the desired behavior

CM: I suspect it's that way because that's how things work in HTML
... legacy reasons
... I don't see any issues for using on or the other
... maybe if you wanted to reuse the same script element multiple times then you want to choose the SVG way
... I think it's a pretty minor thing
... not really stopping you from doing anything
... the two major desktop browsers do it that way

ED: I would like to do it the same as HTML
... I would favor us changing it the Tiny spec
... we don't have any test cases on it
... I'd be surprised if people are relying on it

CM: Or if people are relying on it they are probably relying on it working on the HTML way

DS: I'm trying to think of a reason to do it
... yes we should align
... either SVG or HTML
... there are some issues in which HTML should change, this isn't one of them

CM: I think I wouldn't be surprised if there was HTML stuff on it out there that relied on it
... working that way

DS: I'm fine with it changing

ED: Sounds like we all agree to have the spec changed

<scribe> ACTION: Cameron to fix the spec by aligning the script element behavior with HTMLs script element behavior [recorded in http://www.w3.org/2008/06/12-svg-minutes.html#action02]

<trackbot> Created ACTION-2063 - Fix the spec by aligning the script element behavior with HTMLs script element behavior [on Cameron McCormack - due 2008-06-19].

ARIA in SVG

DS: Gives some background of ARIA
... There was a big discussion of the syntax that would be used in HTML and SVG for ARIA
... we didn't like it
... but we agreed to use the aria- syntax

CM: From reading things I think that's what I think everyone agreed on

ED: That's what we agreed on

DS: So since that time, on the HTML list and on the appropriate WAI list
... there has been a lot of debate about it and on the TAG
... tried to push the name spaces syntax
... but if you recall
... after you agreed to it
... it was implemented in all 4 browsers some of which are SVG user agents
... this was the 'aria-*' syntax implementation
... So that TAG tried push name spaces syntax
... and there has been push back from WAI
... somehow it wasn't conveyed to WAI that this is what the SVG WG had agreed on
... I'd like to confirm that we agreed to the "aria-*" syntax

RESOLUTION: SVG will use the "aria-*" syntax for ARIA and tends to publish a module describing its use with the "role" attribute

ED: I found the minutes from the last F2F that we resolved to use the role attribute
... couldn't find the ARIA resolution
... I guess this answers all their questions
... were all the questions answered on the coordination call

<scribe> ACTION: Doug to send an email to WAI and SVG that we agreed on the ARIA resolution [recorded in http://www.w3.org/2008/06/12-svg-minutes.html#action03]

<trackbot> Created ACTION-2064 - Send an email to WAI and SVG that we agreed on the ARIA resolution [on Doug Schepers - due 2008-06-19].

www-svg feedback

ED: First one is
... ordering of effects with enable-background:new and filter on the same element

AG: So reading the spec it wasn't entirely clear

ED: I agree for the wording on how to generate the background image is not as clear as it could be

AG: Would be nice to have examples of the buffer
... at different stages

ED: We all seem to agree on the result of his example

AG: So I had a play with it and what opera is doing is correct

CM: The way it's written it's a bit unclear on what enable-background applies to

<scribe> ACTION: Erik to reword the enable-background property example [recorded in http://www.w3.org/2008/06/12-svg-minutes.html#action04]

<trackbot> Created ACTION-2065 - Reword the enable-background property example [on Erik Dahlström - due 2008-06-19].

<ed> http://lists.w3.org/Archives/Public/www-svg/2008Jun/0003.html

http://www.w3.org/TR/SVG11/filters.html#AccessingBackgroundImage

AG: So it's that bottom bit before the SVG Syntax example (Example enable-background-01) that's a bit confusing

ED: So the next on is

more BackgroundImage/enable-background issues

<ed> http://lists.w3.org/Archives/Public/www-svg/2008Jun/0007.html

ED: There is nothing really preventing you from doing that
... Batik seems to do what Robert is expecting
... and Opera seems to be clipping
... I think it's a bug in Opera
... Robert is suggesting to remove half of the sentence
... I don't think that's the best way
... I think it would be better to add some extra text saying that
... extending the background image past the viewPort
... is possible

AG: Should we make an errata for this? or will this appear in the module?

ED: My plan was for it to appear in the module

<scribe> ACTION: Erik to propose wording that clarifies the use of background image outside of the viewPort bounds [recorded in http://www.w3.org/2008/06/12-svg-minutes.html#action05]

<trackbot> Created ACTION-2066 - Propose wording that clarifies the use of background image outside of the viewPort bounds [on Erik Dahlström - due 2008-06-19].

<scribe> ACTION: anthony to add Eriks proposed wording to the Errata. Link to ACTION-2066 [recorded in http://www.w3.org/2008/06/12-svg-minutes.html#action06]

<trackbot> Created ACTION-2067 - Add Eriks proposed wording to the Errata. Link to ACTION-2066 [on Anthony Grasso - due 2008-06-19].

ED: The next on is about Question about SVG List replaceItem

<ed> http://lists.w3.org/Archives/Public/www-svg/2008May/0043.html

CM: I started to investigate it
... and then ran into a crash in FF
... [Explains issue]
... The spec doesn't say where the index is
... before or after the removal

ED: This is about the SVG path seg list
... only effecting the case where you are trying to replace the item in a list
... in the case we have with replace item on the same list
... some weird things happen

CM: So this is why the issues doesn't occur in normal DOM core lists

ED: The spec is not clear on this
... the index doesn't really say if the removal is before or after
... so it's not clear where the item will end up

CM: Do you think we should test different implementations?

ED: I think Opera and Batik are doing different things
... it would be nice to have a few test cases for this
... we should ask him for test cases on this
... we can't resolve it unless we know what implementations are doing

<scribe> ACTION: Cameron to test the SVG List replaceItem behavior of different implementations and report back [recorded in http://www.w3.org/2008/06/12-svg-minutes.html#action07]

<trackbot> Created ACTION-2068 - Test the SVG List replaceItem behavior of different implementations and report back [on Cameron McCormack - due 2008-06-19].

<ed> http://lists.w3.org/Archives/Public/www-svg/2008May/0033.html

ED: So the next one is
... Resolving IRIs for resource documents in SVG Tiny 1.2

AG: Looks a bit like an optimisation

CM: I think it's a reasonable thing to bring up
... maybe you can rely on caching to see if there is redirect still

ED: I'm not sure either

AG: Perhaps this is something we can come back to or discuss over email

- DRAFT -

SVG Working Group Teleconference

12 Jun 2008

Attendees

Contents