- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Fri, 20 Nov 2009 08:53:01 +1100
- 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 UTC