SVG Working Group Teleconference -- 18 Dec 2008

<trackbot> Date: 18 December 2008

<scribe> Scribe: anthony

<ed> 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: If you had that, then you say the SVG was a bit smaller and clipped the circle a bit

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 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> 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> 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 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> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml

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

<shepazu> 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> 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 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> http://www.w3.org/Graphics/SVG/WG/track/actions/2386

<shepazu> ACTION: jwatt to look into Mozilla helping sponsor SVG Open [recorded in 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

- DRAFT -

SVG Working Group Teleconference

18 Dec 2008

Attendees

Contents

Never-ending Clip Path Errata Item

SVG 1.1 Test Suite

Name Change of SVG Tiny 1.2

Errata Items

Break

Summary of Action Items

Scribe.perl diagnostic output