W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2008

Minutes, SVG telcon Thursday 18 December 2008

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Fri, 19 Dec 2008 08:09:49 +1100
Message-ID: <494ABC1D.6000108@cisra.canon.com.au>
To: W3C SVG Public Working Group <public-svg-wg@w3.org>




       [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


           ed, shepazu, ChrisL, heycam, [IPcaller], anthony, jwatt




      * [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

    <shepazu> <g clip-path="url(#clip)"
    pointer-events="visibleStroke"><circle pointer-events="all"/></g>

    <scribe> Scribe: anthony


      [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
    ... 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

    <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

    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
    ... I figured we'd probably only want one script to work on the test

    <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


    <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

    <scribe> ACTION: Anthony to Make an XSLT to change the template of
    the 1.1 tests to the new one [recorded in

    <trackbot> Created ACTION-2385 - Make an XSLT to change the template
    of the 1.1 tests to the new one [on Anthony Grasso - due

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




      [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

    <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
    ... 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>

    <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

    JW: Sure

    <jwatt> ja

    <ChrisL> tracker status?

    <ChrisL> trackbot, status?

    <scribe> ACTION: Jonathan to Investigate the "SVGZoomEvent -
    Interface" errata item further [recorded in

    <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 --

    <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

    <trackbot> Created ACTION-2387 - Look into Mozilla helping sponsor
    SVG Open [on Jonathan Watt - due 2008-12-25].

    <shepazu> dang skype


    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

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
    [NEW] ACTION: Doug to Test for event clipping when the clippath is
    on a group [recorded in
    [NEW] ACTION: Jonathan to Investigate the "SVGZoomEvent - Interface"
    errata item further [recorded in
    [NEW] ACTION: jwatt to look into Mozilla helping sponsor SVG Open
    [recorded in

    [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

      [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
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:40 UTC