W3C home > Mailing lists > Public > www-svg@w3.org > March 2012

Re: Agenda, 15 March 2012 SVG WG telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 16 Mar 2012 08:36:24 +1100
Message-ID: <4F6260D8.2070205@mcc.id.au>
To: SVG public list <www-svg@w3.org>
Minutes from today's SVG WG telcon are at


and below as text.


       [1] http://www.w3.org/

                                - DRAFT -

                     SVG Working Group Teleconference

15 Mar 2012



    See also: [3]IRC log

       [3] http://www.w3.org/2012/03/15-svg-irc


           cyril, glenn, heycam, [IPcaller], ed, Tav, krit





      * [4]Topics
          1. [5]Finishing SVG 2 requirements
          2. [6]Microdom
          3. [7]Relaxed document error handling
          4. [8]display of InkML trace groups
          5. [9]Connectors
          6. [10]enhanced text support
          7. [11]Hit-testing on image alpha
      * [12]Summary of Action Items

    <trackbot> Date: 15 March 2012

    <scribe> ScribeNick: heycam

Finishing SVG 2 requirements

    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

    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

    … 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?

    ED: yes

    … some new inheritance structure

    CM: we'll need to revisit inheritance structure for Web IDL

    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

    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

    <scribe> ACTION: Cyril to update the list of differences
    between MicroDOM and SVG 1.1 to help with DOM improvement
    proposals [recorded in

    <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



Relaxed document error handling

    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



display of InkML trace groups


      [17] http://lists.w3.org/Archives/Public/www-svg/2011May/0055.html

    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


      [18] http://lists.w3.org/Archives/Public/www-svg/2011Oct/0108.html

    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

    put#buffered-rendering we have resolved


    <ed> and


    put#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

    <krit> [22]http://www.w3.org/TR/InkML/

      [22] http://www.w3.org/TR/InkML/

    … it's not clear how the InkML would map into SVG

    CM: the InkML traces are sequences of points with a pressure

    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

    DS: is that were you specify points? and you get nice paths
    along these points?

    TB: no


      [24] http://dev.w3.org/SVG/modules/connector/SVGConnector.html

    TB: basically you have objects that are connected by lines, and
    the connectors say which object you start on and which you end

    … 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?

    TB: yes

    … 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

    … beacuse there are many path routing algorithms you could want

    DS: I would be interested in having the semantics in SVG


      [25] http://www.w3.org/2009/09/30-svg-minutes.html#item05

    <cyril> this is the minutes from a previous discussion on

    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

    … 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

    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

    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



enhanced text support


      [27] http://www.w3.org/TR/SVG11/text.html#BaselineAlignmentProperties

    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


      [28] http://dev.w3.org/csswg/css3-linebox/#dominant-baseline-prop

    RESOLUTION: SVG 2 will support glyphs being aligned to
    different baselines, perhaps by using existing or improved CSS

Hit-testing on image alpha



    DS: we talked about pointer events some time ago

    … hit testing is related to that

    <krit> [30]https://developer.mozilla.org/en/CSS/pointer-events

      [30] https://developer.mozilla.org/en/CSS/pointer-events

    CM: it was going to go into CSS UI but it got deferred

    <krit> [31]http://wiki.csswg.org/spec/css4-ui#pointer-events

      [31] http://wiki.csswg.org/spec/css4-ui#pointer-events

    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


      [32] http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty

    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> [33]http://www.w3.org/mid/4DC60BB0.1000500@w3.org is part
    of the thread on pointer-events alpha

      [33] http://www.w3.org/mid/4DC60BB0.1000500@w3.org













    <scribe> ACTION: Cameron to mail Brian asking his opinion on
    these open animation requirements [recorded in

    <trackbot> Created ACTION-3250 - Mail Brian asking his opinion
    on these open animation requirements [on Cameron McCormack -
    due 2012-03-22].

Summary of Action Items

    [NEW] ACTION: Cameron to mail Brian asking his opinion on these
    open animation requirements [recorded in
    [NEW] ACTION: Cyril to update the list of differences between
    MicroDOM and SVG 1.1 to help with DOM improvement proposals
    [recorded in

    [End of minutes]
Received on Thursday, 15 March 2012 21:37:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:29:50 UTC