06:29:41 <RRSAgent> RRSAgent has joined #svg
06:29:42 <RRSAgent> logging to http://www.w3.org/2009/07/15-svg-irc
06:29:43 <trackbot> RRSAgent, make logs public
06:29:44 <Zakim> Zakim has joined #svg
06:29:45 <trackbot> Zakim, this will be GA_SVGWG
06:29:45 <Zakim> ok, trackbot; I see GA_SVGWG()2:30AM scheduled to start in 1 minute
06:29:46 <trackbot> Meeting: SVG Working Group Teleconference
06:29:47 <trackbot> Date: 15 July 2009
06:29:59 <Zakim> GA_SVGWG()2:30AM has now started
06:30:06 <Zakim> +Doug_Schepers
06:30:37 <Zakim> +[IPcaller]
06:30:39 <heycam> Zakim, [ is me
06:30:39 <Zakim> +heycam; got it
06:31:44 <ed> ed has joined #svg
06:31:55 <Zakim> +??P2
06:32:01 <anthony> Zakim, ??P2 is me
06:32:01 <Zakim> +anthony; got it
06:36:27 <Zakim> +??P3
06:36:37 <ed> Zakim, ??P3 is me
06:36:37 <Zakim> +ed; got it
06:39:27 <heycam> Scribe: Cameron
06:39:30 <heycam> ScribeNick: heycam
06:39:32 <heycam> Chair: Erik
06:39:39 <heycam> Topic: SVG DOM
06:40:16 <heycam> DS: i've heard a lot of complaints about the SVG DOM
06:40:32 <heycam> ... specifically from implementors
06:40:42 <heycam> ... and users complaining about the speed of svg
06:40:51 <heycam> ... and authors complaining about the complexity of SVG DOM programming
06:40:56 <heycam> ... i think roc has a good point [on www-svg]
06:41:08 <heycam> ... having to hit the DOM three times to set the properties of a circle is kind of ridiculous
06:41:18 <heycam> ... SVG is already hampered in its speed by having a DOM in the first place
06:41:33 <heycam> ... they're talking now about <canvas> having some SVG-like properties
06:41:42 <heycam> ... like having a "DOM" / structured content for accessibility
06:41:53 <heycam> ... a lot of these SVG DOM features people don't use
06:42:00 <heycam> ... i haven't seen content in the wild that uses SVGPathSegList, for example
06:42:28 <heycam> ... 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?
06:42:34 <heycam> ... perhaps it could also be useful for canvas
06:42:46 <heycam> ED: i've wanted a better DOM since i joined the group, basically
06:42:57 <heycam> DS: i think it's well past time for talking about this in a serious way
06:43:06 <heycam> ... right now we have people implementing SVG 1.1 and moaning about it, rightfully so
06:43:17 <heycam> ... i'd much rather have everybody on board with something everybody wants
06:43:28 <heycam> ... heycam and I were talking about the details of how this would work
06:43:37 <heycam> ... i'm starting to look at usage patterns of svg
06:43:43 <heycam> ... and he brought up MAMA
06:43:49 <heycam> ... erik do you have access to MAMA?  does everyone?
06:43:56 <heycam> ED: i don't think so but i can talk to the guy who runs it
06:44:10 <heycam> DS: here are are a couple of things i'd like to see
06:44:17 <heycam> ... first, how much SVG content exists on the web
06:44:44 <heycam> ED: i don't know if it looks at a static page or if it runs scripts
06:47:40 <heycam> 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
06:48:14 <heycam> CM: i think the API usage information would be great to have
06:48:19 <heycam> ... especially when we're thinking of dropping existing APIs
06:48:37 <heycam> ED: i'll ask him if it's possible to change and run it, and whether it works with scripts
06:48:59 <heycam> ACTION: Erik to ask about MAMA usage for SVG document frequency and SVG DOM API usage
06:49:00 <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].
06:50:02 <heycam> DS: so for the poorly implemented apis, i'd like to drop them
06:50:11 <heycam> ED: definitely the SVGPathSegList ones are complex to implement, and not well performing
06:50:16 <heycam> ... so something simpler for path would be nice
06:50:29 <heycam> DS: i'd like to have a unified api for canvas and svg, that's on my wishlist
06:50:37 <heycam> ED: that would be nice, if the syntax was more or less the same
06:50:50 <heycam> DS: there might be some differences on certain things, but if it's more useful than not, that'd be a win
06:51:12 <heycam> ED: the arc command, e.g., when you try to make a circle in SVG you can't actually specify that
06:51:15 <heycam> ... but you can in canvas
06:51:19 <heycam> ... so that it will be closed completely
06:51:25 <heycam> DS: i've wanted to change that for a long time
06:51:54 <heycam> ISSUE: look at making path arcto command work with drawing 360 degree arcs
06:51:54 <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 .
06:53:21 <heycam> AG: it would be good if the SVG DOM were faster
06:53:27 <heycam> ... especially in embedded scenarios
06:53:37 <heycam> ED: with the pathseg objects, i don't know if you can do anything useful with them anyway
06:54:05 <heycam> CM: i imagine a lot of the time people are just modifying path data strings instead
06:54:11 <heycam> ED: that's the only thing that really works across viewers
06:54:16 <heycam> DS: i haven't seen anybody do it otherwise
06:57:03 <heycam> CM: roc was suggesting on the list about dropping units in the SVGLength interfaces
06:57:15 <heycam> ... and my inkscape-developing officemate was suggesting to drop units altogether
06:57:20 <heycam> AG: i think percentages are still useful
06:57:28 <heycam> ED: and ems are useful for background images
06:57:55 <heycam> CM: otherwise percentages are of the containing block?
06:57:56 <heycam> ED: yes
06:58:03 <heycam> ... but mostly people only use percentage units
06:59:06 <heycam> ... i think the thing roc is talking about is that you can fetch the computed value in user units
06:59:27 <heycam> ... so perhaps the proposal in ISSUE-2044 wasn't sufficient
07:00:49 <heycam> ... i made a test implementation that simply forwarded the x accessors to the baseVal.value
07:00:54 <heycam> ... which gives you the value in user units
07:01:04 <heycam> ... because .x is just an SVGAnimatedLength
07:01:39 <heycam> CM: i'm worried about that proposal being a bit cute/hacky
07:01:42 <heycam> ED: it is hacky, but it works
07:03:04 <heycam> CM: if we could get the MAMA information soon, we should look at which features are droppable and work on improving those first
07:03:30 <heycam> DS: there are a lot of factors that go into not working on this quickly
07:03:53 <heycam> ... the MAMA suggestion is a good concrete way to push the SVG DOM reworking forwards
07:04:14 <heycam> ... it's a bit frustrating to have people complaining about svg 1.1 but not committing to later versions
07:04:44 <heycam> ... i think we need to reach out to implementors
07:05:27 <heycam> ... i think roc, jwatt and if we have eric seidel interested in this then it could help it move forward more quickly
07:09:34 <heycam> ACTION: Erik to email implementors about their thoughts on improving the SVG DOM
07:09:34 <trackbot> Created ACTION-2639 - Email implementors about their thoughts on improving the SVG DOM [on Erik Dahlström - due 2009-07-22].
07:14:25 <heycam> ED: anything we should be doing with proposals or spec text, before we get MAMA results and implementor feedback?
07:14:33 <heycam> ... or should we just wait for that
07:15:17 <shepazu> http://dev.w3.org/SVG/proposals/type-constructors/type-constructors.txt
07:15:33 <heycam> DS: imo, without having the time to do it myself right now, we should start adding spec text
07:16:29 <heycam> ... what about dino?
07:16:38 <heycam> ED: i think he did want to help improve the svg dom at one point
07:16:53 <heycam> DS: even if he doesn't have time at the moment, he might be able to share the ideas he has
07:18:27 <heycam> ... i'd like to see constructs for graphical element types, too
07:18:33 <heycam> ... for all the shapes, at least
07:18:50 <heycam> ... maybe not for things like filter, pattern, things like that
07:19:01 <heycam> ... do you think having too many constructors would clutter up the implementation?
07:19:13 <heycam> ED: i guess it does in a way, but for all of the basic types i think it makes perfect sense
07:19:45 <heycam> DS: how would the constructor look?  beyond the dom attributes.
07:19:53 <heycam> ... fill, stroke and stroke-width are the most common things that are changed
07:19:59 <heycam> ... how far do we go?
07:20:55 <heycam> CM: you could have a single argument { fill: '#eee', 'stroke-width': 2 }
07:21:04 <heycam> DS: i like that
07:21:10 <heycam> ... they could reuse that same JS object in multiple calls
07:21:23 <heycam> ... so if you changed the style object it wouldn't change anything, it wouldn't be live
07:23:07 <heycam> ... we should talk to js toolkit implementors too
07:23:12 <heycam> ... like dojo, jquery
07:23:19 <heycam> ... surely they know what the pain points are
07:25:34 <heycam> ... so there are two different things we're trying to do here
07:25:39 <heycam> s/two/three/
07:26:05 <heycam> ... one, find paint points and where they have or have not been implemented, what features implementors want to drop
07:26:19 <heycam> ... and encourage implementors to help us with 2.0 instead of wasting time implementing the poor 1.1 interfaces
07:26:30 <heycam> ... two, we want to find out what apis would be ideal if we were designing it from scratch
07:26:36 <heycam> ... if it were being made today, what would it look like
07:27:04 <heycam> ... three, we want to see if we can make the api useful for canvas as well as svg
07:27:20 <heycam> ... 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
07:27:40 <heycam> ... i think the idea of the constructor wouldn't be quite the same
07:28:14 <heycam> ... so you wouldn't have to use this for canvas but you could
07:28:27 <heycam> myGroupElement.drawCircle(50, 50, 100, { fill: red })
07:28:41 <heycam> ... what are the goals?
07:28:55 <heycam> ... 1. make it easy to use
07:28:59 <heycam> ... 2. make it fast, implementation-wise
07:29:14 <heycam> ... 3. make it fairly generally applicable, so even if there's another language in the future that uses graphics it might use this api
07:29:19 <heycam> ... e.g. svg/canvas/maybe some third thing
07:29:27 <heycam> ... we don't want people to have to learn new things
07:29:36 <heycam> ED: one option would be to have a <canvas> element in svg as well, or something similar
07:29:47 <heycam> DS: i think we've talked about being able to use canvas on any <svg:image>
07:29:53 <heycam> ED: that'd be quite simple, if you have <canvas> support already
07:30:55 <heycam> DS: 4. maybe more friendly to an html author
07:31:06 <heycam> ... we should think about css in the same context
07:31:35 <heycam> ... it'd be interesting if one of the things you could pass in, instead of the style object, a css class
07:31:48 <heycam> AG: i think keeping it simple is a good goal, too
07:32:19 <heycam> 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
07:32:25 <heycam> ... we should base it on real-world usage patterns
07:33:22 <heycam> 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
07:33:51 <heycam> 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
07:34:04 <heycam> ... i already have that idea in the integration spec
07:34:16 <heycam> ... but it's not expanded very well
07:34:21 <heycam> ED: buffered-rendering ties in to this too
07:34:29 <heycam> ... it's a way of speeding up things that can be slow to rerender
07:34:44 <heycam> ... with canvas you can clear and redraw the parts you need to redraw
07:35:15 <heycam> DS: how much will is there to work on this?
07:35:23 <heycam> ... do you think this is something that we can follow through on?
07:35:45 <heycam> CM: i think this is a reasonable first thing to work on for the 2.0 spec
07:35:50 <heycam> DS: be good to show it at svg open
07:35:58 <heycam> AG: it's working on the underlying architecture
07:36:30 <heycam> DS: how does it stand in priority compared to 1.1 2ed?
07:36:38 <heycam> ED: so we expect to have 2ed out by svg open?
07:36:49 <heycam> CM: that'd be good
07:36:53 <heycam> ED: i don't want to dwell on it much longer
07:37:40 <heycam> Topic: SVG 1.1 second edition
07:37:47 <heycam> DS: we've got a few actions left
07:37:58 <heycam> ... i'd like to get JW's final buy in for some of mine
07:38:11 <heycam> ... then we need to have tests
07:38:19 <heycam> ED: i think the test part is the biggest thing we have left to do
07:38:38 <heycam> ... there are a couple unfinished test actions still
07:40:16 <heycam> DS: should we have telcons next week?
07:40:25 <heycam> CM: if it will help us get the actions done i'm happy with not having telcons next week
07:40:34 <heycam> DS: erik will be on vacation
07:40:44 <heycam> ED: i only have test related actions left for 1.1e2 now
07:43:04 <ed> http://dev.w3.org/SVG/profiles/1.1F2/test/templates/
07:44:13 <heycam> [discussions on getting the tests for the 1.1 errata done]
07:47:56 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition
07:53:06 <heycam> We decide not to have telcons next week or the following week.
07:53:22 <heycam> Next week 2 hours before the regular Wednesday telcon time we will meet on IRC to work on the tests for 1.1 2ed.
07:54:10 <heycam> ed will be on vacation for the next two weeks
07:54:33 <heycam> ag will be on vacation for the week after next
08:01:31 <heycam> ACTION: Doug to mail eseidel about SVGPathSegList
08:01:32 <trackbot> Created ACTION-2640 - Mail eseidel about SVGPathSegList [on Doug Schepers - due 2009-07-22].
08:04:26 <Zakim> -ed
08:04:27 <Zakim> -anthony
08:04:30 <Zakim> -heycam
08:04:31 <Zakim> -Doug_Schepers
08:04:31 <Zakim> GA_SVGWG()2:30AM has ended
08:04:32 <Zakim> Attendees were Doug_Schepers, [IPcaller], heycam, anthony, ed
08:04:42 <heycam> RRSAgent, make minutes
08:04:42 <RRSAgent> I have made the request to generate http://www.w3.org/2009/07/15-svg-minutes.html heycam
08:42:07 <Zakim> Zakim has left #svg
08:46:49 <heycam> heycam has joined #svg
10:46:17 <heycam> heycam has joined #svg
11:43:00 <ed_work> hmm...looking at the compositing spec and comparing with filters, I'm wondering if I should perhaps add some of the blendmodes
11:43:57 <ed_work> feComposite can do "plus" using the "arithmetic" keyword for example, but doesn't have a keyword for that operation specifically
11:44:51 <ed_work> "plus" would be: operator="arithmetic" k2="1" k3="1"
11:45:15 <ed_work> "src" would also be possible to map this way, perhaps others too