21:00:45 <RRSAgent> RRSAgent has joined #svg
21:00:45 <RRSAgent> logging to http://www.w3.org/2012/06/28-svg-irc
21:00:47 <trackbot> RRSAgent, make logs public
21:00:47 <Zakim> Zakim has joined #svg
21:00:49 <trackbot> Zakim, this will be GA_SVGWG
21:00:49 <Zakim> ok, trackbot; I see GA_SVGWG(SVG1)5:00PM scheduled to start now
21:00:50 <trackbot> Meeting: SVG Working Group Teleconference
21:00:50 <trackbot> Date: 28 June 2012
21:01:32 <Tav> Tav has joined #svg
21:01:33 <Zakim> GA_SVGWG(SVG1)5:00PM has now started
21:01:40 <Zakim> +??P7
21:01:47 <Zakim> +Doug_Schepers
21:02:01 <heycam> Zakim, ??P7 is me
21:02:01 <Zakim> +heycam; got it
21:02:30 <Zakim> +??P13
21:02:36 <Zakim> +nikos
21:02:42 <ed> Zakim, ??P13 is me
21:02:42 <Zakim> +ed; got it
21:03:42 <Zakim> +Tav
21:05:30 <heycam> Chair: Cameron
21:05:35 <heycam> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012AprJun/0109.html
21:06:59 <heycam> Scribe: Cameron
21:07:02 <heycam> Topic: SVG Integration
21:07:11 <heycam> ScribeNick: heycam
21:07:15 <heycam> Topic: SVG Integration
21:07:40 <heycam> CM: what's needed for publication?
21:07:58 <heycam> DS: basically it's these tables, let me get a link
21:08:22 <shepazu> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
21:08:32 <shepazu> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html#svg-tokens
21:08:53 <heycam> DS: since we're working on SVG2, we should include it here too
21:09:02 <heycam> … we want a table with element name, attributes, properties, and possible child elements
21:09:44 <heycam> … and we want that for SVG 1.1, 1.2T and SVG2
21:10:03 <heycam> … we want it to link to the particular spec
21:10:12 <shepazu> Element Table: Element name, Attributes, Properties, Possible Child Elements
21:10:26 <heycam> … for example here we have the <a> element, we've got a link to the definition of the a element to SVG 1.1
21:10:38 <heycam> … there's links for each attribute to its definition in 1.1, also in 1.2T
21:11:01 <heycam> … whether it accepts properties
21:11:08 <heycam> … and then possible child elements for the different versions of the spec
21:11:12 <heycam> … so we want links to all these things
21:11:17 <heycam> … there are some gotchas in here
21:11:59 <shepazu> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html#svg-attributes
21:12:29 <heycam> … in the second table, we list whether something is an attribute or property
21:12:48 <shepazu> SVG Attributes Table: Attribute or Property,  Type, Applicable Elements for each of SVG 1.1, SVGT1.2, SVG2
21:12:52 <heycam> … then we list the applicable elements for each of SVG 1.1 and 1.2T
21:13:21 <heycam> TB: how do we know what's going to be in SVG2?
21:13:48 <heycam> CM: I think we just update this as we go along with SVG2, we update this document
21:14:18 <heycam> DS: if you look at width="" in the attribute table
21:15:10 <heycam> … in some versions of this table, because width can be on multiple elements, there were several instances of width
21:15:21 <heycam> … anthony ran into some other problems
21:15:43 <heycam> http://www.w3.org/TR/SVG11/attindex.html
21:15:49 <heycam> CM: there are duplicate lines for width here
21:15:58 <heycam> … but that's because there are multiple definitions in the spec, different for each element
21:18:26 <heycam> DS: there's also an SVG properties table
21:18:35 <shepazu> SVG Properties: Property, Attribute Type 
21:18:55 <heycam> … why do we want this table?
21:19:10 <heycam> … the original reason was that basically there was some concern that HTML5 would whitelist a set of elements
21:19:16 <heycam> … and that would be for the parser
21:19:43 <heycam> … 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
21:19:58 <heycam> … this does not actually list all the attribute and property values, which might be interesting
21:20:30 <heycam> http://www.w3.org/TR/SVG11/propidx.html
21:20:46 <heycam> CM: that sort of property table would be more useful
21:21:26 <heycam> … that information isn't in a more useful form for parsing currently though
21:22:00 <heycam> … I could work on the script for that table generation
21:22:39 <heycam> NA: I asked anthony about it and he said it's in the svn repo under tools
21:23:07 <heycam> ACTION: Cameron to work on the script for table generation in SVG Integration
21:23:07 <trackbot> Created ACTION-3312 - Work on the script for table generation in SVG Integration [on Cameron McCormack - due 2012-07-05].
21:23:30 <heycam> CM: so with the tables regenerated we'd be happy to republish the spec as it is?
21:23:42 <heycam> DS: sure. there's a lot more I'd like to do with the spec but as a first draft it would be fine.
21:23:59 <heycam> … for the second draft, we should determine what should be in the spec
21:24:07 <heycam> … there are some aspects of the draft that should just actually be in SVG2
21:24:20 <heycam> … inline SVG in HTML, should that be in SVG 2?
21:24:25 <heycam> … inline HTML in SVG, should that be in SVG 2?
21:25:40 <heycam> CM: I think at least HTML in SVG should be mentioned in the SVG spec
21:25:54 <heycam> … whether or not we define the rendering behaviour for HTML in foreignObject in SVG2 or just in Integration
21:26:43 <heycam> NA: no strong opinion
21:27:11 <heycam> 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
21:27:32 <shepazu> scribenick: shepazu 
21:28:43 <shepazu> Topic: Bounding Boxes for 0-sized shapes
21:28:45 <heycam> http://lists.w3.org/Archives/Public/www-svg/2012Jun/0046.html
21:30:11 <shepazu> heycam: implementations differ, but don't seem to return position, only {0,0,0,0}
21:30:43 <shepazu> … rlongson says that 0-sized elements are not rendered, so there isn't a position
21:30:55 <shepazu> q+
21:31:26 <ed> testcase: http://svg.cc/posts/getBBox_circle_r0.html
21:31:58 <shepazu> shepazu: but element in defs have a bbox
21:32:17 <shepazu> ed: Opera returns the position
21:32:40 <shepazu> Tav: why is this important? animation?
21:32:51 <shepazu> heycam: there are lots of various use cases
21:33:29 <shepazu> nikos: reading description in SVG1.1, I think the Opera interpretation is correct
21:33:35 <nikos> http://www.w3.org/TR/SVG/types.html#__svg__SVGLocatable__getBBox
21:34:26 <shepazu> "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."
21:34:50 <shepazu> nikos: and I think the bbox is (0.)) centered at the location
21:35:02 <shepazu> s/(0.))/(0,0)
21:35:52 <shepazu> shepazu: agree, and we should be more explicit in SVG2
21:36:20 <shepazu> heycam: yes, there needs to be an exact definition
21:37:24 <shepazu> Resolution: Bounding Box should return correct x,y coordinates, even for 0-sized (non-rendered) elements, and the SVG2 spec should define that
21:38:33 <shepazu> action: shepazu to clarify bbox position for 0-sized (non-rendered) elements in SVG2
21:38:33 <trackbot> Created ACTION-3313 - Clarify bbox position for 0-sized (non-rendered) elements in SVG2 [on Doug Schepers - due 2012-07-05].
21:38:48 <shepazu> agenda+ pointer-events
21:39:20 <jet> jet has joined #svg
21:40:03 <ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feConvolveMatrixElementOrderAttribute
21:40:11 <shepazu> Topic: Rounding behavior for the 'order' attribute of feConvolveMatrix
21:40:13 <heycam> http://www.w3.org/Graphics/SVG/WG/track/issues/2438
21:40:46 <shepazu> heycam: the order attribute takes an integer, but it doesn't specify the behavior
21:41:18 <shepazu> … it's a bit tricky, because the syntax definition says it takes (number, optional number), says floats, but expects integers
21:41:45 <shepazu> … do we round in a particular way, or consider floats to be invalid, or what?
21:42:10 <shepazu> ed: I think rounding is more consistent with other cases
21:42:19 <shepazu> … and prefer not adding a new type
21:42:41 <shepazu> … it's used together with kernal matrix… 
21:42:59 <shepazu> … not sure how common it is to have float values, probably not very common
21:43:06 <shepazu> … or in animation
21:43:32 <shepazu> Tav: it makes no sense to change this, without also changing the kernalMatrix
21:44:22 <shepazu> Tav: the kernalMatrix has a list of numbers, and the order attribute defines those
21:44:46 <shepazu> heycam: probably would have been better to define microsyntax
21:44:53 <ed> s/kernalMatrix/kernelMatrix/
21:45:02 <shepazu> q+
21:45:50 <shepazu> shepazu: rounding is probably friendliest error-correction
21:46:38 <shepazu> Tav: the person should know they made a mistake
21:46:57 <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."
21:47:03 <shepazu> heycam: we could throw a console warning, and still let it round
21:48:34 <shepazu> Tav gives up in disgust
21:48:54 <shepazu> s/Tav gives up in disgust//
21:50:23 <shepazu> Resolution: float values in the 'order' attribute of feConvolveMatrix will use traditional rounding to an integer value, and will through a console log warning
21:51:16 <shepazu> 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
21:51:16 <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].
21:52:14 <heycam> ScribeNIck: heycam
21:52:20 <heycam> ScribeNick: heycam
21:52:23 <heycam> Topic: pointer events
21:52:58 <heycam> DS: the pointer-events property is now implemented for HTML in all the browsers?
21:53:13 <heycam> ED: not sure
21:53:41 <heycam> DS: it's been removed from the css3-ui spec, because hit testing isn't defined for the web platform anywhere
21:54:02 <heycam> … 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
21:54:30 <heycam> … so I suggest we go to the CSS WG and ask for this to be a module for css ui
21:55:23 <heycam> … basically that we just propose there's a spec
21:55:33 <heycam> … and that it's in charter because it was in css3-ui previously
21:55:50 <heycam> … and that we decide amongst ourselves who might edit that spec
21:56:12 <heycam> … and to do that work in the FX group, or purely CSS
21:56:18 <heycam> CM: FX sounds good
21:56:58 <heycam> CM: 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
21:57:40 <heycam> DS: I'm happy to work on it
21:58:12 <heycam> … annevk had sent in a lot of good feedback on the hit testing, so I'll try and find that
21:59:35 <heycam> RESOLUTION: We will approach the CSS WG about a hit testing and pointer events joint spec
22:00:11 <Zakim> -heycam
22:00:12 <Zakim> -nikos
22:00:14 <Zakim> -ed
22:00:14 <Zakim> -Tav
22:00:16 <Zakim> GA_SVGWG(SVG1)5:00PM has ended
22:00:16 <Zakim> Attendees were Doug_Schepers, heycam, nikos, ed, Tav
22:00:28 <heycam> RRSAgent, make minutes
22:00:28 <RRSAgent> I have made the request to generate http://www.w3.org/2012/06/28-svg-minutes.html heycam
22:21:41 <heycam> nikos, http://www.boganipsum.com/ :D
22:35:26 <nikos> struth!
22:41:25 <shepazu> oh, you aussies...
22:59:10 <birtles> birtles has joined #svg