- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Fri, 19 Dec 2008 08:09:49 +1100
- To: W3C SVG Public Working Group <public-svg-wg@w3.org>
http://www.w3.org/2008/12/18-svg-minutes.html
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
18 Dec 2008
See also: [2]IRC log
[2] http://www.w3.org/2008/12/18-svg-irc
Attendees
Present
ed, shepazu, ChrisL, heycam, [IPcaller], anthony, jwatt
Regrets
Chair
Erik
Scribe
anthony
Contents
* [3]Topics
1. [4]Never-ending Clip Path Errata Item
2. [5]SVG 1.1 Test Suite
3. [6]Name Change of SVG Tiny 1.2
4. [7]Errata Items
5. [8]Break
* [9]Summary of Action Items
_________________________________________________________
<trackbot> Date: 18 December 2008
<ed> <g clip-path="url(#clip)"><circle pointer-events="all"/></g>
<ed> <g clip-path="url(#clip)"><circle
pointer-events="visiblePainted"/></g>
<shepazu> <g clip-path="url(#clip)"
pointer-events="visibleStroke"><circle pointer-events="all"/></g>
<scribe> Scribe: anthony
<ed>
[10]http://lists.w3.org/Archives/Public/www-svg/2008Dec/0049.html
[10] http://lists.w3.org/Archives/Public/www-svg/2008Dec/0049.html
Never-ending Clip Path Errata Item
ED: Pasted in a link to my question
... if you have a nested SVG element that establishes a clipping
viewport
... you wouldn't expect to get mouse events outside that viewport
... I think a group element would be kind of the same
<ed> <svg><svg><circle></svg></svg>
ED: If you had that, then you say the SVG was a bit smaller and
clipped the circle a bit
<ed> <svg><g clip-path="url(...)"><circle></g></svg>
ED: I'd consider that to be similar to something like this
DS: I understand why you would expect that
... but I don't think it's actually a clip path right
... it is clipped
... Because they establish a new coordinate system
... they do a number of things that clippaths do not do
... I just see them as very different things
ED: I agree, but they have similarities
DS: So you're saying that any clipping whether it be from the
viewport establishing element or a clippath would behave similarly?
ED: To me I'm seeing it like a filter
... you're clipping something
... I'd expect only the events going through that clippath
... I'd expect whatever was in the viewport to be clipped or limited
by the clipping
DS: I guess it just doesn't seem intuitive to me
... You're going off the computed value. You might want to have
different things have different pointer events within the same group
ED: I think it would be useful to see what implementations are doing
... A group doesn't have a fill or stroke
DS: But we are working on computed values
ED: I'd like to see a couple of implementations doing one way
DS: I'll make a test
<scribe> ACTION: Doug to Test for event clipping when the clippath
is on a group [recorded in
[11]http://www.w3.org/2008/12/18-svg-minutes.html#action01]
<trackbot> Created ACTION-2384 - Test for event clipping when the
clippath is on a group [on Doug Schepers - due 2008-12-25].
SVG 1.1 Test Suite
<ed> [12]http://dev.w3.org/SVG/profiles/1.1F2/test/
[12] http://dev.w3.org/SVG/profiles/1.1F2/test/
ED: I moved the tests from the old archive to the new one
... I moved latest revisions
... it turns out that diffing these tests against the 1.2 Tiny tests
... has quite a few significant changes
... one of the problems is because we use a new template
... for Tiny 1.2
... doesn't have the exact same syntax for test case descriptions
... uses xml:id - small thing
... I had hoped for something better
... just wondering what's the best way to deal with this now
CL: We could XSLT out the content of the test
... all the stuff should be there
... it would be easier
... and let us focus on what the differences are
... then looking on the SVG root element
... to see what the differences are
... see if there is anything added
ED: One thing I was wandering was the SVG Fonts
... we used them all over in SVG Tiny 1.2
... but not in 1.1
CL: Reason for that 1.1 Tiny didn't let you use SVG Fonts
... but 1.1 Full did
... previously you had to have certain fonts installed
... and you'd get inconsistencies
... I think it should be ok to use SVG Fonts though
AG: I committed the new template to the archive
... which is similar to the SVG Tiny 1.2 template
... it uses SVG Fonts
... I like Chris's idea
ED: I agree we should probably use the new template everywhere
... so the question is would it be easier to make a script for it or
get XSLT to do the same
... I don't really mind either way as long as the end result is the
same
AG: I guess it'd probably be ok to use XSLT
CL: Once we have a working method for doing this
... we can just check in the new ones
... perhaps tag them before we commit the new ones
ED: My action to moving the test suite and diffing the test suite
... should I close the action
AG: I think that action is complete
... for this task we need a new action
ED: One thing I didn't move on purpose was move the scripts
directory
... I figured we'd probably only want one script to work on the test
suites
<ed> trackbot, close ACTION-2382
<trackbot> ACTION-2382 Move the 1.1 tests to public cvs, checking
diffs against the corresponding 1.2T tests closed
<ed> ACTION-2352
ACTION-2352?
<trackbot> ACTION-2352 -- Erik Dahlström to get rid of svggen/ --
due 2008-11-27 -- OPEN
<trackbot> [13]http://www.w3.org/Graphics/SVG/WG/track/actions/2352
[13] http://www.w3.org/Graphics/SVG/WG/track/actions/2352
ED: I guess I can continue my current action to try to rip out stuff
from the old scripts and try to merge with the new ones
... I'll add a note to that action saying that's also about merging
the scripts
AG: Keep in mind when you merge the scripts to base it on the new
template
<scribe> ACTION: Anthony to Make an XSLT to change the template of
the 1.1 tests to the new one [recorded in
[14]http://www.w3.org/2008/12/18-svg-minutes.html#action02]
<trackbot> Created ACTION-2385 - Make an XSLT to change the template
of the 1.1 tests to the new one [on Anthony Grasso - due
2008-12-25].
Name Change of SVG Tiny 1.2
DS: I emailed Bitflash and Ikivo off list
... they did respond
... Bitflash - didn't like the change for marketing reasons. They
didn't want to confuse their customers
... Ikivo - didn't mind the name chage however they didn't want
anything to slow down publication
... We have a commitment to JIS but also to OMA and JSR and they are
counting on SVG Tiny being published as soon as possible
... JSR already references SVG Tiny 1.2
CL: I suggested that we clarify in the status of the document
... we should clarify this relationship
... and say that future versions of this will be called Core
... and not Tiny
AG: Canon thinks that it is important to change the name
DS: I understand Canon's position but I'm also concerned about the
positions of the other members
Errata Items
<ed> [15]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml
[15] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml
<ed>
[16]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#svgzoomev
ent-interface
[16]
http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#svgzoomevent-interface
<shepazu>
[17]http://lists.w3.org/Archives/Public/www-svg/2008Dec/0049.html
[17] http://lists.w3.org/Archives/Public/www-svg/2008Dec/0049.html
ED: First one is the Zoom Event interface
... Reported by JWatt
... I think we were almost decided on this one
AG: I remember making the changes for it, but Andrew had an action
to investigate something relating to it
ED: So it might something in Tiny?
AG: I can't remember
ED: SVGZoom is an Event in SVG Tiny
... it's a Event
<ed> [18]http://www.w3.org/TR/SVG11/interact.html
[18] http://www.w3.org/TR/SVG11/interact.html
ED: there's no corresponding DOM2 category in SVG 1.1
<ed> ...for SVGZoom
ED: So they do seem to be slightly different
<ed> interface SVGZoomEvent : events::UIEvent {
<ed> readonly attribute SVGRect zoomRectScreen;
<ed> readonly attribute float previousScale;
<ed> readonly attribute SVGPoint previousTranslate;
<ed> readonly attribute float newScale;
<ed> readonly attribute SVGPoint newTranslate;
<ed> };
ED: This is what the IDL says not what the table in the
interactivity section says
CM: DOM2 Category doesn't always need to correspond to the interface
... but it would be better if they did
ED: Is it necessary that the Zoom event to inherit form the UI event
... one way to inherit just from event
... just wondering if there is anything in UI Event that is needed
CM: View perhaps
... you need a particular view
... not useful
EDS I guess that's fair enough
ED: So in Tiny 1.2 there is nothing on the SVG Zoom
... you only get the Event with the type of SVG Zoom
... but you don't have any properties like in 1.1
... the other thing is the bubbling canceling of the events because
they are similar
... so that would make it a bit difficult I guess
... question is do we need to bubble or should we errata 1.2?
... I can admit to not having used Zoom events that much
CL: Do we have content that depends on this?
... usually on the root element
ED: Yes
CL: Which kind of means it's not going anywhere
DS: If I recall correctly in SVG 1.1 it's only allowed on the root
... although I could be thinking of ASV
JW: That's how Mozilla does it. We don't implement zoom on anything
else but the root element
<jwatt> Mozilla only pays attention to attempts to set
currentScale/currentTranslate on the root element
DS: And that would actually correspond to how the current Zoom and
current translate on nested reflect the value of the root
<jwatt> so trying to change them on nested <svg> elements will be
ignored
<jwatt> i.e. we don't dispatch an SVGZoom event there
ED: Sounds more like it's better to say that it doesn't bubble in
1.1 to go with what we have 1.2 Tiny
DS: Sounds good
JW: Are there bubbling events in Tiny though?
ED: Sure there are a couple of those
<jwatt> so my concern with saying that SVGZoomEvent doesn't bubble
is that there could be content out there that relies on that
<jwatt> so things could break
DS: I guess that concern could be addressed by saying that event is
dispatched to the outermost/rootmost element in SVG 1.1
<jwatt> but saying in tiny that it does bubble isn't much of a
burden on tiny implementers
<jwatt> and avoids the risk of breaking stuff
ED: Saying that it does bubble in Tiny at this point is a bit late I
guess
... we could issue an errata
... I think those issues are the one we have to deal with
<jwatt> so I don't have a strong preference either way
ED: I don't think there are any more
<jwatt> but please use "document element", not "rootmost <svg>
element"
<heycam> jwatt, "rootmost <svg> element" has a particular defined
meaning in 1.2T
ED: Document element may include an element other than SVG element
... depends on how you implement I guess
... Opera does support zooming on particular SVG graphics
... not sure how we do Zoom Events
... We should definitely align 1.1 and 1.2
CL: I agree we just need to be careful about any effects the changes
my cause
ED: JWatt would you like to take an action to investigate this any
further
JW: Sure
<jwatt> ja
<ChrisL> tracker status?
<ChrisL> trackbot, status?
<scribe> ACTION: Jonathan to Investigate the "SVGZoomEvent -
Interface" errata item further [recorded in
[19]http://www.w3.org/2008/12/18-svg-minutes.html#action03]
<trackbot> Created ACTION-2386 - Investigate the \"SVGZoomEvent -
Interface\" errata item further [on Jonathan Watt - due 2008-12-25].
<ChrisL> action-2386?
<trackbot> ACTION-2386 -- Jonathan Watt to investigate the
"SVGZoomEvent - Interface" errata item further -- due 2008-12-25 --
OPEN
<trackbot> [20]http://www.w3.org/Graphics/SVG/WG/track/actions/2386
[20] http://www.w3.org/Graphics/SVG/WG/track/actions/2386
<shepazu> ACTION: jwatt to look into Mozilla helping sponsor SVG
Open [recorded in
[21]http://www.w3.org/2008/12/18-svg-minutes.html#action04]
<trackbot> Created ACTION-2387 - Look into Mozilla helping sponsor
SVG Open [on Jonathan Watt - due 2008-12-25].
<shepazu> dang skype
Break
ED: There will be no Telcons for the next 2 weeks
... we will have the next telcon on 5th Monday
<shepazu> Zakim won't let me rejoin
CL: I'll still be on holidays then, but I'll back for the Thursday
one
Summary of Action Items
[NEW] ACTION: Anthony to Make an XSLT to change the template of the
1.1 tests to the new one [recorded in
[22]http://www.w3.org/2008/12/18-svg-minutes.html#action02]
[NEW] ACTION: Doug to Test for event clipping when the clippath is
on a group [recorded in
[23]http://www.w3.org/2008/12/18-svg-minutes.html#action01]
[NEW] ACTION: Jonathan to Investigate the "SVGZoomEvent - Interface"
errata item further [recorded in
[24]http://www.w3.org/2008/12/18-svg-minutes.html#action03]
[NEW] ACTION: jwatt to look into Mozilla helping sponsor SVG Open
[recorded in
[25]http://www.w3.org/2008/12/18-svg-minutes.html#action04]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [26]scribe.perl version 1.133
([27]CVS log)
$Date: 2008/12/18 21:04:01 $
_________________________________________________________
[26] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[27] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51
Check for newer version at [28]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/to that clippath/through that clippath/
Succeeded: s/clipped the SVG a bit/clipped the circle a bit/
Succeeded: s/ED: Yes. I had tests made for it already but/ED: /
Succeeded: s/Mouse event/Event/
Succeeded: s/DS:/EDS/
Succeeded: s/Zoom element/root element/
Succeeded: s/ED: Sounds more like better to say that it doesn't/ED: Sou
nds more like it's better to say that it doesn't bubble/
Succeeded: s/light/late/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: ed, shepazu, ChrisL, heycam, [IPcaller], anthony, jwat
t
Present: ed shepazu ChrisL heycam [IPcaller] anthony jwatt
Found Date: 18 Dec 2008
Guessing minutes URL: [29]http://www.w3.org/2008/12/18-svg-minutes.html
People with action items: anthony doug jonathan jwatt
[29] http://www.w3.org/2008/12/18-svg-minutes.html
End of [30]scribe.perl diagnostic output]
[30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 18 December 2008 21:10:43 UTC