W3C home > Mailing lists > Public > www-svg@w3.org > July 2009

Minutes, July 15 2009 SVG WG telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 15 Jul 2009 18:08:21 +1000
To: www-svg@w3.org
Message-ID: <20090715080821.GB9277@arc.mcc.id.au>
Hello www-svg.

Please find the minutes of the July 15 2009 SVG WG telcon at:


or below as text for tracker to find.


      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

15 Jul 2009

   See also: [2]IRC log

      [2] http://www.w3.org/2009/07/15-svg-irc


          Doug_Schepers, [IPcaller], heycam, anthony, ed




     * [3]Topics
         1. [4]SVG DOM
         2. [5]SVG 1.1 second edition
     * [6]Summary of Action Items

   <trackbot> Date: 15 July 2009

   <scribe> Scribe: Cameron

   <scribe> ScribeNick: heycam


   DS: i've heard a lot of complaints about the SVG DOM
   ... specifically from implementors
   ... and users complaining about the speed of svg
   ... and authors complaining about the complexity of SVG DOM
   ... i think roc has a good point [on www-svg]
   ... having to hit the DOM three times to set the properties of a
   circle is kind of ridiculous
   ... SVG is already hampered in its speed by having a DOM in the
   first place
   ... they're talking now about <canvas> having some SVG-like
   ... like having a "DOM" / structured content for accessibility
   ... a lot of these SVG DOM features people don't use
   ... i haven't seen content in the wild that uses SVGPathSegList, for
   ... rather than having people implement something nobody really
   wants, how about making a concerted effort to make a new DOM for SVG
   2.0 and get implementors to go with that instead?
   ... perhaps it could also be useful for canvas

   ED: i've wanted a better DOM since i joined the group, basically

   DS: i think it's well past time for talking about this in a serious
   ... right now we have people implementing SVG 1.1 and moaning about
   it, rightfully so
   ... i'd much rather have everybody on board with something everybody
   ... heycam and I were talking about the details of how this would
   ... i'm starting to look at usage patterns of svg
   ... and he brought up MAMA
   ... erik do you have access to MAMA? does everyone?

   ED: i don't think so but i can talk to the guy who runs it

   DS: here are are a couple of things i'd like to see
   ... first, how much SVG content exists on the web

   ED: i don't know if it looks at a static page or if it runs scripts

   DS: i'd like to use MAMA to find out generally, how much svg content
   there is, a list of DOM apis that are used for SVG and their

   CM: i think the API usage information would be great to have
   ... especially when we're thinking of dropping existing APIs

   ED: i'll ask him if it's possible to change and run it, and whether
   it works with scripts

   <scribe> ACTION: Erik to ask about MAMA usage for SVG document
   frequency and SVG DOM API usage [recorded in

   <trackbot> Created ACTION-2638 - Ask about MAMA usage for SVG
   document frequency and SVG DOM API usage [on Erik Dahlström - due

   DS: so for the poorly implemented apis, i'd like to drop them

   ED: definitely the SVGPathSegList ones are complex to implement, and
   not well performing
   ... so something simpler for path would be nice

   DS: i'd like to have a unified api for canvas and svg, that's on my

   ED: that would be nice, if the syntax was more or less the same

   DS: there might be some differences on certain things, but if it's
   more useful than not, that'd be a win

   ED: the arc command, e.g., when you try to make a circle in SVG you
   can't actually specify that
   ... but you can in canvas
   ... so that it will be closed completely

   DS: i've wanted to change that for a long time

   ISSUE: look at making path arcto command work with drawing 360
   degree arcs

   <trackbot> Created ISSUE-2290 - Look at making path arcto command
   work with drawing 360 degree arcs ; please complete additional
   details at
   [8]http://www.w3.org/Graphics/SVG/WG/track/issues/2290/edit .

      [8] http://www.w3.org/Graphics/SVG/WG/track/issues/2290/edit

   AG: it would be good if the SVG DOM were faster
   ... especially in embedded scenarios

   ED: with the pathseg objects, i don't know if you can do anything
   useful with them anyway

   CM: i imagine a lot of the time people are just modifying path data
   strings instead

   ED: that's the only thing that really works across viewers

   DS: i haven't seen anybody do it otherwise

   CM: roc was suggesting on the list about dropping units in the
   SVGLength interfaces
   ... and my inkscape-developing officemate was suggesting to drop
   units altogether

   AG: i think percentages are still useful

   ED: and ems are useful for background images

   CM: otherwise percentages are of the containing block?

   ED: yes
   ... but mostly people only use percentage units
   ... i think the thing roc is talking about is that you can fetch the
   computed value in user units
   ... so perhaps the proposal in ISSUE-2044 wasn't sufficient
   ... i made a test implementation that simply forwarded the x
   accessors to the baseVal.value
   ... which gives you the value in user units
   ... because .x is just an SVGAnimatedLength

   CM: i'm worried about that proposal being a bit cute/hacky

   ED: it is hacky, but it works

   CM: if we could get the MAMA information soon, we should look at
   which features are droppable and work on improving those first

   DS: there are a lot of factors that go into not working on this
   ... the MAMA suggestion is a good concrete way to push the SVG DOM
   reworking forwards
   ... it's a bit frustrating to have people complaining about svg 1.1
   but not committing to later versions
   ... i think we need to reach out to implementors
   ... i think roc, jwatt and if we have eric seidel interested in this
   then it could help it move forward more quickly

   <scribe> ACTION: Erik to email implementors about their thoughts on
   improving the SVG DOM [recorded in

   <trackbot> Created ACTION-2639 - Email implementors about their
   thoughts on improving the SVG DOM [on Erik Dahlström - due

   ED: anything we should be doing with proposals or spec text, before
   we get MAMA results and implementor feedback?
   ... or should we just wait for that


     [10] http://dev.w3.org/SVG/proposals/type-constructors/type-constructors.txt

   DS: imo, without having the time to do it myself right now, we
   should start adding spec text
   ... what about dino?

   ED: i think he did want to help improve the svg dom at one point

   DS: even if he doesn't have time at the moment, he might be able to
   share the ideas he has
   ... i'd like to see constructs for graphical element types, too
   ... for all the shapes, at least
   ... maybe not for things like filter, pattern, things like that
   ... do you think having too many constructors would clutter up the

   ED: i guess it does in a way, but for all of the basic types i think
   it makes perfect sense

   DS: how would the constructor look? beyond the dom attributes.
   ... fill, stroke and stroke-width are the most common things that
   are changed
   ... how far do we go?

   CM: you could have a single argument { fill: '#eee', 'stroke-width':
   2 }

   DS: i like that
   ... they could reuse that same JS object in multiple calls
   ... so if you changed the style object it wouldn't change anything,
   it wouldn't be live
   ... we should talk to js toolkit implementors too
   ... like dojo, jquery
   ... surely they know what the pain points are
   ... so there are three different things we're trying to do here
   ... one, find paint points and where they have or have not been
   implemented, what features implementors want to drop
   ... and encourage implementors to help us with 2.0 instead of
   wasting time implementing the poor 1.1 interfaces
   ... two, we want to find out what apis would be ideal if we were
   designing it from scratch
   ... if it were being made today, what would it look like
   ... three, we want to see if we can make the api useful for canvas
   as well as svg
   ... because even if it doesn't map 100%, there's still a lot of
   useful stuff that people wouldn't have to learn more than once
   ... i think the idea of the constructor wouldn't be quite the same
   ... so you wouldn't have to use this for canvas but you could

   myGroupElement.drawCircle(50, 50, 100, { fill: red })

   scribe: what are the goals?
   ... 1. make it easy to use
   ... 2. make it fast, implementation-wise
   ... 3. make it fairly generally applicable, so even if there's
   another language in the future that uses graphics it might use this
   ... e.g. svg/canvas/maybe some third thing
   ... we don't want people to have to learn new things

   ED: one option would be to have a <canvas> element in svg as well,
   or something similar

   DS: i think we've talked about being able to use canvas on any

   ED: that'd be quite simple, if you have <canvas> support already

   DS: 4. maybe more friendly to an html author
   ... we should think about css in the same context
   ... it'd be interesting if one of the things you could pass in,
   instead of the style object, a css class

   AG: i think keeping it simple is a good goal, too

   DS: yes i think that's an excellent goal, implementors aren't going
   to commit to complex APIs if they're not sure people will use it
   ... we should base it on real-world usage patterns

   AG: it'd be interesting to have svg had properties to say "don't
   stick this in the dom", you could speed up the rendering

   DS: we did talk a bit at the f2f about whether an immediate mode
   should exist for svg, i think that goes along with that
   ... i already have that idea in the integration spec
   ... but it's not expanded very well

   ED: buffered-rendering ties in to this too
   ... it's a way of speeding up things that can be slow to rerender
   ... with canvas you can clear and redraw the parts you need to

   DS: how much will is there to work on this?
   ... do you think this is something that we can follow through on?

   CM: i think this is a reasonable first thing to work on for the 2.0

   DS: be good to show it at svg open

   AG: it's working on the underlying architecture

   DS: how does it stand in priority compared to 1.1 2ed?

   ED: so we expect to have 2ed out by svg open?

   CM: that'd be good

   ED: i don't want to dwell on it much longer

SVG 1.1 second edition

   DS: we've got a few actions left
   ... i'd like to get JW's final buy in for some of mine
   ... then we need to have tests

   ED: i think the test part is the biggest thing we have left to do
   ... there are a couple unfinished test actions still

   DS: should we have telcons next week?

   CM: if it will help us get the actions done i'm happy with not
   having telcons next week

   DS: erik will be on vacation

   ED: i only have test related actions left for 1.1e2 now

   <ed> [11]http://dev.w3.org/SVG/profiles/1.1F2/test/templates/

     [11] http://dev.w3.org/SVG/profiles/1.1F2/test/templates/

   [discussions on getting the tests for the 1.1 errata done]


     [12] http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition

   We decide not to have telcons next week or the following week.

   Next week 2 hours before the regular Wednesday telcon time we will
   meet on IRC to work on the tests for 1.1 2ed.

   ed will be on vacation for the next two weeks

   ag will be on vacation for the week after next

   <scribe> ACTION: Doug to mail eseidel about SVGPathSegList [recorded
   in [13]http://www.w3.org/2009/07/15-svg-minutes.html#action03]

   <trackbot> Created ACTION-2640 - Mail eseidel about SVGPathSegList
   [on Doug Schepers - due 2009-07-22].

Summary of Action Items

   [NEW] ACTION: Doug to mail eseidel about SVGPathSegList [recorded in
   [NEW] ACTION: Erik to ask about MAMA usage for SVG document
   frequency and SVG DOM API usage [recorded in
   [NEW] ACTION: Erik to email implementors about their thoughts on
   improving the SVG DOM [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [17]scribe.perl version 1.135
    ([18]CVS log)
    $Date: 2009/07/15 08:04:48 $

     [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [18] 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 [19]http://dev.w3.org/cvsweb/~checkout~/2002

     [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/two/three/
Found Scribe: Cameron
Found ScribeNick: heycam
Default Present: Doug_Schepers, [IPcaller], heycam, anthony, ed
Present: Doug_Schepers [IPcaller] heycam anthony ed
Found Date: 15 Jul 2009
Guessing minutes URL: [20]http://www.w3.org/2009/07/15-svg-minutes.html
People with action items: doug erik

     [20] http://www.w3.org/2009/07/15-svg-minutes.html

   End of [21]scribe.perl diagnostic output]

     [21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Cameron McCormack ≝ http://mcc.id.au/
Received on Wednesday, 15 July 2009 08:09:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:18 UTC