SVG Working Group Teleconference -- 05 Jan 2009

<trackbot> Date: 05 January 2009

<scribe> scribe: erik

<scribe> scribeNick: ed__

ProgressEvents draft

<heycam> http://www.w3.org/mid/op.um15r1xnwxe0ny@widsithpro.lan

CMC: charles send us a reminder for us to review it

DS: we did have suggestions for that spec, right?

ED: yes, and those have been incorporated AFAIK

DS: shall we do a review of it?

CMC: sounds like a good idea to give it a quick readthrough

DS: noting that our changes were taken in and so on
... who wants to do the review?

<scribe> ACTION: ed to review the progressevents spec (http://www.w3.org/mid/op.um15r1xnwxe0ny@widsithpro.lan) and send comments to public-svg-wg [recorded in http://www.w3.org/2009/01/05-svg-minutes.html#action01]

<trackbot> Created ACTION-2388 - Review the progressevents spec (http://www.w3.org/mid/op.um15r1xnwxe0ny@widsithpro.lan) and send comments to public-svg-wg [on Erik Dahlström - due 2009-01-12].

<scribe> ACTION: DS to review the progressevents spec (http://www.w3.org/mid/op.um15r1xnwxe0ny@widsithpro.lan) and send comments to public-svg-wg [recorded in http://www.w3.org/2009/01/05-svg-minutes.html#action02]

<trackbot> Created ACTION-2389 - Review the progressevents spec (http://www.w3.org/mid/op.um15r1xnwxe0ny@widsithpro.lan) and send comments to public-svg-wg [on Doug Schepers - due 2009-01-12].

ISSUE-2194

ISSUE-2194?

<trackbot> ISSUE-2194 -- Syntax of some list-type attributes in SVG Tiny 1.2 incompatible with those in SVG 1.1 -- RAISED

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

CMC: someone noted on svgdevelopers that the glyphname, g1 and g2 attributes took semicolon-separated lists in 1.2T, but commawhitespace-separated lists in 1.1

DS: we should look at the cvs logs

CMC: may have been me doing list-of-<T> changes

DS: I like the standard solution comma-whitespace separated lists

CMC: i think we found that implementations accepted both syntaxes anyway

DS: e.g in viewBox we only allow space-separation, but we should allow commas there...trips people up
... another one is stroke-dasharray
... only allows spaces
... ASV allowes spaces, commas or both

CMC: the only place where you might want to disallow commas are values that are strings, where a comma can be part of the value

DS: right, so we should make that the exception

CMC: we should errata this particular one

DS: I think we might have an issue for core regarding this anyway

CMC: any objections to adding an errata for 1.2T to align with 1.1?

(none heard)

<heycam> trackbot, search issues for list

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

<shepazu> http://www.w3.org/Graphics/SVG/WG/track/actions/2135

DS: i don't find a corresponding issue to ACTION-2135... I'll raise one now

CMC: not everything is setup for 1.2T errata yet

<heycam> http://www.w3.org/TR/SVG11/fonts.html#HKernElementG1Attribute

JW: maybe have two erratas, one for 1.2T to allow comma-separation, and one for 1.1 that allows whitespace as the separator so that the syntax is fully aligned for glyphname, g1 and g2

DS: agreed
... we could also address this later (in core2) instead of issuing an errata for 1.2T
... ultimately what we want is to unify the syntaxes

<scribe> ACTION: CMC to create an errata for 1.2T with the first item being the comma-separation of glyphname, g1, g2 [recorded in http://www.w3.org/2009/01/05-svg-minutes.html#action03]

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

<scribe> ACTION: Cameron to create an errata for 1.2T with the first item being the comma-separation of glyphname, g1, g2 [recorded in http://www.w3.org/2009/01/05-svg-minutes.html#action04]

<trackbot> Created ACTION-2390 - Create an errata for 1.2T with the first item being the comma-separation of glyphname, g1, g2 [on Cameron McCormack - due 2009-01-12].

<shepazu> http://www.w3.org/2008/12/REC-SVGTiny12-20081222-errata.html

SVG 1.1 errata

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml

CMC: looking at the errata file, there are only a few left open as drafts
... JW have you had a chance to look at the zoomevent ones?

JW: not yet

<shepazu> http://www.w3.org/Graphics/SVG/WG/track/users/34802

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#reword-f5-tangents

ACTION-2362

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

<shepazu> ISSUE-2195

trackbot, close ACTION-2377

<trackbot> ACTION-2377 Announce the xmas break closed

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

CMC: DS did you have an action related to taht?

<shepazu> http://www.w3.org/Graphics/SVG/WG/track/users/38635

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

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

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#currenttranslate-currentscale-nested-svg

CMC: missing the suggested text there

DS: ok, will get to that one

CMC: ok, all assigned then...we can move on

clipping and pointer-events

DS: JW have you had a chance to look at that one?

JW: not yet

DS: (explains clipping and pointer-events, if reading minutes please see previous minutes where this was discussed)

<jwatt> is it just me having problems hearing?

CMC: the idea is to use the visible* values for clipped parts of the shape...so that if you had a clipped shape with visiblePainted you wouldn't get pointerevents on parts that were clipped away
... afterwards there were some comments on the www-svg list about this, from thomas deweese

<heycam> http://lists.w3.org/Archives/Public/www-svg/2008Nov/0064.html

DS: a brief summary is that he's afraid that it may make conforming content nonconforming
... cases that use clippath sort of like a fake window

CMC: right, for something like a scrolling window...without knowing what the content is exactly
... so you wouldn't be able to control that the pointer-events couldn't be captured on the clipped out path, because the content inside that ou don't control might use pointer-events=fill
... especially since that's the suggested way of doing pointer-events on invisible rects
... behaviour would change for those cases
... i think what thomas wants is a separate attribute/prperty to control events wrt clipping

<jwatt> how about I read through the thread and reply with my thoughts on the list?

CMC: yes, your input would be helpful

testsuite infrastructure

<heycam> ED: (talks about his work in removing svggen/, he has it working locally)

<heycam> ED: there's some platform-specific code in the testsuite scripts, e.g. use of xcopy

<heycam> ED: i changed it to use cp instead

<heycam> ED: this is for the 1.2T test suite

<heycam> ED: I can commit the changes

<heycam> ED: getting rid of svggen/ doesn't seem to be a major problem

<heycam> ED: i could commit the changes i've made to the script files, and not do anything about the rest, that way we still have all the generated files like before

<heycam> ED: this does change all of the harness files, because you change the links from svggen/ to svg/ instead

<heycam> CM: does that affect revision numbers in the slides?

<heycam> ED: no, it wouldn't affect it at all

<heycam> ED: we could regenerate the slides if we want, but we don't have to

<heycam> ED: i think the slides are generated from svg/ anyway

<heycam> ED: should i commit the harness files and remove the svg/ directory?

<heycam> DS: yes

ED: ok, will do that and close the action

CMC: the other listed actions in hte agenda are maybe more for core

DS: yes and no...we should adopt a test-first methodology
... we should have more tests, and we should solve that by writing tests as we move the spec forward
... the earlier we have test infrastructure in place the better

brief SVG in HTML

CMC: I should get the discussion going on the list again
... have an action to summarize previous discussion

<shepazu> http://lists.w3.org/Archives/Public/public-html/2008Dec/0128.html

<heycam> ED: we can look at that thread and discuss on thursday

<heycam> CM: also erik pointed out that the HTMLWG's proposal now works with SVG <font> elements

other open issues and actions

CMC: i wanted to make sure we have a procedure for issues
... we should make use of the raised for issues we should discuss
... and use open for when we have discussed them
... in tracker

DS: that leaves out bugzilla that some ppl have been using recently
... might be possible to have an automated process that raises the issues for the public
... bugzilla doubles our work for any given issue

CMC: some other groups only have an html form that people can fill things in
... for comments...I think it was xquery

JW: what's the problem with opening tracker to the public?

DS: might be extra work for systems staff

JW: i would like a public tracker

DS: if mozilla can provide resources to fix tracker that'd be welcome...
... I won't close down the public bugzilla until we have a public tracker

CMC: JW you are aware that the tracker is publicly readable, right?

JW: but you can't comment on the issue or raise new issues?

DS: no
... on the one hand bugzilla isn't well suited for spec stuff
... and it's duplicating effort
... we have to keep track of both
... or actually, the tracker, bugzilla and the mailinglists
... tracker is good for some things, but is perhaps too simple for some things
... not sure how difficult it'd be to take features from bugzilla and add them to tracker

JW: is tracker w3c internal?

DS: yes

- DRAFT -

SVG Working Group Teleconference

05 Jan 2009

Attendees

Contents