minutes, 28 June 2012 SVG WG telcon

Please find the minutes for this week's SVG WG telcon below.

   http://www.w3.org/2012/06/28-svg-minutes.html


    [1]W3C

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

                                - DRAFT -

                     SVG Working Group Teleconference

28 Jun 2012

    [2]Agenda

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

    See also: [3]IRC log

       [3] http://www.w3.org/2012/06/28-svg-irc

Attendees

    Present
           Doug_Schepers, heycam, nikos, ed, Tav

    Regrets
    Chair
           Cameron

    Scribe
           Cameron

Contents

      * [4]Topics
          1. [5]SVG Integration
          2. [6]Bounding Boxes for 0-sized shapes
          3. [7]Rounding behavior for the 'order' attribute of
             feConvolveMatrix
          4. [8]pointer events
      * [9]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 28 June 2012

    <heycam> Scribe: Cameron

SVG Integration

    <heycam> ScribeNick: heycam

    CM: what's needed for publication?

    DS: basically it's these tables, let me get a link

    <shepazu>
    [10]http://dev.w3.org/SVG/modules/integration/SVGIntegration.ht
    ml

      [10] http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

    <shepazu>
    [11]http://dev.w3.org/SVG/modules/integration/SVGIntegration.ht
    ml#svg-tokens

      [11] 
http://dev.w3.org/SVG/modules/integration/SVGIntegration.html#svg-tokens

    DS: since we're working on SVG2, we should include it here too

    … we want a table with element name, attributes, properties,
    and possible child elements

    … and we want that for SVG 1.1, 1.2T and SVG2

    … we want it to link to the particular spec

    <shepazu> Element Table: Element name, Attributes, Properties,
    Possible Child Elements

    … for example here we have the <a> element, we've got a link to
    the definition of the a element to SVG 1.1

    … there's links for each attribute to its definition in 1.1,
    also in 1.2T

    … whether it accepts properties

    … and then possible child elements for the different versions
    of the spec

    … so we want links to all these things

    … there are some gotchas in here

    <shepazu>
    [12]http://dev.w3.org/SVG/modules/integration/SVGIntegration.ht
    ml#svg-attributes

      [12] 
http://dev.w3.org/SVG/modules/integration/SVGIntegration.html#svg-attributes

    … in the second table, we list whether something is an
    attribute or property

    <shepazu> SVG Attributes Table: Attribute or Property, Type,
    Applicable Elements for each of SVG 1.1, SVGT1.2, SVG2

    … then we list the applicable elements for each of SVG 1.1 and
    1.2T

    TB: how do we know what's going to be in SVG2?

    CM: I think we just update this as we go along with SVG2, we
    update this document

    DS: if you look at width="" in the attribute table

    … in some versions of this table, because width can be on
    multiple elements, there were several instances of width

    … anthony ran into some other problems

    [13]http://www.w3.org/TR/SVG11/attindex.html

      [13] http://www.w3.org/TR/SVG11/attindex.html

    CM: there are duplicate lines for width here

    … but that's because there are multiple definitions in the
    spec, different for each element

    DS: there's also an SVG properties table

    <shepazu> SVG Properties: Property, Attribute Type

    … why do we want this table?

    … the original reason was that basically there was some concern
    that HTML5 would whitelist a set of elements

    … and that would be for the parser

    … the notion was that SVG would define the elements, and HTML
    would simply refer to a spec that had all of the possible
    elements and attributes for the parser

    … this does not actually list all the attribute and property
    values, which might be interesting

    [14]http://www.w3.org/TR/SVG11/propidx.html

      [14] http://www.w3.org/TR/SVG11/propidx.html

    CM: that sort of property table would be more useful

    … that information isn't in a more useful form for parsing
    currently though

    … I could work on the script for that table generation

    NA: I asked anthony about it and he said it's in the svn repo
    under tools

    <scribe> ACTION: Cameron to work on the script for table
    generation in SVG Integration [recorded in
    [15]http://www.w3.org/2012/06/28-svg-minutes.html#action01]

    <trackbot> Created ACTION-3312 - Work on the script for table
    generation in SVG Integration [on Cameron McCormack - due
    2012-07-05].

    CM: so with the tables regenerated we'd be happy to republish
    the spec as it is?

    DS: sure. there's a lot more I'd like to do with the spec but
    as a first draft it would be fine.

    … for the second draft, we should determine what should be in
    the spec

    … there are some aspects of the draft that should just actually
    be in SVG2

    … inline SVG in HTML, should that be in SVG 2?

    … inline HTML in SVG, should that be in SVG 2?

    CM: I think at least HTML in SVG should be mentioned in the SVG
    spec

    … whether or not we define the rendering behaviour for HTML in
    foreignObject in SVG2 or just in Integration

    NA: no strong opinion

    DS: we could put as part of the preface of the Integration
    spec, that if people feel some things should move to the SVG2
    spec itself we can do that

    <shepazu> scribenick: shepazu

Bounding Boxes for 0-sized shapes

    <heycam>
    [16]http://lists.w3.org/Archives/Public/www-svg/2012Jun/0046.ht
    ml

      [16] http://lists.w3.org/Archives/Public/www-svg/2012Jun/0046.html

    heycam: implementations differ, but don't seem to return
    position, only {0,0,0,0}

    … rlongson says that 0-sized elements are not rendered, so
    there isn't a position

    <ed> testcase: [17]http://svg.cc/posts/getBBox_circle_r0.html

      [17] http://svg.cc/posts/getBBox_circle_r0.html

    shepazu: but element in defs have a bbox

    ed: Opera returns the position

    Tav: why is this important? animation?

    heycam: there are lots of various use cases

    nikos: reading description in SVG1.1, I think the Opera
    interpretation is correct

    <nikos>
    [18]http://www.w3.org/TR/SVG/types.html#__svg__SVGLocatable__ge
    tBBox

      [18] http://www.w3.org/TR/SVG/types.html#__svg__SVGLocatable__getBBox

    "Note that getBBox must return the actual bounding box at the
    time the method was called, even in case the element has not
    yet been rendered."

    nikos: and I think the bbox is (0,0) centered at the location

    shepazu: agree, and we should be more explicit in SVG2

    heycam: yes, there needs to be an exact definition

    Resolution: Bounding Box should return correct x,y coordinates,
    even for 0-sized (non-rendered) elements, and the SVG2 spec
    should define that

    <scribe> ACTION: shepazu to clarify bbox position for 0-sized
    (non-rendered) elements in SVG2 [recorded in
    [19]http://www.w3.org/2012/06/28-svg-minutes.html#action02]

    <trackbot> Created ACTION-3313 - Clarify bbox position for
    0-sized (non-rendered) elements in SVG2 [on Doug Schepers - due
    2012-07-05].

    <ed>
    [20]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
    #feConvolveMatrixElementOrderAttribute

      [20] 
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feConvolveMatrixElementOrderAttribute

Rounding behavior for the 'order' attribute of feConvolveMatrix

    <heycam>
    [21]http://www.w3.org/Graphics/SVG/WG/track/issues/2438

      [21] http://www.w3.org/Graphics/SVG/WG/track/issues/2438

    heycam: the order attribute takes an integer, but it doesn't
    specify the behavior

    … it's a bit tricky, because the syntax definition says it
    takes (number, optional number), says floats, but expects
    integers

    … do we round in a particular way, or consider floats to be
    invalid, or what?

    ed: I think rounding is more consistent with other cases

    … and prefer not adding a new type

    … it's used together with kernal matrix…

    … not sure how common it is to have float values, probably not
    very common

    … or in animation

    Tav: it makes no sense to change this, without also changing
    the kernalMatrix
    ... the kernelMatrix has a list of numbers, and the order
    attribute defines those

    heycam: probably would have been better to define microsyntax

    shepazu: rounding is probably friendliest error-correction

    Tav: the person should know they made a mistake

    <ed> this is what all the other attributes that take numbers
    but want integers say: "Non-integer values are truncated, i.e
    rounded to the closest integer value towards zero."

    heycam: we could throw a console warning, and still let it
    round

    Resolution: float values in the 'order' attribute of
    feConvolveMatrix will use traditional rounding to an integer
    value, and will through a console log warning

    <scribe> ACTION: ed to specify that float values in the 'order'
    attribute of feConvolveMatrix will use traditional rounding to
    an integer value, and will throw a console log warning
    [recorded in
    [22]http://www.w3.org/2012/06/28-svg-minutes.html#action03]

    <trackbot> Created ACTION-3314 - Specify that float values in
    the 'order' attribute of feConvolveMatrix will use traditional
    rounding to an integer value, and will throw a console log
    warning [on Erik Dahlström - due 2012-07-05].

    <heycam> ScribeNIck: heycam

    <scribe> ScribeNick: heycam

pointer events

    DS: the pointer-events property is now implemented for HTML in
    all the browsers?

    ED: not sure

    DS: it's been removed from the css3-ui spec, because hit
    testing isn't defined for the web platform anywhere

    … I suggest a css hit testing spec, which includes the
    pointer-events property and anything else related to hit
    testing, would be a useful spec to have

    … so I suggest we go to the CSS WG and ask for this to be a
    module for css ui

    … basically that we just propose there's a spec

    … and that it's in charter because it was in css3-ui previously

    … and that we decide amongst ourselves who might edit that spec

    … and to do that work in the FX group, or purely CSS

    CM: FX sounds good
    ... there's obviously a need to define this both for SVG and
    CSS/HTML, so I'd be happy for there to be a spec

    DS: I'm happy to work on it

    … annevk had sent in a lot of good feedback on the hit testing,
    so I'll try and find that

    RESOLUTION: We will approach the CSS WG about a hit testing and
    pointer events joint spec

Summary of Action Items

    [NEW] ACTION: Cameron to work on the script for table
    generation in SVG Integration [recorded in
    [23]http://www.w3.org/2012/06/28-svg-minutes.html#action01]
    [NEW] ACTION: ed to specify that float values in the 'order'
    attribute of feConvolveMatrix will use traditional rounding to
    an integer value, and will throw a console log warning
    [recorded in
    [24]http://www.w3.org/2012/06/28-svg-minutes.html#action03]
    [NEW] ACTION: shepazu to clarify bbox position for 0-sized
    (non-rendered) elements in SVG2 [recorded in
    [25]http://www.w3.org/2012/06/28-svg-minutes.html#action02]

    [End of minutes]
      __________________________________________________________

Received on Thursday, 28 June 2012 22:02:41 UTC