minutes, 22 March 2012 SVG WG telcon

Hello hello, minutes are below.



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

                                - DRAFT -

                     SVG Working Group Teleconference

22 Mar 2012



    See also: [3]IRC log

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


           heycam, glenn, ed, Doug_Schepers, cyril,
           +1.415.832.aaaa, krit, Tav


           krit, heycam


      * [4]Topics
          1. [5]telcomtime
          2. [6]SVG 2.0 requireemts
          3. [7]SVG 2 next phase
          4. [8]css transforms presentation attributes
          5. [9]intrinsic sizing and percetnage values for inline
             svg in html
      * [10]Summary of Action Items

    <trackbot> Date: 22 March 2012

    <glenn> sorry, was trying to tell zakim to mute me

    <krit> scribeNick: krit




    heycam: most might have less problems with proposal 2
    ... suggest to go with 2 than

    Tav: that's fine with me

    resolution: telcoms will be at 21: UTC once all people are in
    summer time

    it was Tav :(

    <Tav> I'll call in again

    cyril: next week just europe changes

    resolution: keep the current time till the end of the month

SVG 2.0 requireemts

    s/topic: SVG 2.0 require,emts/topic: SVG 2.0 requiremets/

    cyril: I try to find the link



    Detect if a mouse event is on the fill or stroke

    heycam: nice to have
    ... allows us not to duplicate the elements

    cyril: can we extend mouse events?
    ... be able to regster events only on the stroke, or shape
    ... onstrokeclick

    heycam: you have to duplicate a lot
    ... thinking more of the dupl. of existing events

    cyril: might be handy

    heycam: not sure if i like the idea for the new events

    ed: makes it harder to deal with pointer events
    ... haveing some way of setting where the events came from
    doesn't sound expesnsive

    heycam: we could send a mail to the DOM mailing list what
    people think there

    Tav: isn't this equivalent to the use case of clicking on a
    border to resize a window when you have a border

    heycam: might be

    cyril: clikcing on the stroke would give you a feedback what
    you clicked as well as a point where
    ... stroke or fill

    heycam: what about isPointOnTheStroke, or isPointOnThe Fill

    shepazu: feels strange to me
    ... would not only be fill and strokebut marker as well
    ... what is the equivalent in CSS? borderoutline or background?

    heycam: would be on the DOM SVG elements
    ... more like events

    <heycam> onmouseover="if (this.isPointOnStroke(evt.clientX,
    evt.clientY)) { … }"

    shepazu: Iam a user I click on the stroke of the circle
    ... what does the code do?
    ... that is differen

    heycam: yes, the example is kind of stupid

    shepazu: ok, but it looks more interessting to me
    ... we have get intersection BLA

    <ed> onmouseover="if (this.isPointOnStroke(evt))..." even?

    shepazu: like getIntersectionList

    <heycam> onmouseover="var markerIndex =
    this.getIndexOfMarkerThisPointIsOver(evt.clientX, evt.clientY);

    shepazu: it could return which parts of this element does this
    point hit
    ... it doesn't have to use an event
    ... for collistion detection might be useful

    <ed> isPointInPath would be useful too, in this case...

    shepazu: it might not useful it self, so it might be a
    rectanlge by size one

    heycam: we might except it then as a requirement

    resolution: SVG 2 will make it easier to detect if an mouse
    event is on the stroke or fill of an element



    SMIL data feedback

    cyril: we can look at it

    heycam: looks like simulation
    ... seems to be complexed data based input to SMIL animations
    ... might be useful to
    ... give me an action

    <scribe> ACTION: heycam will look at data feedback for SMIL and
    stays in contact with David [recorded in

    <trackbot> Created ACTION-3251 - Will look at data feedback for
    SMIL and stays in contact with David [on Cameron McCormack -
    due 2012-03-29].

    resolution: SVG 2 will not have SMIL data feedback until we
    accept requirement after clarification



    cyril: we kind of reolved time container already

    heycam: We are waiting for Brian about feedback
    ... he might be more aware of the needs
    ... it is likely that he suggest that we have time container in
    SVG 2

    cyril: if we don't resolve it now, we should discuss the next

    krit: we should at least have an action to look at it

    heycam: I talk to Brian till the next telcon

    cyril: we should move on to the next agenda topic

SVG 2 next phase





    cyril: can you summarize?
    ... we have so many requirements, to many for get the spec in
    ... we should pick up topics and need to make choices

    heycam: I agree
    ... discussed that in sydney as well

    cyril: how many proposals do we expect to proceed
    ... even 20 is a lot
    ... working on it to the end of july is really aggressively

    heycam: how many proposals do we have?

    cyril: it's in my email
    ... 126?

    heycam: pick the things you are interessted in and push it
    ... we should start a wiki page where people put ther names on
    the feature



    cyril: put your name under the feature on the list above

    heycam: we should have realistic time frames
    ... idea: pick a feature, put your name on it , write the spec,
    the test
    ... we can speak about it to the next week telcon
    ... the timeframes...

    cyril: next or in two weeks
    ... need a list of requ. that need a written down proposal

    krit: what about fixed time frames for discussions on telcoms?
    ... if a topic takes more time it gets cut off till the next
    ... like the CSS WG

    heycam: Proposals should come on the list first
    ... and discussed there
    ... if needed the discussion is done on the tel com

    cyril: who owns a feature will decide if it needs discussed on
    ... two people want a feature, how do we decide who gets it?

    heycam: we should assign on it before
    ... working on it
    ... someone wants to work on it?

    cyril: sometime you have two different ideas

    heycam: sure
    ... we should be clear who is driving which feature
    ... get the topics till next week?

    ed: fine

    heycam: I send a mail to the list

    <scribe> ACTION: heycam will send a mail to the list to put
    their names to the SVG 2 requirements [recorded in

    <trackbot> Created ACTION-3252 - Will send a mail to the list
    to put their names to the SVG 2 requirements [on Cameron
    McCormack - due 2012-03-29].

    <scribe> ACTION: Nikos produce a list of requirements that need
    proposals [recorded in

    <trackbot> Created ACTION-3253 - Produce a list of requirements
    that need proposals [on Nikos Andronikos - due 2012-03-29].

    <heycam> ScribeNick: heycam

css transforms presentation attributes

    krit: should the new presentation attributes allow unitless
    values and scientific notation?

    heycam: I think they should

    krit: for example transform-origin="100,100"

    … I agree

    … I wrote some test cases without thinking about, and I wrote
    unitless values

    … I think it's more native for SVG people to use unitless

    … as well as scientific notation

    … using user units makes more sense in an SVG context than
    using px

    … so I propose we support both in all presentation attributes

    heycam: what is the set of new presentation attributes?

    <krit> [21]http://dev.w3.org/csswg/css3-transforms/

      [21] http://dev.w3.org/csswg/css3-transforms/


      [22] http://dev.w3.org/csswg/css3-transforms/#property-index

    cyril: so perspective, perspective-origin and transform-origin

    heycam: I think authors will expect to be able to use user

    <ed> also see


    <ed> issue#2

    ed: issue 2 in that document covers exactly this issue

    krit: do we have to specify the syntax in the css spec?

    heycam: do you want a link to SVG length/number syntax?

    krit: at the moment they are not specified





    heycam: I think it would be better to link or define the syntax
    of the presentation
    ... easiest would be to link to <length> and <number> from
    1.1's types chapter

    <krit> [26]http://www.w3.org/TR/SVG/types.html

      [26] http://www.w3.org/TR/SVG/types.html

    heycam: the issue 2 in the animation proposal aligns with what
    we want then, user units allowed in presentation attributes

    ed: I assume we would support all of the new units in the
    presentation attributes

    heycam: what about calc()?
    ... just want to be sure the grammar/parser will work with say
    scientific notation inside calc expressions

    ed: I think we should try to stay as close to the css syntax
    where we can

    heycam: do you want to allow unitless values in the middle of

    ed: good question

    shepazu: I would want to

    krit: for webkit it wouldn't be a problem

    RESOLUTION: SVG WG is happy with allowing unitless numbers and
    scientific notation in the css transforms presentation

    ISSUE: Should we allow unitless numbers and scientific notation
    inside calc expressions in presentation attributes?

    <trackbot> Created ISSUE-2442 - Should we allow unitless
    numbers and scientific notation inside calc expressions in
    presentation attributes? ; please complete additional details
    at [27]http://www.w3.org/Graphics/SVG/WG/track/issues/2442/edit

      [27] http://www.w3.org/Graphics/SVG/WG/track/issues/2442/edit

    <scribe> ACTION: Dirk to mail public-fx about unitless numbers
    in presentation attributes [recorded in

    <trackbot> Created ACTION-3254 - Mail public-fx about unitless
    numbers in presentation attributes [on Dirk Schulze - due

intrinsic sizing and percetnage values for inline svg in html

    ed: some questions from our layout team about sizing of svg in



    … would like to know mozilla's opinion on this given their open

    … this needs clarifying in a spec somewhere


    <trackbot> ISSUE-2241 -- 1. Introduction - More explanations
    about the used coordinate system -- raised


      [30] http://www.w3.org/Graphics/SVG/WG/track/issues/2241

    ed: I think this is specific to where you have percetanges
    specified, or not specified at all, and whether or not they
    define an intrinsic size/ratio

    … I think it comes down to how you want to resolve the lengths,
    and tweaking the spec wording to that effect

    … reading the mozilla bug, it seems that mozilla went and did
    something else

    … so it would be nice to have something defined in the spec

    … we have at least three different behaviours among the 4

    heycam: do you have an opinion on which way to resolve it?

    ed: I would prefer if it doesn't break a lot of content, of

    … in the first case what opera/firefox do at the moment would
    be good

    … for the second example, I'm not sure either way

    <ed> [31]http://www.w3.org/Graphics/SVG/WG/track/issues/2441
    has more details than the mail

      [31] http://www.w3.org/Graphics/SVG/WG/track/issues/2441


      [32] https://bug668163.bugzilla.mozilla.org/attachment.cgi?id=545713

    krit: there is a webkit bug about that, so it might be changed
    a bit

    <glenn> dropping now, have another appt

    <scribe> ACTION: Cameron to ask jwatt about the percentage
    sizing issue [recorded in

    <trackbot> Created ACTION-3255 - Ask jwatt about the percentage
    sizing issue [on Cameron McCormack - due 2012-03-29].


      [34] http://www.w3.org/Graphics/SVG/WG/track/issues/2441

    <trackbot> ACTION-3255 Ask jwatt about the percentage sizing
    issue notes added

Summary of Action Items

    [NEW] ACTION: Cameron to ask jwatt about the percentage sizing
    issue [recorded in
    [NEW] ACTION: Dirk to mail public-fx about unitless numbers in
    presentation attributes [recorded in
    [NEW] ACTION: heycam will look at data feedback for SMIL and
    stays in contact with David [recorded in
    [NEW] ACTION: heycam will send a mail to the list to put their
    names to the SVG 2 requirements [recorded in
    [NEW] ACTION: Nikos produce a list of requirements that need
    proposals [recorded in

    [End of minutes]

Received on Thursday, 22 March 2012 21:37:07 UTC