W3C home > Mailing lists > Public > www-svg@w3.org > November 2009

Minutes, 19 November 2009 SVG WG telcon

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Fri, 20 Nov 2009 08:53:01 +1100
Message-ID: <4B05BE3D.3070601@cisra.canon.com.au>
To: www-svg@w3.org
http://www.w3.org/2009/11/19-svg-minutes.html

---

    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

19 Nov 2009

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDec/0041.html

    See also: [3]IRC log

       [3] http://www.w3.org/2009/11/19-svg-irc

Attendees

    Present
           ed, Shepazu, jwatt, anthony

    Regrets
    Chair
           SV_MEETING_CHAIR

    Scribe
           Jonathan Watt, anthony

Contents

      * [4]Topics
          1. [5]Roadmap
          2. [6]IntersectionList
          3. [7]Deprecating CSSValue
          4. [8]CSSUnit and Values
      * [9]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 19 November 2009

    <ed> [10]http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap

      [10] http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap

    <jwatt> Scribe: Jonathan Watt

    <jwatt> scribenick: jwatt

Roadmap

    DS: the table is really out of date

    AG: Compositing could go to LC in Feb/Mar I think

    DS: how about May for CR then?

    ED: the earlier there's a testsuite the better

    DS: PR Aug; Rec Sep

    AG: sounds fine

    ED: so Filters
    ... I'd prefer to have a couple more drafts before going to LC
    ... especially since i'd like to put in the CSS canned filters, and
    perhaps new syntax as well
    ... probably a few more primitives

    JW: I'd like to revisit the need for authors to specify filter
    regions, and filterRes

    ED: I would like to resolve that too
    ... I think Sep for LC

    DS: I think that's pretty far away

    <anthony> Scribe: anthony

    <scribe> scribenick: anthony

    DS: Let's say June 2010 for Use Case & Requirements for Layout
    ... He'd probably be working on the spec at the same time
    ... so let's say July 2010
    ... for FPWD
    ... then LC October
    ... that would put CR in December
    ... and PR in June 2011
    ... Masking and Clipping?

    AG: Who is doing that anyway?

    DS: Emmons

    ED: It's basically dealing with coordinate systems

    DS: don't really need a lot of changes

    <ed> we have some issues raised on masks/clippaths, we should
    address those... and pinnedclip maybe

    DS: I'm going to give it the same time line as Compositing

    <ed> ...and perhaps use of clip/mask in CSS/HTML

    ED: Not convinced we need a separate module for it

    DS: You mean do it as part of SVG 2.0 instead?

    ED: Yeah, although it might be good for other specs

    DS: Media Access Events is the same, it's pretty much done
    ... just need someone to finish it
    ... Paint Servers
    ... I'm going to put that on the same time line as filters
    ... what do you think?

    ED: Who is the editor for that?

    DS: I would say Chris

    ED: The guy from Inkscape

    DS: Print spec

    AG: Print will become Colour Management and Pagination

    DS: I couldn't find a Pagination spec

    AG: Currently there is none

    ED: That line needs to be split up
    ... into two lines

    DS: It went to LC in September?

    AG: Yes, something like that

    <ed> [11]http://www.w3.org/TR/SVGColor12/

      [11] http://www.w3.org/TR/SVGColor12/

    ED: Looks like FPWD

    DS: And it was October
    ... shouldn't it be called Colour Management?

    AG: Yeah you're right

    DS: Chris didn't think that there was that much more to do on the
    spec
    ... try to get Colour Management to LC in December
    ... For pagination I'm going to say May 2010 for FPWD
    ... LC December 2010
    ... CR March 2011
    ... PR October 2011
    ... Rec December 2011

    <ed> [12]http://www.w3.org/TR/SVG-Transforms/

      [12] http://www.w3.org/TR/SVG-Transforms/

    <ed> 20 March 2009

    <ed> FPWD

    DS: Transformations, LC in July

    JW: If we combine with CSS is that a new document?

    AG: October 2010 CR

    DS: May, June for Rec?

    AG: Ok

    DS: Vector Effects
    ... I'm going to move those dates all back 1 year

    JW: Should turn the dates into links to specs
    ... do you think we can implement Vector Effects, ED are you happy
    with that?

    ED: Not sure exactly how cheap some of the operations are

    DS: Will Firefox implement this?

    JW: The reason I ask is stroking a stroke is something unknown to
    current rendering libraries
    ... I think it's going to be harder to implement than it looks

    DS: The feature set probably wont change that much
    ... but the basic syntax and what it allows you to do seems pretty
    straight forward to me
    ... do we think the language itself is going to change?
    ... the process allows us to go to CR
    ... and if we need to change it then go back to LC

    ED: Maybe push that back a bit more
    ... I'd say the same time as filters

    DS: Webfonts

    ED: Not sure what that is about really

    DS: I'm going to say move that to CSS

    ED: Chris will probably know more about that

    DS: SVG 2.0 moving all the dates to 2011

IntersectionList

    <ed>
    [13]http://lists.w3.org/Archives/Public/www-svg/2009Nov/0015.html

      [13] http://lists.w3.org/Archives/Public/www-svg/2009Nov/0015.html

    ED: That's the start of the thread
    ... the node lists are static
    ... and that's what we say in the 2nd edition spec
    ... the second parameter to the method is it the root of the subtree
    to search or is it something else?
    ... I'm pretty sure Opera implemented to be the subtree
    ... the results are limited to be the children of the subtree
    element

    DS: That seems kind of strange to me

    JW: Limiting it to the subtree?

    DS: Yes

    JW: Why?

    DS: Where is it likely that someone will use these things
    ... and I just don't see where moving it to a subtree makes sense
    ... from a performance stand point it makes sense
    ... but I don't know why someone would want to limit it to a subtree

    JW: So a joining area of a drawing application
    ... so if can restrict it
    ... it makes sense

    DS: Ok yeah, you're right

    ED: Do you think it's a good idea to clarify it to be the subtree
    root?

    DS: Which bit are saying? getIntersectionList?

    ED: Yes

    DS: It doesn't say that

    JW: I don't see it makes sense any other way than what Opera has
    done

    <ed> [[referenceElement -- If not null, then only return elements
    whose drawing order has them below the given reference element.]]

    DS: There are two interpretations of it
    ... I've never seen 'below' to define a subtree
    ... I think what they meant in the spec is rendering order

    JW: I think rendering order doesn't make sense and no one has done
    that

    DS: One thing you mentioned which is important
    ... is collision detection

    ED: Collision detection is pretty common for games

    JW: In some 3D games I've seen, the character goes halfway through
    an object before the collision is detected
    ... in that case they are not using the geometry

    ED: Do we want to resolve that it is a subtree

    DS: It is clearly subtree
    ... that is not the intent of 1.1
    ... we can change it for 2.0

    ED: I don't agree with that
    ... that's not the way I read it

    DS: ASV6 did it the way I described
    ... I don't mind us changing it, I don't think that was the original
    intent
    ... and I'm not sure form a process point of view if we can change
    it that way

    ED: It is ambiguous at the moment
    ... what we have not is not interoperable at the moment

    JW: I'd have to side with DS about what it means
    ... but what they describe it is difficult to implement
    ... We are not doing any more errata for 2nd Edition are we?

    ED: I wouldn't mind putting something in
    ... we already have test cases

    DS: We could ask Chris, JF or Dino if we want to clarify
    ... In line with JW was saying, we should just define what we think
    is correct
    ... the way it's defined in 1.1 is not the we want people to do it
    anyway
    ... let's just start over
    ... and not fix the mistakes of the past
    ... at some point we have to move on

    ED: Batik probably does it as well
    ... since CM wrote a test (that I'm reviewing) for it
    ... If you think it's not worth it and if you're willing to take the
    risk of different interpretations of it

    DS: What if put the question to the list?

    JW: I don't see any reason to restrict to a rect. I'd push for a new
    API
    ... maybe getIntersectionList could stay there and call into the
    more complex one

    ED: People on the list seem to prefer the subtree model

    DS: I think it's a waste of time to fix stuff that's broken from the
    start

    JW: ED is going to do it. Then he can get on with reviewing tests

    DS: Are you the same as Batik on tests?

    ED: Not all of them

    <scribe> ACTION: Erik to Investigate getIntersectionList and add
    clarification to the specification [recorded in
    [14]http://www.w3.org/2009/11/19-svg-minutes.html#action01]

    <trackbot> Created ACTION-2695 - Investigate getIntersectionList and
    add clarification to the specification [on Erik Dahlström - due
    2009-11-26].

Deprecating CSSValue

    <ed>
    [15]http://lists.w3.org/Archives/Public/www-svg/2009Nov/0054.html

      [15] http://lists.w3.org/Archives/Public/www-svg/2009Nov/0054.html

    ED: Don't know if there is anything we can do
    ... but we could put some informative note in the 1.1 specification
    ... saying don't use this
    ... or deprecate it

    DS: Not sure if you can deprecate it

    ED: So an informative note
    ... it's a bit harder if we want to remove stuff I guess
    ... I don't think any user agent implemented that to a large degree
    ... Opera did for colour and it was hard to use

    DS: Actually maybe we should deprecate it
    ... then we don't have to test it

    ED: Is it possible for us to do that?
    ... what does it mean, it doesn't remove it?

    DS: Discourage people from using it and tells them we will remove it
    later

    <ed> deprecate SVGStylable.getPresentationAttribute and SVGPaint,
    SVGColor (which inherit from CSSValue)

    <scribe> ACTION: Erik to Deprecate
    SVGStylable.getPresentationAttribute and SVGPaint, SVGColor in SVG
    1.1 2nd Edition [recorded in
    [16]http://www.w3.org/2009/11/19-svg-minutes.html#action02]

    <trackbot> Created ACTION-2696 - Deprecate
    SVGStylable.getPresentationAttribute and SVGPaint, SVGColor in SVG
    1.1 2nd Edition [on Erik Dahlström - due 2009-11-26].

CSSUnit and Values

    DS: We will put this off for 2.0

    RESOLUTION: We will put this off for SVG 2.0

    ED: We should have an issue for it

    <ed> [17]http://www.w3.org/Graphics/SVG/WG/track/issues/2278 maybe?

      [17] http://www.w3.org/Graphics/SVG/WG/track/issues/2278

    ED: maybe we should raise a new issue

    <jwatt> ISSUE-2300

    <jwatt> btw

Summary of Action Items

    [NEW] ACTION: Erik to Deprecate SVGStylable.getPresentationAttribute
    and SVGPaint, SVGColor in SVG 1.1 2nd Edition [recorded in
    [18]http://www.w3.org/2009/11/19-svg-minutes.html#action02]
    [NEW] ACTION: Erik to Investigate getIntersectionList and add
    clarification to the specification [recorded in
    [19]http://www.w3.org/2009/11/19-svg-minutes.html#action01]

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [20]scribe.perl version 1.135
     ([21]CVS log)
     $Date: 2009/11/19 21:50:43 $
      _________________________________________________________

      [20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [21] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at [22]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

      [22] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Mozilla will/do you think we can/
Succeeded: s/mre/more/
Succeeded: s/and it goes on and on and on and on and on//
Succeeded: s/dectection/detection/
Succeeded: s/witht hat/with that/
Succeeded: s/implemented/wrote a test (that I'm reviewing) for/
Succeeded: s/CSS Value/CSSValue/
Succeeded: s/hard/hard to use/
Found Scribe: Jonathan Watt
Found ScribeNick: jwatt
Found Scribe: anthony
Inferring ScribeNick: anthony
Found ScribeNick: anthony
Scribes: Jonathan Watt, anthony
ScribeNicks: jwatt, anthony
Default Present: ed, Shepazu, jwatt, anthony
Present: ed Shepazu jwatt anthony
Agenda: [23]http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDe
c/0041.html

      [23] http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDec/0041.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 19 Nov 2009
Guessing minutes URL: [24]http://www.w3.org/2009/11/19-svg-minutes.html
People with action items: erik

      [24] http://www.w3.org/2009/11/19-svg-minutes.html

    End of [25]scribe.perl diagnostic output]

      [25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 19 November 2009 21:53:51 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:43 GMT