12:58:02 <RRSAgent> RRSAgent has joined #svg
12:58:02 <RRSAgent> logging to http://www.w3.org/2014/06/12-svg-irc
12:58:04 <trackbot> RRSAgent, make logs public
12:58:04 <Zakim> Zakim has joined #svg
12:58:06 <trackbot> Zakim, this will be GA_SVGWG
12:58:06 <Zakim> ok, trackbot, I see GA_SVGWG()9:00AM already started
12:58:07 <trackbot> Meeting: SVG Working Group Teleconference
12:58:07 <trackbot> Date: 12 June 2014
12:58:52 <Zakim> +[IPcaller.a]
12:58:54 <birtles> Zakim, who is on the call?
12:58:55 <Zakim> On the phone I see [IPcaller], [IPcaller.a]
12:59:08 <birtles> Zakim, [IPcaller] is me
12:59:09 <Zakim> +[IPcaller.aa]
12:59:09 <Zakim> +birtles; got it
12:59:23 <heycam> Zakim, [IPcaller.aa] is me
12:59:23 <Zakim> +heycam; got it
12:59:44 <ed> Zakim, [IPcaller.a] is me
12:59:44 <Zakim> +ed; got it
12:59:49 <heycam> Agenda: http://lists.w3.org/Archives/Public/www-svg/2014Jun/0038.html
12:59:51 <heycam> Chair: Cameron
13:01:16 <heycam> Zakim, who is making noise?
13:01:29 <Zakim> heycam, listening for 12 seconds I heard sound from the following: birtles (88%)
13:02:28 <Zakim> +??P3
13:02:44 <stakagi> zakim, ??P3 is me
13:02:44 <Zakim> +stakagi; got it
13:03:01 <Zakim> +[IPcaller]
13:03:23 <cabanier> zakim, [ipcaller] is me
13:03:23 <Zakim> +cabanier; got it
13:04:37 <Zakim> +[IPcaller]
13:04:50 <Zakim> -[IPcaller]
13:05:09 <birtles> scribenick: birtles
13:05:21 <birtles> scribe: birtles
13:05:29 <birtles> topic: Missing 'turn' unit in SVGAngle
13:05:35 <Zakim> + +1.415.832.aaaa
13:05:42 <ed> http://www.w3.org/2013/07/11-svg-minutes.html#item05
13:05:49 <birtles> ed: I spoke with Dirk about this and we already had a resolution for this
13:05:57 <birtles> ... we decided not to add new IDL constants for the old SVG DOM
13:06:12 <Zakim> +Tav
13:06:12 <birtles> ... so the previous resolution wasn't exactly clear what we should do with new units for example
13:06:24 <birtles> ... for parts of the DOM that expect a unit
13:06:25 <krit> Zakim, aaaa is me
13:06:25 <Zakim> +krit; got it
13:06:34 <birtles> ... I take this to mean we don't want to change any of the behaviour
13:06:46 <birtles> ... i.e. act as if those new units weren't supported when you inspect the SVG DOM
13:06:55 <birtles> heycam: so you'd get the unknown value when you look up the unit?
13:07:10 <birtles> ed: and if you use valueAsString you'd get the default value as if the unit wasn't supported
13:07:20 <birtles> ... since the new resolution only concerned not adding new IDL constants
13:07:28 <birtles> ... I wanted to make sure the rest was covered
13:07:39 <birtles> heycam: we've had a few instances of this kind of thing of not having a new constant in the IDL
13:07:49 <birtles> ... but these issues that you bring up now show that it's kind of awkward
13:07:56 <birtles> ... it makes those interfaces completely useless
13:08:08 <birtles> ... I wonder what we should do if in the future we don't go ahead with the new SVG DOM proposal
13:08:17 <birtles> ... in that case perhaps we should extend these old interfaces
13:08:28 <birtles> ... or should we say you can only use get/setAttribute for these new unit types
13:08:37 <birtles> krit: most of these libraries just use get/setAttribute
13:09:18 <birtles> ... most of attributes get presentation properties and then they can use 'style' for examples to set the value
13:09:22 <birtles> ... and get the string
13:09:26 <heycam> element.style.someAngledProperty = '2turn'
13:09:28 <birtles> ... with, of course, the units
13:10:05 <birtles> ... I don't want to shut the door on the SVG DOM but maybe we should wait until we decide what we want to do with the SVG DOM
13:10:09 <birtles> ... but keep it as it is for now
13:10:24 <birtles> heycam: so keep things exactly as they are for now until we finally decide what we're doing with the DOM
13:10:37 <birtles> ... then we can add the constants or not depending on which course we take
13:11:11 <birtles> ... it would be great to have that behavior defined in the spec (re: when you use one of the new units)
13:11:17 <birtles> ed: I think it is defined already
13:11:26 <birtles> ... it's just the angle interface is not so useful
13:11:35 <birtles> ... it basically just behaves as if the unit was not supported
13:11:44 <birtles> heycam: ok, I guess the existing spec text is sufficient
13:11:54 <birtles> ed: yes, I think it is, but I just wanted to confirm that's what we wanted
13:12:06 <birtles> ... SVGAngle is not so useful but the same issue applies to SVGLength and SVGTransform
13:12:10 <birtles> heycam: I'm ok with that
13:12:33 <birtles> ed: I think the existing resolution and spec text is enough but just wanted to confirm
13:12:43 <birtles> topic: Aiming for SVG Integration Last Call by April 2015
13:13:06 <birtles> heycam: I was speaking with Vlad who works on the OpenType font format spec which is the spec with the SVG table now
13:13:17 <birtles> ... we've been discussing what to do about the reference to the SVG Integration spec
13:13:29 <birtles> ... April 2015 is basically the last point where they can update references in the spec
13:13:48 <birtles> ... so if the SVG Integration spec can be in last call by then, then it's fine to leave it in as a normative reference
13:14:10 <birtles> ... I need to check if that would mean the LC URL would be baked in, or if we could use the more general URL
13:14:15 <birtles> ... but that's the timeline
13:14:29 <birtles> ... so I wanted to see if we can have something usefully at LC by then?
13:14:42 <birtles> krit: I think we should try to do it before then
13:15:16 <birtles> heycam: there is a period for final comments for the MPEG group which finishes in about 1.5 days
13:15:30 <birtles> ... I'll send in a few suggested wording tweaks including suggestions about the SVG reference
13:15:56 <birtles> topic: Moving definition of getSVGDocument to HTML
13:16:27 <birtles> ed: I think I got this from Simon Pieters and I think we should go ahead and let HTML define getSVGDocument
13:16:32 <birtles> ... basically removing it from the SVG spec
13:16:56 <birtles> heycam: so getSVGDocument was a function the Adobe player exposed on the <object> and <embed> elements when they referenced an SVG document
13:17:07 <birtles> ... as a way of getting to the SVG document DOM
13:17:12 <birtles> ... since then contentDocument has been added
13:17:21 <birtles> ... and people should use that, so getSVGDocument is a bit useless
13:17:41 <birtles> ... getSVGDocument is defined to be the same thing as contentDocument but it isn't precise
13:18:00 <birtles> ... it's probably easier to define in HTML where definitions about browsing contexts etc. are available
13:18:11 <birtles> ed: I think contentDocument doesn't work for <embed> elements
13:18:17 <birtles> heycam: does getSVGDocument work?
13:18:20 <birtles> ed: yes, I believe so
13:18:53 <birtles> heycam: somebody asked me again recently what was the status of this and whether it was ok for the HTML spec to add it and us to remove it
13:18:59 <birtles> ... any objections?
13:19:04 <birtles> ??: no
13:19:23 <birtles> RESOLUTION: SVG2 will remove the definition of getSVGDocument and it will move to the HTML spec
13:19:44 <birtles> topic: Geometry interfaces: Replace isIdentity?
13:19:51 <krit> http://dev.w3.org/fxtf/geometry/
13:21:44 <birtles> krit: we had some discussions about isIdentity and to have something more reliable like hasTransform which basically returns false if there are no transforms on the matrix
13:21:57 <birtles> ... so it's more reliable because something that has not been transformed is definitely not identity
13:22:27 <birtles> ... but at the end I think people thought it was more useful to have isIdentity even if might return false sometimes where it could return true
13:22:48 <birtles> ... I think at the end we agreed on the behavior but I just wanted to tell the group about it
13:23:06 <birtles> ... in the end isIdentity is used for optimizations so it just means the code might not run as optimally as it could
13:23:43 <birtles> ... there are cases where you transform something and transform it back and you might end up returning false in that case
13:23:49 <birtles> ... but hasTransform would also return false then
13:23:58 <birtles> ... isIdentity would return true more often than hasTransform
13:24:14 <birtles> heycam: so how is this different from what is currently defined?
13:24:17 <birtles> krit: it's not
13:24:22 <birtles> cabanier: hasTransform never made it into the spec
13:24:29 <birtles> heycam: so it just checks for 0s and 1s?
13:24:34 <birtles> krit: yes, the simple-minded way
13:25:40 <birtles> topic: Geometry interfaces: various issues
13:25:53 <birtles> http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0164.html
13:25:59 <birtles> krit: is2D is the next issue
13:26:16 <birtles> ... after discussion we decided to make this track transformations
13:26:25 <birtles> ... if you have transforms that are 3D it will return false
13:26:31 <birtles> ... if all transforms are 2D it will return true
13:26:49 <birtles> heycam: so it's a flag that once it becomes false it stays that way?
13:26:52 <birtles> krit: right
13:27:05 <birtles> ... this is something that Benoit preferred and I'm fine with it too
13:27:13 <birtles> heycam: so it requires you to store extra state in the object
13:27:33 <birtles> cabanier: but usually you just allocate a 2D matrix until a 3D transformation is made and then you swap it out
13:27:41 <birtles> heycam: so you'd have some state there already
13:27:53 <birtles> krit: I think that was the only open issue there
13:28:33 <birtles> ... the use case came from when you have rotation points around the x-axis
13:28:56 <birtles> ... if you swap to 3D and back for one frame that would be odd
13:29:23 <birtles> heycam: in what cases do you expect authors to use it?
13:29:47 <birtles> krit: it might be the result of some calculation that you need to check if you need to switch to 3D calculations or not
13:30:18 <birtles> ... I definitely want people to view the spec and send objections to the list
13:30:50 <birtles> krit: Geometry interfaces: replacee translateBy by translateSelf for better expressiveness?
13:30:58 <birtles> topic: Geometry interfaces: replacee translateBy by translateSelf for better expressiveness?
13:31:21 <birtles> krit: people found translateBy confusing, we think translateSelf is easier to understand
13:31:24 <birtles> heycam: I agree
13:31:35 <birtles> krit: the other suggestion was 'this' instead of 'self'
13:31:42 <birtles> heycam: I'm not sure which I prefer
13:32:27 <birtles> krit: another topic which may need agreement of WG was whether we should have 'invert' or 'invertSelf'
13:32:41 <birtles> ... SVG has 'inverse'
13:32:52 <birtles> ... but 'invertSelf' is more consistent with the other methods
13:33:06 <birtles> heycam: what's the plan for aligning SVGMatrix and DOMMatrix?
13:33:14 <birtles> ... does SVGMatrix inherit from DOMMatrix or alias it?
13:33:17 <birtles> krit: alias it
13:33:29 <birtles> heycam: in that case, will there still be an Inverse method for compatibility
13:33:42 <birtles> ed: SVG's Inverse returns a new matrix I think
13:33:48 <birtles> krit: yes
13:34:08 <birtles> ... so any objections to adding 'invertSelf'
13:34:19 <birtles> heycam: it seems bad to have 'invert' and 'inverse'
13:34:26 <birtles> cabanier: it would be 'inverse' and 'invertSelf'
13:34:55 <birtles> heycam: I though Dirk was suggesting we have 'invert' for consistency
13:35:19 <birtles> krit: no, the question was do we want to rename 'invert' to 'invertSelf'
13:35:23 <birtles> heycam: yes, definitely
13:35:42 <birtles> ... do you think it's a silly idea to have 'invert' as well?
13:35:50 <birtles> krit: why?
13:35:56 <birtles> heycam: for completeness and matching the pattern
13:35:56 <heycam> 'inverse', 'invert', 'invertSelf'
13:36:04 <heycam> where inverse means the same as invert
13:36:15 <birtles> ... I would probably shy away from having all 3 but it's also tempting to have for completeness
13:36:30 <birtles> krit: we keep inverse, that's for sure
13:36:46 <birtles> ... would invert modify itself?
13:37:00 <birtles> ... I'm not a fan of adding things for completeness
13:37:11 <birtles> heycam: ok, we can add it later
13:37:15 <birtles> cabanier: we can always add it later
13:37:44 <birtles> heycam: the other matrix interfaces you want to have compatibility with, MSMatrix, WebkitMatrix etc., what do they have on them?
13:37:54 <cabanier> https://developer.apple.com/library/safari/documentation/AudioVideo/Reference/WebKitCSSMatrixClassReference/WebKitCSSMatrix/WebKitCSSMatrix.html
13:38:01 <birtles> ... is it a goal to be compatible with them or just to have the same features
13:38:18 <birtles> krit: it would be good to be compatible. Both have inverse, just like SVGMatrix
13:38:30 <birtles> heycam: do they have the other methods that modify the same object?
13:38:40 <birtles> krit: no, they only have the methods that return a new object
13:39:26 <birtles> cabanier: WebKitCSSMatrix has setMatrixValue
13:39:58 <birtles> krit: I didn't add it because it seems to be redundant
13:40:05 <birtles> ... with the constructor that also takes a string
13:40:21 <birtles> heycam: so you couldn't modify an existing object by giving it a value using a string
13:40:25 <birtles> krit: yes, that's correct
13:40:32 <birtles> ... if there's a need for that, we'll add it then
13:41:02 <birtles> cabanier: you don't have any plans to alias WebKitCSSMatrix to DOMMatrix right?
13:41:08 <birtles> krit: actually, yes I'd like to do that
13:41:25 <birtles> ... but I'd still like to make setMatrixValue not part of DOMMatrix
13:41:33 <birtles> ... not sure yet how I will do that, but somehow
13:42:05 <birtles> cabanier: (checking github to see if anyone uses setMatrixValue)
13:43:22 <birtles> krit: Rik mentioned that he would like to make isIdentity and is2D readonly attributes
13:43:28 <birtles> ... it's just a cosmetic issue
13:43:51 <birtles> ... I'd like to make them the same (i.e. both attributes or both methods)
13:43:59 <birtles> ... I'm leaning towards methods
13:44:14 <birtles> ... attributes seem to suggest something is stored whereas methods suggest checking something
13:44:26 <birtles> ... it's not a hard-and-fast rule but that's how I understand it
13:44:30 <birtles> ... what does the group think?
13:44:41 <birtles> heycam: from my intuition I think attributes are right
13:44:50 <birtles> ... I think it's fine to have attributes that reflect some state of the object
13:44:58 <birtles> ed: I think I agree with Cameron
13:45:04 <birtles> krit: ok, we'll change it to attributes
13:45:40 <birtles> cabanier: I found some places where setMatrixValue are used
13:45:49 <birtles> krit: should we add it then, or try to avoid it?
13:46:18 <birtles> heycam: I think it would be handy to be able to assign with a string value
13:46:27 <birtles> ... is it also on MSCSSMatrix
13:46:30 <birtles> krit: yes
13:46:34 <birtles> heycam: then I'd say go with that
13:46:47 <birtles> krit: the last question, should the in-place transformations return the same object?
13:46:53 <cabanier> for instance: https://github.com/yui/yui3-gallery/blob/5b0e2d507be5916560aebae04f8a74d4211af402/src/gallery-node-transform2d/js/node-transform2d.js#L20
13:47:01 <birtles> ... for example translateSelf, changes it in place
13:47:10 <birtles> ... should it return the same object?
13:47:39 <cabanier> should the xxxSelf function return the object?
13:47:54 <krit> everything is void atm
13:47:55 <cabanier> so m.translateSelf(...).scaleSelf(...)
13:48:04 <krit> matrix.translateSelf()
13:48:09 <krit> matrix.scaleSelf()
13:48:15 <krit> matrix.translateSelf()
13:48:16 <birtles> krit: the current return value of these is void
13:48:19 <krit> change this to
13:48:30 <krit> m.translateSelf(...).scaleSelf(…).translateSelf(...)
13:48:43 <birtles> ... I would like to change it so it returns the object and you can chain like this ^
13:48:51 <birtles> birtles: why would you not do that?
13:49:27 <birtles> heycam: I'm not sure I'm a fan of that kind of chaining style approach in general but I think it makes sense in this case
13:49:44 <birtles> ... since I think you often want to do these operations in a row
13:50:13 <birtles> birtles: promises use a lot of chaining
13:50:37 <ed> why would one not do m.stringSetter = "translate...scale ... translate"
13:51:08 <birtles> ed: repeating "self" a lot is a bit redundant
13:51:28 <birtles> krit: that's because we're dealing with the legacy of SVGMatrix which took the short names
13:52:03 <birtles> heycam: you could change 'self' to 'me' :)
13:52:09 <birtles> ... translateMe
13:52:24 <birtles> krit: the benefit of 'me' is it's shorter (same as 'by')
13:52:30 <birtles> heycam: I think 'self' is better
13:52:48 <birtles> krit: I will make all these changes
13:52:54 <birtles> ... I would like to have people review the spec
13:53:07 <birtles> ... I'd like people to have a look after I've made the changes too
13:53:15 <birtles> ... I will have it done today or so
13:53:34 <birtles> ... I would like to ask for last call in the next week or the week after
13:53:39 <Zakim> -Tav
13:53:46 <birtles> ... it depends if working group members want more time for review
13:53:54 <birtles> ... just let me know by next week if you need more time or not
13:54:19 <birtles> ... I'll send a mail to the WG and to www-style as well
13:54:21 <Zakim> +Tav
13:54:47 <birtles> topic: F2F in London
13:54:53 <birtles> heycam: I've booked a room for the F2F
13:55:27 <birtles> ... I need to tell the office person a few weeks beforehand about numbers/dietary requirements so plenty of time still
13:55:34 <birtles> ... Chris sent up a registration form for it
13:55:40 <birtles> ... I'll look into hotels too
13:56:53 <Zakim> -ed
13:56:56 <Zakim> -heycam
13:56:57 <Zakim> -Tav
13:56:58 <Zakim> -krit
13:56:58 <Zakim> -cabanier
13:57:00 <Zakim> -birtles
13:57:00 <Zakim> -stakagi
13:57:00 <Zakim> GA_SVGWG()9:00AM has ended
13:57:00 <Zakim> Attendees were birtles, heycam, ed, stakagi, cabanier, [IPcaller], +1.415.832.aaaa, Tav, krit
13:57:10 <heycam>  /me birtles do you wear a headset?
13:58:40 <krit> s/by/me/
13:58:47 <krit> my
13:58:59 <birtles> apologies: Nikos
13:59:11 <birtles> RRSAgent, make minutes
13:59:11 <RRSAgent> I have made the request to generate http://www.w3.org/2014/06/12-svg-minutes.html birtles
13:59:47 <birtles> RRSAgent, do it now please
13:59:47 <RRSAgent> I'm logging. I don't understand 'do it now', birtles.  Try /msg RRSAgent help
14:02:34 <birtles> RRSAgent, I get a 404 for that URL
14:02:34 <RRSAgent> I'm logging. I don't understand 'I get a 404 for that URL', birtles.  Try /msg RRSAgent help
14:03:37 <birtles> RRSAgent, pointer
14:03:37 <RRSAgent> See http://www.w3.org/2014/06/12-svg-irc#T14-03-37
14:04:18 <birtles> RRSAgent, please make minutes
14:04:18 <RRSAgent> I have made the request to generate http://www.w3.org/2014/06/12-svg-minutes.html birtles
14:07:31 <birtles> Regrets: nikos
14:07:35 <birtles> RRSAgent, please make minutes
14:07:35 <RRSAgent> I have made the request to generate http://www.w3.org/2014/06/12-svg-minutes.html birtles
15:27:47 <Zakim> Zakim has left #svg
15:45:13 <glenn> glenn has joined #svg
17:39:16 <thorton> thorton has joined #svg
17:41:32 <thorton> thorton has joined #svg
17:41:43 <thorton> thorton has joined #svg
19:21:46 <shepazu> shepazu has joined #svg
20:12:50 <krit> heycam|away: should Geomerty Interfaces add typedef DOMMatrix SVGMatrix; typedef DOMPoint SVGPoint and typedef DOMRect SVGRect; ?
23:41:20 <jdaggett> jdaggett has joined #svg
23:46:52 <heycam> krit, typedef will only make it so that we don't have to update our IDL in SVG 2 to refer to DOMMatrix etc. it won't do the actual aliasing, which we'll need to write in prose.
23:47:02 <heycam> krit, probably not worth it -- I think we should update the types in SVG 2 instead