See also: IRC log
<trackbot> Date: 15 March 2012
<scribe> ScribeNick: heycam
CC: we left off at microdom
CM: I agree with Erik we should split these out
CC: should we split it and come back to it later?
ED: I've listed the ones I knew about
… the changes that I think are useful and ones I know aren't useful
CM: we don't need to look at the minor changes as requirements
ED: we could just consider this all as part of improving the DOM
… which we've already accepted as a requirement
… the changing interface names might be tricky though
… if we introduce new interfaces, we shouldn't clash with existing ones
CM: like SVGAnimationElement?
… some new inheritance structure
CM: we'll need to revisit inheritance structure for Web IDL anyway
CC: for SVGMatrix particularly, there's also the work from Dean
… on CSSMatrix unification
CM: I would be fine with consider these as part of DOM improvements
CC: I feel a bit uneasy about that
… improvement in general, yes, but maybe we should have some still general requirements
… the TraitAccess had a specific design
… 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
ED: for SVGRect, that's the same as in 1.1
… we could split up this requirement entry into chunks
… was there a specific feature you were concerned about?
… I listed the changes I was aware of compared to 1.1
… it's all the big parts, I think. if there's anything missing it's small.
… the biggest one here would be the TraitAccess interface, and perhaps SVGTimer/SVGGlobal
CM: did we already resolve not to include timers?
ED: it was the timer event
CM: we could have a discussion now about whether we want to include microdom as is
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
… for example arcs are missing in tiny, so the path interfaces in tiny would need changes
… for the features we've already decided to have, maybe it makes sense to merge back parts
CM: I was never a fan of the microdom design
… I don't want to accept it as a whole
… as part of the DOM improvements work that someone does/designs, it can be looked at for inspiration
CC: I'm concerned that we will miss out some useful functionality
<scribe> ACTION: Cyril to update the list of differences between MicroDOM and SVG 1.1 to help with DOM improvement proposals [recorded in http://www.w3.org/2012/03/15-svg-minutes.html#action01]
<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].
RESOLUTION: SVG 2 will not merge the MicroDOM as is but will use it as input into the DOM improvement designs
CM: I think that's a good idea
ED: me too
RESOLUTION: SVG 2 will have relaxed document error handling (with lacuna values etc.) as defined in Tiny 1.2
CC: we should look at ones we skipped now, before going on to the late requests
CC: reading the email again, I wonder if we didn't have an action to ask charles about specific features/changes
… the email conclusion says "it would be fantastic if SVG could be used to display InkML trace groups"
… but it doesn't propose anything
CM: two requirements I can tease out of this
… one is buffered-rendering
… the other is like variable stroke width, but not necessarily varying just stroke width, also opacity
<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#buffered-rendering we have resolved
<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Variable_stroke_width might also be related
CC: we said we would not accept replicate without use cases and author/implementor interest
… so this seems like a use case
… and author interest
… but we still don't have implementor interest
ED: I would want more details
… it's not clear how the InkML would map into SVG
CM: the InkML traces are sequences of points with a pressure value
ED: I'm unclear how you would use it together with SVG
… somehow to connect the two
CM: whether it's a new element?
ED: or maybe a DOM API
… but the request isn't clear on that
DS: maybe we should ask for more clarification
… InkML is a big spec to require
CC: his derived requirements are efficient DOM rendering, and variable stroke width
CM: but not varying opacity?
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
TB: there is interest in Inkscape to support connectors
… but the group that indicated interest hasn't done any work on it
DS: is that were you specify points? and you get nice paths along these points?
TB: basically you have objects that are connected by lines, and the connectors say which object you start on and which you end on
… a way of building up diagrams
… Inkscape has support for automatic routing connectors
… you can say this object is connected to this other object, and it will draw a line between them
DS: with connection points?
… one nice thing is that you can say to have the line avoid certain objects, so the lines route around it
CM: I think we've avoided talking about path routing in the past
… beacuse there are many path routing algorithms you could want
DS: I would be interested in having the semantics in SVG
<cyril> this is the minutes from a previous discussion on connnectors
ED: we've just talked about simple lines for the rendering
… but a way to have the author specify anything nicer
… the reasoning was that if you just have the links and no visual output, there's less incentive to use it
… because you don't get much for free except the semantics
… otoh if it's ugly nobody might use it
… but I could see using it for simple cases
TB: if there's a way for the author to override the simple line, it might give the incentive to use it
… I think this is also good for accessibility
DS: in that case the semantic is important
CC: from a different perspective, you can already do connectors
… diagrams, reconnecting objects, you can already do this with JS
… so you might expect to see examples on the web
… I'm wondering if this is a good use case
… I'm not hearing interest from browser vendors
… maybe the use cases aren't strong enough for browsers to be interested
DS: it depends how you see the SVG documents
… browsers see them as images you can script, not necessarily as the semantics behind it
… so it's not as important to add the connection semantics
… 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
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
ED: I think it would make sense to have this as a module
DS: the question is who would use the module?
… special tools that try to visualise connections?
… or would browsers render the connections?
… tools like Visio would give the user a choice to modify the paths, but if we have an algorithm that would not be possible
CM: the spec just requires a straight line between the two points
DS: but how often do you want to draw just a straight line?
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
RESOLUTION: SVG 2 will not have connectors, but we will continue its work as a separate module/spec
CM: I think David wanted different sized glyphs to be aligned on a baseline other than alphabetic
ED: I know these baseline properties aren't implemented well cross browser
… they might satisfy David's use case
CM: my guess is that these baseline properties will allow you to do this
GA: I believe it's in the CSS3 line layout module
data: text/html,A<span style='font-size:200px'>B</span>C
CC: I think the requirement is OK
ED: I think it is handled by these properties, and the requirement is OK
RESOLUTION: SVG 2 will support glyphs being aligned to different baselines, perhaps by using existing or improved CSS properties
DS: we talked about pointer events some time ago
… hit testing is related to that
CM: it was going to go into CSS UI but it got deferred
CM: I think it would be fine to handle this alpha image pointer events in SVG if CSS doesn't get to it
… I would be happy with this if there aren't unsolvable security problems
CC: would this be on gradient opacity too?
… it would be a new property or attribute?
… you can't change the current behaviour
CM: or extend the pointer-events property with new values
ED: yes having an alpha cutoff was discussed at some point
… I think we should look at the previous discussion
… I'm a bit worried about the security aspects of it
RESOLUTION: SVG 2 will support pointer events sensitive to alpha, subject to security constraints
<ed> http://www.w3.org/mid/4DC60BB0.email@example.com is part of the thread on pointer-events alpha
<scribe> ACTION: Cameron to mail Brian asking his opinion on these open animation requirements [recorded in http://www.w3.org/2012/03/15-svg-minutes.html#action02]
<trackbot> Created ACTION-3250 - Mail Brian asking his opinion on these open animation requirements [on Cameron McCormack - due 2012-03-22].
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/TB/DS/ Succeeded: s/I know if /I know / Found ScribeNick: heycam Inferring Scribes: heycam Default Present: cyril, glenn, heycam, [IPcaller], ed, Tav, krit Present: cyril glenn heycam [IPcaller] ed Tav krit Regrets: Rik Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0159.html Found Date: 15 Mar 2012 Guessing minutes URL: http://www.w3.org/2012/03/15-svg-minutes.html People with action items: cameron cyril WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]