See also: IRC log
<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
programming
... 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 properties
... 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 example
... 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 way
... 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 wants
... heycam and I were talking about the details of how this
would work
... 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 frequency
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 http://www.w3.org/2009/07/15-svg-minutes.html#action01]
<trackbot> Created ACTION-2638 - Ask about MAMA usage for SVG document frequency and SVG DOM API usage [on Erik Dahlström - due 2009-07-22].
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 wishlist
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 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 quickly
... 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 http://www.w3.org/2009/07/15-svg-minutes.html#action02]
<trackbot> Created ACTION-2639 - Email implementors about their thoughts on improving the SVG DOM [on Erik Dahlström - due 2009-07-22].
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
<shepazu> 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 implementation?
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 api
... 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 <svg:image>
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
redraw
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 spec
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
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> http://dev.w3.org/SVG/profiles/1.1F2/test/templates/
[discussions on getting the tests for the 1.1 errata done]
<ed> 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 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].
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/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: http://www.w3.org/2009/07/15-svg-minutes.html People with action items: doug erik[End of scribe.perl diagnostic output]