SVG Working Group Teleconference -- 19 Nov 2009

<trackbot> Date: 19 November 2009

<ed> 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> 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> 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> 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 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> 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 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> http://www.w3.org/Graphics/SVG/WG/track/issues/2278 maybe?

ED: maybe we should raise a new issue

<jwatt> ISSUE-2300

<jwatt> btw

- DRAFT -

SVG Working Group Teleconference

19 Nov 2009

Attendees

Contents

Roadmap

IntersectionList

Deprecating CSSValue

CSSUnit and Values

Summary of Action Items

Scribe.perl diagnostic output