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 http://www.w3.org/2012/03/15-svg-irc
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]: +cyril
20:03:17 [Zakim]: +??P5
20:03:26 [glenn]: zakim, ??p5 is glenn
20:03:26 [Zakim]: +glenn; got it
20:03:33 [ed]: Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0159.html
20:03:47 [Zakim]: +??P6
20:03:50 [heycam]: Zakim, ??P6 is me
20:03:50 [Zakim]: +heycam; got it
20:04:44 [Zakim]: +[IPcaller]
20:04:54 [ed]: Zakim, [IP is me
20:04:54 [Zakim]: +ed; got it
20:05:27 [Zakim]: +Tav
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]: -Tav
20:07:09 [Zakim]: +Tav
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Micro_DOM
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]: +??P9
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]: -krit
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]: See http://www.w3.org/2012/03/15-svg-irc#T20-23-51
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Relaxed_document_error_handling_.28lacuna_values_etc.29
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Display_of_InkML_trace_groups
20:27:03 [heycam]: Topic: display of InkML trace groups
20:27:17 [heycam]: http://lists.w3.org/Archives/Public/www-svg/2011May/0055.html
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]: http://lists.w3.org/Archives/Public/www-svg/2011Oct/0108.html
20:31:54 [Zakim]: -ed
20:32:14 [Zakim]: +[IPcaller]
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#buffered-rendering we have resolved
20:35:36 [ed]: and http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Replicate
20:36:02 [ed]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Variable_stroke_width 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]: http://www.w3.org/TR/InkML/
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Connectors
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]: http://dev.w3.org/SVG/modules/connector/SVGConnector.html
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]: -heycam
20:56:30 [heycam]: TB: I would be interested in having the semantics in SVG
20:56:30 [heycam]: s/TB/DS/
20:56:49 [cyril]: http://www.w3.org/2009/09/30-svg-minutes.html#item05
20:57:12 [cyril]: this is the minutes from a previous discussion on connnectors
20:57:52 [Zakim]: +??P6
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]: -Tav
21:03:16 [heycam]: … or would browsers render the connections?
21:03:52 [Zakim]: +Tav
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Enhanced_text_support
21:07:21 [heycam]: Topic: enhanced text support
21:08:49 [ed]: http://www.w3.org/TR/SVG11/text.html#BaselineAlignmentProperties
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]: ABC
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]: http://dev.w3.org/csswg/css3-linebox/#dominant-baseline-prop
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]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Hit-testing_on_image_alpha
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]: https://developer.mozilla.org/en/CSS/pointer-events
21:20:25 [heycam]: CM: it was going to go into CSS UI but it got deferred
21:20:27 [krit]: http://wiki.csswg.org/spec/css4-ui#pointer-events
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]: http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
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]: http://www.w3.org/mid/4DC60BB0.1000500@w3.org is part of the thread on pointer-events alpha
21:29:49 [cyril]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_data_feedback
21:29:51 [cyril]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_containers
21:29:53 [cyril]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_a_.27key.28.29.27_keyword_for_animation_triggers
21:29:54 [cyril]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.27timelineBegin.27_attribute_on_the_.3Csvg.3E_element
21:29:56 [cyril]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.3Cdiscard.3E_element
21:29:57 [cyril]: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.27playbackOrder.27_attribute_on_the_.3Csvg.3E_element
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]: -ed
21:33:07 [Zakim]: -glenn
21:33:08 [Zakim]: -heycam
21:33:08 [Zakim]: -krit
21:33:10 [Zakim]: -Tav
21:33:11 [Zakim]: -cyril
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 http://www.w3.org/2012/03/15-svg-minutes.html 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 http://www.w3.org/2012/03/15-svg-minutes.html heycam