SVG Working Group Teleconference -- 12 Nov 2009

<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> 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

- DRAFT -

SVG Working Group Teleconference

12 Nov 2009

Attendees

Contents

F2F dates

Microsoft

Summary of Action Items

Scribe.perl diagnostic output