Re: Agenda, 15 March 2012 SVG WG telcon

Minutes from today's SVG WG telcon are at

   http://www.w3.org/2012/03/15-svg-minutes.html

and below as text.



    [1]W3C

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

                                - DRAFT -

                     SVG Working Group Teleconference

15 Mar 2012

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0159.html

    See also: [3]IRC log

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

Attendees

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

    Regrets
           Rik

    Chair
           ed

    Scribe
           heycam

Contents

      * [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

Microdom

    <cyril>
    [13]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#Micro_DOM

      [13] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Micro_DOM

    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?

    ED: yes

    … 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
    [14]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

    <ed>
    [15]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#Relaxed_document_error_handling_.28lacuna_values_etc.29

      [15] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Relaxed_document_error_handling_.28lacuna_values_etc.29

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

    <cyril>
    [16]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#Display_of_InkML_trace_groups

      [16] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Display_of_InkML_trace_groups

display of InkML trace groups

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

      [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.ht
    ml

      [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

    <ed>
    [19]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#buffered-rendering we have resolved

      [19] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#buffered-rendering

    <ed> and
    [20]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#Replicate

      [20] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Replicate

    <ed>
    [21]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#Variable_stroke_width might also be related

      [21] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Variable_stroke_width

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

    <cyril>
    [23]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#Connectors

      [23] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Connectors

Connectors

    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: no

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

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

    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
    past

    … beacuse there are many path routing algorithms you could want

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

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

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

    <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

    <cyril>
    [26]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#Enhanced_text_support

      [26] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Enhanced_text_support

enhanced text support

    <ed>
    [27]http://www.w3.org/TR/SVG11/text.html#BaselineAlignmentPrope
    rties

      [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

    ABC

    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-pro
    p

      [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
    properties

Hit-testing on image alpha

    <cyril>
    [29]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#Hit-testing_on_image_alpha

      [29] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#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

    <ed>
    [32]http://www.w3.org/TR/SVG11/interact.html#PointerEventsPrope
    rty

      [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

    <cyril>
    [34]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#SMIL_data_feedback

      [34] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_data_feedback

    <cyril>
    [35]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#SMIL_time_containers

      [35] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_containers

    <cyril>
    [36]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#Consider_adding_a_.27key.28.29.27_keyword_for_animation_tri
    ggers

      [36] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_a_.27key.28.29.27_keyword_for_animation_triggers

    <cyril>
    [37]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#the_.27timelineBegin.27_attribute_on_the_.3Csvg.3E_element

      [37] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.27timelineBegin.27_attribute_on_the_.3Csvg.3E_element

    <cyril>
    [38]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#the_.3Cdiscard.3E_element

      [38] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.3Cdiscard.3E_element

    <cyril>
    [39]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
    put#the_.27playbackOrder.27_attribute_on_the_.3Csvg.3E_element

      [39] 
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.27playbackOrder.27_attribute_on_the_.3Csvg.3E_element

    <scribe> ACTION: Cameron to mail Brian asking his opinion on
    these open animation requirements [recorded in
    [40]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].

Summary of Action Items

    [NEW] ACTION: Cameron to mail Brian asking his opinion on these
    open animation requirements [recorded in
    [41]http://www.w3.org/2012/03/15-svg-minutes.html#action02]
    [NEW] ACTION: Cyril to update the list of differences between
    MicroDOM and SVG 1.1 to help with DOM improvement proposals
    [recorded in
    [42]http://www.w3.org/2012/03/15-svg-minutes.html#action01]

    [End of minutes]
      __________________________________________________________

Received on Thursday, 15 March 2012 21:37:11 UTC