IRC log of svg on 2009-07-15

Timestamps are in UTC.

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