SVG Working Group Teleconference -- 28 Jun 2012

<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> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

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

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

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 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> 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: 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> 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 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> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feConvolveMatrixElementOrderAttribute

Rounding behavior for the 'order' attribute of feConvolveMatrix

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

- DRAFT -

SVG Working Group Teleconference

28 Jun 2012

Attendees

Contents

SVG Integration

Bounding Boxes for 0-sized shapes

Rounding behavior for the 'order' attribute of feConvolveMatrix

pointer events

Summary of Action Items

Scribe.perl diagnostic output