- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Fri, 13 Nov 2009 08:46:29 +1100
- To: www-svg@w3.org
http://www.w3.org/2009/11/12-svg-minutes.html
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
12 Nov 2009
See also: [2]IRC log
[2] http://www.w3.org/2009/11/12-svg-irc
Attendees
Present
Shepazu, jwatt, [IPcaller], anthony
Regrets
Chair
SV_MEETING_CHAIR
Scribe
jwatt, anthony
Contents
* [3]Topics
1. [4]F2F dates
2. [5]Microsoft
* [6]Summary of Action Items
_________________________________________________________
<trackbot> Date: 12 November 2009
<scribe> scribe: jwatt
<scribe> scribenick: jwatt
F2F dates
AG: spoke erik - not available 18-22 Feb
... Cam not back until Q2 earliest
... jwatt not available in Feb
... or Jan
... so I'm wondering if we should do the F2F early March
... first week
DS: I was thinking of going to Japan in Jan, and hoping to make it a
single trip going back via AUS
[discussion about times]
AG: how about 10th - 14th Feb?
[more discussion]
JW: okay, that could hopefully work for me
AG: I'll talk to Ed about those dates
Microsoft
<shepazu>
[7]http://lists.w3.org/Archives/Public/www-svg/2009Nov/0026.html
[7] http://lists.w3.org/Archives/Public/www-svg/2009Nov/0026.html
<shepazu> if MS were to implement SVG, how much of the DOM would be
necessary for broad interoperability?
<shepazu> as far as implementations, the most complete is probably
Batik... then ASV (which is dwindling)... then the modern browsers
(Opera, FF, Safari)...
<shepazu> then there's the mobile UAs, but they use SVGT1.2's
microdom...
<shepazu> there's also compatibility with existing content to look
at... it would be good to know how much of the corner-cases of the
DOM are used in content
<shepazu> note that Opera, FF, and WebKit implement different
subsets of the DOM
DS: there's a lot of good stuff in the SVG DOM, including
unimplemented stuff, and there's a lot of stuff that was possibly
not well thought out
... I think we're at a unique point where there's not a lot of
content affected by DOM changes
... if we had a bunch of implementers that wanted to reconsider the
DOM, we should maybe do that
... 1.2 Tiny is a complete departure from 1.1 Full anyway
... it would be a hard sell to some people, but if all the browser
vendors wanted to do it, I'd we willing to look at it
AG: I think it would be good to look at provided we keep backwards
compatibility in mind
DS: backwards compatibility could mean backwards compatibility with
content OR implementations
... there's three different types of content to deal with
... 1) static content - not relevant here
... 2) content that uses basic DOM Level 1/2/3 stuff
... 3) content that uses particular things in the SVG DOM
... we're only at partial risk in 2, depending on how much we throw
away or keep
... 3 is where our main risk is
... the importance I'd give is first content, then implementations,
then specifications
<anthony> AG: With backwards compatibility of implementations, we
would only need to look at where implementations overlap
JW: I'm mainly worried about implementation complexity and
performance
<anthony> scribe: anthony
JW: The SVG DOM that are really negative for both
... especially the complex multiple levels of objects
... and object properties
... for certain attributes
... means you end up crossing the boundary between script and
multiple implementations several times
... just to set multiple properties
... and these object heavy interfaces
... also add to implementation complexity
... if you are to avoid excessive memory use
... a lot of the time when I'm implementing DOM I sometimes wish we
could start over and redesign it
... given the knowledge we have now
... but I've never felt that it was really possible
DS: One thing I've been talking about with people recently
... is a DOM summit
... or workshop
... where we get together for 2 - 3 days with authors and developers
... people who are doing implementations and also people who
experience with the SVG DOM making content with the SVG DOM
... and people who have experience with the Flex development and
seeing if we can make a best of breed interface
... and API developers
... I've seen people who said they liked what the SVG WG came up
with recently
... there are sort of general DOM optimisations
... then there is stuff that is useful for SVG and Graphics
... unified API for SVG and Canvas
... TC39 should be along for the summit as well
... I'd like to take a look at expanding the maths library so it
deals with points and vectors
... and matrices
JW: Math global?
DS: Yes
... I think TC39 does the Math global
JW: Yes it will be
... I'm kind of worried about getting so many people in the one room
... as your starting point
AG: I agree
JW: TC39 would not have any dependencies on SVG
... and I don't think they'd like that
... they would have to have dependencies on SVG
DS: We could put the functions in the right places or where they
belong
JW: Java script library is probably the right place for that
DS: Scrip libraries rarely do that one thing they are suppose to do.
They always end up doing a whole bunch of other things
... and you end up having to download the whole library
... I think they are overused as a tactic for expanding the web
JW: I agree at some point we want to take a script library and
standardise the features
... once it's in the standard it becomes concrete
DS: I understand your point JWatt, at what point is it appropriate
to standardise
AG: With the summit, you'd want to go in there with use case and
requirements
JW: I guess the main point here is should we be working on a new DOM
... I'm not sure how many people this will effect
... and how much content will be lost
... if people throw away their old implementations
DS: Let's not pretend that the browsers have as complete
implementation as Adobe did
JW: I think Mozilla's implementation in certain places is more
complete than Adobe's ever was
DS: If we are worried about breaking compatibility with past content
... then that's already been done
... most of the content that was made back in the old days is not
compatible with the implementations of today
JW: I agree all the stuff that was written in the Adobe days is
pretty much broken
... I'm worried that people made content we broke it
... then people have made new content
... then we break it again
... maybe that the content is small enough that for the sake of the
benefits of the future out weigh the cost for breaking things again
... but still going to be a painful process
... I think the thing that might sway me to take the root of
breaking backwards compatibility
... is the emergence of Web IDL which allows us to make much better
interfaces
... Have a whole bunch of bulky stuff and it'd be nice to throw it
away
... we'd have to publicize this
... and get feedback
DS: I think MAMA is a good way to gauge what is out there
<jwatt> s/feedback/feedback\/see how much we get flamed/
DS: and having a good test suite would help
JW: I think what you're talking about what is used in the wild
... is useful, but what I was talking about was making a list
... of things we might consider removing from the SVG DOM
... and saying "hey we're not thinking about throwing everything in
the SVG DOM away, we are thinking of throwing away X, Y and Z"
... potential for less confusion
DS: Obviously we'd have to get pretty concrete
... what's the next step?
... Maybe we should start on a specification
... nothing like a specification to get people talking
... we need to finish SVG Full 1.1 2nd Edition
... and start SVG 2.0
... and start with the DOM
... so next step is what?
JW: Working on the specification is one thing
... should have a document somewhere saying we are thinking of doing
this
AG: How is that different from the current page?
DS: Current page has future ideas
AG: We should have a parent page
DS: If I felt that everyone was along for the ride
... then I'd say let's go with SVG 2.0 and not worry about the past
JW: Really I'd love to see the MAMA stuff and get the data
... and I don't want to commit to breaking suff
DS: That would be what we need is feedback from the community
... we are fortunate that most of the content is static
Summary of Action Items
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [8]scribe.perl version 1.135
([9]CVS log)
$Date: 2009/11/12 21:38:34 $
_________________________________________________________
[8] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[9] 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 [10]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/SVG DOM/Microsoft/
Succeeded: s/the/probably the/
Succeeded: s/one point/what point/
Succeeded: s/JW/DS/
Succeeded: s/Adobe/Adobe days/
Succeeded: s/with the/is the/
Succeeded: s/has allowed/which allows/
WARNING: Bad s/// command: s/feedback/feedback\/see how much we get fla
med/
Succeeded: s/starting over/throwing everything in the SVG DOM away/
Succeeded: s/some things away/away X, Y and Z/
Succeeded: s/stutt/suff/
Found Scribe: jwatt
Inferring ScribeNick: jwatt
Found ScribeNick: jwatt
Found Scribe: anthony
Inferring ScribeNick: anthony
Scribes: jwatt, anthony
ScribeNicks: jwatt, anthony
Default Present: Shepazu, jwatt, [IPcaller], anthony
Present: Shepazu jwatt [IPcaller] anthony
WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth
Found Date: 12 Nov 2009
Guessing minutes URL: [11]http://www.w3.org/2009/11/12-svg-minutes.html
People with action items:
[11] http://www.w3.org/2009/11/12-svg-minutes.html
End of [12]scribe.perl diagnostic output]
[12] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 12 November 2009 21:47:06 UTC