IRC log of svg on 2012-03-15

Timestamps are in UTC.

20:01:36 [RRSAgent]
RRSAgent has joined #svg
20:01:36 [RRSAgent]
logging to
20:01:38 [trackbot]
RRSAgent, make logs public
20:01:38 [Zakim]
Zakim has joined #svg
20:01:40 [trackbot]
Zakim, this will be GA_SVGWG
20:01:40 [Zakim]
ok, trackbot; I see GA_SVGWG(SVG1)4:00PM scheduled to start now
20:01:41 [trackbot]
Meeting: SVG Working Group Teleconference
20:01:41 [trackbot]
Date: 15 March 2012
20:02:19 [cyril]
cyril has joined #svg
20:02:27 [Zakim]
GA_SVGWG(SVG1)4:00PM has now started
20:02:34 [Zakim]
20:03:17 [Zakim]
20:03:26 [glenn]
zakim, ??p5 is glenn
20:03:26 [Zakim]
+glenn; got it
20:03:33 [ed]
20:03:47 [Zakim]
20:03:50 [heycam]
Zakim, ??P6 is me
20:03:50 [Zakim]
+heycam; got it
20:04:44 [Zakim]
20:04:54 [ed]
Zakim, [IP is me
20:04:54 [Zakim]
+ed; got it
20:05:27 [Zakim]
20:05:58 [glenn]
zakim, who's noisy?
20:06:04 [ed]
chair: ed
20:06:11 [Zakim]
glenn, listening for 12 seconds I heard sound from the following: heycam (4%), Tav (83%), ed (32%)
20:06:25 [Zakim]
20:07:09 [Zakim]
20:07:24 [heycam]
ScribeNick: heycam
20:07:48 [heycam]
Topic: Finishing SVG 2 requirements
20:08:24 [heycam]
CC: we left off at microdom
20:08:27 [heycam]
Topic: Microdom
20:08:27 [cyril]
20:09:05 [heycam]
CM: I agree with Erik we should split these out
20:09:30 [heycam]
CC: should we split it and come back to it later?
20:09:47 [heycam]
ED: I've listed the ones I knew about
20:10:01 [heycam]
… the changes that I think are useful and ones I know aren't useful
20:10:54 [Zakim]
20:10:55 [heycam]
CM: we don't need to look at the minor changes as requirements
20:11:02 [heycam]
ED: we could just consider this all as part of improving the DOM
20:11:07 [krit]
zakim, P9 is me
20:11:07 [Zakim]
sorry, krit, I do not recognize a party named 'P9'
20:11:10 [heycam]
… which we've already accepted as a requirement
20:11:15 [heycam]
… the changing interface names might be tricky though
20:11:24 [krit]
zakim, +??P9 is me
20:11:24 [Zakim]
sorry, krit, I do not recognize a party named '+??P9'
20:11:38 [krit]
zakim, ??P9 is me
20:11:38 [Zakim]
+krit; got it
20:11:39 [heycam]
… if we introduce new interfaces, we shouldn't clash with existing ones
20:12:09 [heycam]
CM: like SVGAnimationElement?
20:12:10 [heycam]
ED: yes
20:12:15 [heycam]
… some new inheritance structure
20:12:28 [heycam]
CM: we'll need to revisit inheritance structure for Web IDL anyway
20:12:38 [heycam]
CC: for SVGMatrix particularly, there's also the work from Dean
20:12:44 [heycam]
… on CSSMatrix unification
20:13:04 [Zakim]
20:13:12 [heycam]
CM: I would be fine with consider these as part of DOM improvements
20:13:16 [heycam]
CC: I feel a bit uneasy about that
20:13:23 [Zakim]
+ +1.415.308.aaaa
20:13:28 [heycam]
… improvement in general, yes, but maybe we should have some still general requirements
20:13:40 [krit]
zakim, +1.415.308.aaaa is me
20:13:40 [Zakim]
+krit; got it
20:13:43 [heycam]
… the TraitAccess had a specific design
20:14:04 [krit]
zakim, who's here?
20:14:04 [Zakim]
On the phone I see cyril, glenn, heycam, ed, Tav, krit
20:14:29 [heycam]
… I agree, for some of them like SVGRect we don't want to spend much time on them, but some of them we should spend a bit more time on
20:14:52 [heycam]
ED: for SVGRect, that's the same as in 1.1
20:15:08 [heycam]
… we could split up this requirement entry into chunks
20:15:20 [heycam]
… was there a specific feature you were concerned about?
20:15:41 [heycam]
… I listed the changes I was aware of compared to 1.1
20:15:49 [heycam]
… it's all the big parts, I think. if there's anything missing it's small.
20:16:05 [heycam]
… the biggest one here would be the TraitAccess interface, and perhaps SVGTimer/SVGGlobal
20:16:31 [heycam]
CM: did we already resolve not to include timers?
20:16:39 [heycam]
ED: it was the timer event
20:18:27 [heycam]
CM: we could have a discussion now about whether we want to include microdom as is
20:18:40 [heycam]
ED: it's probably not too hard to merge, but in some cases the tiny DOM doesn't take into account the complexities of 1.1
20:19:11 [heycam]
… for example arcs are missing in tiny, so the path interfaces in tiny would need changes
20:19:33 [heycam]
… for the features we've already decided to have, maybe it makes sense to merge back parts
20:20:44 [heycam]
CM: I was never a fan of the microdom design
20:20:51 [heycam]
… I don't want to accept it as a whole
20:21:07 [heycam]
… as part of the DOM improvements work that someone does/designs, it can be looked at for inspiration
20:21:18 [heycam]
CC: I'm concerned that we will miss out some useful functionality
20:22:00 [heycam]
ACTION: Cyril to update the list of differences between MicroDOM and SVG 1.1 to help with DOM improvement proposals
20:22:00 [trackbot]
Created ACTION-3249 - Update the list of differences between MicroDOM and SVG 1.1 to help with DOM improvement proposals [on Cyril Concolato - due 2012-03-22].
20:23:51 [cyril]
RRSAgent, pointer
20:23:51 [RRSAgent]
20:24:36 [heycam]
RESOLUTION: SVG 2 will not merge the MicroDOM as is but will use it as input into the DOM improvement designs
20:24:55 [ed]
20:25:02 [heycam]
Topic: Relaxed document error handling
20:25:06 [heycam]
CM: I think that's a good idea
20:25:09 [heycam]
ED: me too
20:26:05 [heycam]
RESOLUTION: SVG 2 will have relaxed document error handling (with lacuna values etc.) as defined in Tiny 1.2
20:26:51 [heycam]
CC: we should look at ones we skipped now, before going on to the late requests
20:26:54 [cyril]
20:27:03 [heycam]
Topic: display of InkML trace groups
20:27:17 [heycam]
20:29:12 [heycam]
CC: reading the email again, I wonder if we didn't have an action to ask charles about specific features/changes
20:29:31 [heycam]
… the email conclusion says "it would be fantastic if SVG could be used to display InkML trace groups"
20:29:35 [heycam]
… but it doesn't propose anything
20:30:35 [heycam]
20:31:54 [Zakim]
20:32:14 [Zakim]
20:34:50 [heycam]
CM: two requirements I can tease out of this
20:34:53 [heycam]
… one is buffered-rendering
20:35:09 [heycam]
… the other is like variable stroke width, but not necessarily varying just stroke width, also opacity
20:35:19 [ed] we have resolved
20:35:36 [ed]
20:36:02 [ed] might also be related
20:36:21 [heycam]
CC: we said we would not accept replicate without use cases and author/implementor interest
20:36:26 [heycam]
… so this seems like a use case
20:36:30 [heycam]
… and author interest
20:36:39 [heycam]
… but we still don't have implementor interest
20:36:43 [heycam]
ED: I would want more details
20:36:49 [krit]
20:36:49 [heycam]
… it's not clear how the InkML would map into SVG
20:37:14 [heycam]
CM: the InkML traces are sequences of points with a pressure value
20:37:34 [heycam]
ED: I'm unclear how you would use it together with SVG
20:37:39 [heycam]
… somehow to connect the two
20:38:04 [heycam]
CM: whether it's a new element?
20:38:09 [heycam]
ED: or maybe a DOM API
20:38:14 [heycam]
… but the request isn't clear on that
20:38:45 [heycam]
DS: maybe we should ask for more clarification
20:39:52 [heycam]
… InkML is a big spec to require
20:44:51 [heycam]
CC: his derived requirements are efficient DOM rendering, and variable stroke width
20:45:06 [heycam]
CM: but not varying opacity?
20:50:55 [heycam]
RESOLUTION: SVG 2 should be able to display InkML trace groups by some means, perhaps by using buffered-rendering and variable stroke width, not necessarily varying anything
20:52:17 [cyril]
20:52:17 [heycam]
Topic: Connectors
20:52:57 [heycam]
TB: there is interest in Inkscape to support connectors
20:53:09 [heycam]
… but the group that indicated interest hasn't done any work on it
20:53:18 [heycam]
DS: is that were you specify points? and you get nice paths along these points?
20:53:28 [heycam]
TB: no
20:53:51 [cyril]
20:54:12 [heycam]
TB: basically you have objects that are connected by lines, and the connectors say which object you start on and which you end on
20:54:18 [heycam]
… a way of building up diagrams
20:54:33 [heycam]
… Inkscape has support for automatic routing connectors
20:54:45 [heycam]
… you can say this object is connected to this other object, and it will draw a line between them
20:54:51 [heycam]
DS: with connection points?
20:54:52 [heycam]
TB: yes
20:55:08 [heycam]
… one nice thing is that you can say to have the line avoid certain objects, so the lines route around it
20:55:51 [heycam]
CM: I think we've avoided talking about path routing in the past
20:55:58 [heycam]
… beacuse there are many path routing algorithms you could want
20:56:26 [Zakim]
20:56:30 [heycam]
TB: I would be interested in having the semantics in SVG
20:56:30 [heycam]
20:56:49 [cyril]
20:57:12 [cyril]
this is the minutes from a previous discussion on connnectors
20:57:52 [Zakim]
20:58:03 [heycam]
Zakim, ??P6 is me
20:58:03 [Zakim]
+heycam; got it
20:58:18 [heycam]
ED: we've just talked about simple lines for the rendering
20:58:28 [heycam]
… but a way to have the author specify anything nicer
20:58:43 [heycam]
… the reasoning was that if you just have the links and no visual output, there's less incentive to use it
20:58:50 [heycam]
… because you don't get much for free except the semantics
20:59:05 [heycam]
… otoh if it's ugly nobody might use it
20:59:11 [heycam]
… but I could see using it for simple cases
20:59:25 [heycam]
TB: if there's a way for the author to override the simple line, it might give the incentive to use it
20:59:33 [heycam]
… I think this is also good for accessibility
20:59:41 [heycam]
DS: in that case the semantic is important
20:59:54 [heycam]
CC: from a different perspective, you can already do connectors
21:00:03 [heycam]
… diagrams, reconnecting objects, you can already do this with JS
21:00:15 [heycam]
… so you might expect to see examples on the web
21:00:34 [heycam]
… I'm wondering if this is a good use case
21:00:40 [heycam]
… I'm not hearing interest from browser vendors
21:00:55 [heycam]
… maybe the use cases aren't strong enough for browsers to be interested
21:01:05 [heycam]
DS: it depends how you see the SVG documents
21:01:21 [heycam]
… browsers see them as images you can script, not necessarily as the semantics behind it
21:01:40 [heycam]
… so it's not as important to add the connection semantics
21:02:00 [heycam]
… I think it's OK to say that we want the semantics so that certain tools can use it, but not necessarily a requirement to draw the connection
21:02:36 [heycam]
CC: if it's only about semantics, I don't see why it needs to be in SVG itself, it could be a separate language
21:02:46 [heycam]
ED: I think it would make sense to have this as a module
21:03:02 [heycam]
DS: the question is who would use the module?
21:03:10 [heycam]
… special tools that try to visualise connections?
21:03:12 [Zakim]
21:03:16 [heycam]
… or would browsers render the connections?
21:03:52 [Zakim]
21:04:17 [heycam]
… tools like Visio would give the user a choice to modify the paths, but if we have an algorithm that would not be possible
21:04:58 [heycam]
CM: the spec just requires a straight line between the two points
21:05:09 [heycam]
DS: but how often do you want to draw just a straight line?
21:05:48 [heycam]
CC: I think if we want to work on this in the module that's fine, but I'm worried it would hold up SVG 2
21:06:33 [heycam]
RESOLUTION: SVG 2 will not have connectors, but we will continue its work as a separate module/spec
21:07:09 [cyril]
21:07:21 [heycam]
Topic: enhanced text support
21:08:49 [ed]
21:09:10 [heycam]
CM: I think David wanted different sized glyphs to be aligned on a baseline other than alphabetic
21:09:31 [heycam]
ED: I know if these baseline properties aren't implemented well cross browser
21:09:38 [heycam]
… they might satisfy David's use case
21:09:55 [ed]
s/I know if /I know /
21:11:32 [heycam]
CM: my guess is that these baseline properties will allow you to do this
21:11:48 [heycam]
GA: I believe it's in the CSS3 line layout module
21:13:21 [heycam]
21:14:03 [heycam]
data:text/html,A<span style='font-size:200px'>B</span>C
21:16:01 [heycam]
CC: I think the requirement is OK
21:16:22 [heycam]
ED: I think it is handled by these properties, and the requirement is OK
21:16:55 [heycam]
21:18:31 [heycam]
RESOLUTION: SVG 2 will support glyphs being aligned to different baselines, perhaps by using existing or improved CSS properties
21:19:19 [heycam]
Topic: Hit-testing on image alpha
21:19:23 [cyril]
21:19:36 [heycam]
DS: we talked about pointer events some time ago
21:19:39 [heycam]
… hit testing is related to that
21:20:09 [krit]
21:20:25 [heycam]
CM: it was going to go into CSS UI but it got deferred
21:20:27 [krit]
21:22:13 [heycam]
CM: I think it would be fine to handle this alpha image pointer events in SVG if CSS doesn't get to it
21:22:49 [heycam]
… I would be happy with this if there aren't unsolvable security problems
21:23:00 [heycam]
CC: would this be on gradient opacity too?
21:23:22 [heycam]
… it would be a new property or attribute?
21:23:33 [heycam]
… you can't change the current behaviour
21:23:55 [heycam]
CM: or extend the pointer-events property with new values
21:25:21 [ed]
21:25:28 [heycam]
ED: yes having an alpha cutoff was discussed at some point
21:25:43 [heycam]
… I think we should look at the previous discussion
21:25:49 [heycam]
… I'm a bit worried about the security aspects of it
21:28:36 [heycam]
RESOLUTION: SVG 2 will support pointer events sensitive to alpha, subject to security constraints
21:29:01 [ed] is part of the thread on pointer-events alpha
21:29:49 [cyril]
21:29:51 [cyril]
21:29:53 [cyril]
21:29:54 [cyril]
21:29:56 [cyril]
21:29:57 [cyril]
21:31:45 [heycam]
ACTION: Cameron to mail Brian asking his opinion on these open animation requirements
21:31:46 [trackbot]
Created ACTION-3250 - Mail Brian asking his opinion on these open animation requirements [on Cameron McCormack - due 2012-03-22].
21:33:05 [Zakim]
21:33:07 [Zakim]
21:33:08 [Zakim]
21:33:08 [Zakim]
21:33:10 [Zakim]
21:33:11 [Zakim]
21:33:12 [Zakim]
GA_SVGWG(SVG1)4:00PM has ended
21:33:12 [Zakim]
Attendees were cyril, glenn, heycam, [IPcaller], ed, Tav, krit
21:33:43 [heycam]
RRSAgent, make minutes
21:33:43 [RRSAgent]
I have made the request to generate heycam
21:34:55 [heycam]
Regrets: Rik
21:34:56 [heycam]
RRSAgent, make minutes
21:34:56 [RRSAgent]
I have made the request to generate heycam