See also: IRC log
<trackbot> Date: 19 November 2009
<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
<jwatt> Scribe: Jonathan Watt
<jwatt> scribenick: jwatt
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
<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].
<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].
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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at 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: 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: http://www.w3.org/2009/11/19-svg-minutes.html People with action items: erik[End of scribe.perl diagnostic output]