See also: IRC log
<trackbot> Date: 28 June 2012
<heycam> Scribe: Cameron
<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
<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
<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
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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/(0.))/(0,0)/ Succeeded: s/kernalMatrix/kernelMatrix/ Succeeded: s/Tav gives up in disgust// Found Scribe: Cameron WARNING: No scribe lines found matching ScribeNick pattern: <Cameron> ... Found ScribeNick: heycam Found ScribeNick: shepazu Found ScribeNick: heycam Found ScribeNick: heycam ScribeNicks: heycam, shepazu Default Present: Doug_Schepers, heycam, nikos, ed, Tav Present: Doug_Schepers heycam nikos ed Tav Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012AprJun/0109.html Found Date: 28 Jun 2012 Guessing minutes URL: http://www.w3.org/2012/06/28-svg-minutes.html People with action items: cameron ed shepazu WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]