20:58:14 <RRSAgent> RRSAgent has joined #svg
20:58:14 <RRSAgent> logging to http://www.w3.org/2013/01/10-svg-irc
20:58:16 <trackbot> RRSAgent, make logs public
20:58:16 <Zakim> Zakim has joined #svg
20:58:18 <trackbot> Zakim, this will be GA_SVGWG
20:58:18 <Zakim> ok, trackbot, I see GA_SVGWG(SVG1)4:00PM already started
20:58:19 <trackbot> Meeting: SVG Working Group Teleconference
20:58:19 <trackbot> Date: 10 January 2013
20:58:52 <Zakim> + +61.2.980.5.aaaa
20:59:02 <nikos> Zakim, +61 is me
20:59:02 <Zakim> +nikos; got it
20:59:03 <ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013JanMar/0001.html
20:59:08 <Zakim> +cabanier
20:59:13 <birtles> birtles has joined #svg
20:59:30 <krit> Zakim, who is on the phone?
20:59:30 <Zakim> On the phone I see krit, nikos, cabanier
20:59:40 <Zakim> +[IPcaller]
20:59:55 <Tav> Tav has joined #svg
20:59:56 <ed> Zakim, [IP is me
20:59:56 <Zakim> +ed; got it
21:01:55 <Zakim> +[IPcaller]
21:01:59 <heycam> Zakim, [IPcaller] is me
21:01:59 <Zakim> +heycam; got it
21:02:21 <krit> "G'day"
21:02:22 <Zakim> +[IPcaller]
21:02:36 <birtles> Zakim, IPcaller is me
21:02:36 <Zakim> +birtles; got it
21:03:21 <Zakim> + +33.9.53.77.aabb
21:03:26 <heycam> Zakim, who is noisy?
21:03:38 <Zakim> heycam, listening for 10 seconds I heard sound from the following: cabanier (22%), heycam (13%), +33.9.53.77.aabb (5%)
21:03:46 <Tav> zakim, aabb is me
21:03:46 <Zakim> +Tav; got it
21:04:04 <nikos> scribenick: nikos
21:04:15 <nikos> Topic: SVGDefinitionElement
21:04:25 <ed> http://lists.w3.org/Archives/Public/www-svg/2012Dec/0097.html
21:04:47 <ed> chair: ed
21:04:48 <nikos> heycam: When I was converting interfaces to WebIDL, I added SVGDefinitionElement for all the elements which are like definitions
21:05:04 <nikos> ... the only benefit it provides is it's a single place that the SVGTest interface can go off
21:05:15 <nikos> ... SVGTest has the DOM properties for systemLanguage, etc
21:05:30 <nikos> ... it was pointed out to me that the clip_path element doesn't have those attributes on it
21:06:03 <nikos> ... if that's the case, maybe it's not worth having it in the first place
21:06:15 <nikos> ... maybe it's better implementing SVGTests directly on elements that need it
21:06:34 <nikos> ed: I think that makes sense
21:07:03 <nikos> heycam: it does bring up the question of clippath not having these conditional processing attributes
21:07:07 <nikos> ... do we want to change that?
21:09:07 <nikos> krit: for pattern, mask, etc. We have to distinguish between pattern units, etc, we don't have to do that for clippath. I think it's hard to align clippath with the other elements anyway.
21:09:22 <heycam> https://svgwg.org/svg2-draft/struct.html#ConditionalProcessingOverview
21:09:51 <nikos> heycam: the spec currently says conditional processing attributes have no effect on clippath and a variety of other elements
21:10:16 <nikos> ... There are others that aren't mentioned, i.e. filter
21:10:38 <nikos> ... I just wanted to confirm that these kinds of elements would remain not being affected by conditional processing attributes
21:10:57 <nikos> ed: have you tested to see what implementations do with these?
21:11:17 <nikos> ... I wouldn't be surprised if it just happened to work because of the way things are implemented, but I haven't tested
21:11:28 <nikos> heycam: Opera seems to do the right thing, Mozilla does the wrong thing
21:11:51 <nikos> ed: I would think that if if you used conditional processing attributes on patterns I would think it might work
21:12:41 <heycam> http://lists.w3.org/Archives/Public/www-svg/2012Dec/0102.html
21:12:44 <ed> s/ patterns I would think it might work/ patterns I would think it might work, as in such attributes used inside the pattern, but perhaps not when used on the <pattern> element itself/
21:13:27 <nikos> heycam: I think the current behaviour in the spec is fine, just wanted to confirm
21:13:48 <nikos> krit: is chrome following the spec?
21:13:54 <nikos> heycam: it is for half the elements, but not the other half
21:14:18 <nikos> ... the ones that are explicitly mentioned in the spec, it's doing the wrong thing for. For the ones that aren't mentioned it's doing the right thing
21:14:24 <richardschwerdtfeger> richardschwerdtfeger has joined #svg
21:16:56 <nikos> resolution: Elements that conditional processing attributes shall remain as is in the spec, we will clarify that gradient and fillpath are also not affected.
21:17:53 <nikos> Topic: animateMotion on shapes
21:18:07 <ed> http://lists.w3.org/Archives/Public/www-svg/2012Dec/0101.html
21:18:33 <nikos> heycam: There is a thread on the list talking about animateMotion applying to shapes other than path
21:18:39 <ed> s/fillpath/filter/
21:18:50 <Zakim> -nikos
21:19:21 <Zakim> +nikos
21:19:36 <Zakim> +Doug_Schepers
21:20:13 <nikos> heycam: there didn't seem to be anyone who is against the idea and I think it's reasonable simpmle.
21:20:15 <shepazu> +1
21:20:18 <nikos> s/simpmle/simple
21:20:39 <nikos> birtles: Cam, you just mentioned that supporting use might be problematic but the others are fine
21:20:48 <nikos> ed: I agree, use is more complex
21:20:56 <nikos> ... it would potentially be the same as allowing groups
21:20:58 <shepazu> q+
21:21:20 <krit> Zakim, shepazu q- ;)
21:21:20 <Zakim> I'm glad that smiley is there, krit
21:21:22 <nikos> shepazu: could we define it as well for groups?
21:21:47 <nikos> ... there's the document order for the group, effectively it's the same as defining it for a path that has multiple 'm's
21:22:03 <nikos> ... I don't know how hard it would be to implement, but defining is ok
21:22:50 <nikos> ed: animating each of the sub elements would be fun
21:23:14 <nikos> shepazu: that brings up another question, what happens if the path is animating?
21:23:30 <nikos> krit: it was demonstrated a couple of years ago at SVG Open - it works
21:23:45 <nikos> shepazu: if it was pointing at itself, what happens?
21:23:58 <nikos> heycam: the thing pointing is mpath
21:24:13 <nikos> ... if you had it pointing to a group, the thing that is being animated could be within that group as well
21:24:26 <nikos> ... the motion animation doesn't affect the link to the path
21:24:30 <nikos> ... it would affect the position
21:26:05 <nikos> heycam: lets do the simple features
21:26:33 <nikos> ed: I agree, it might be nice to have more complex elements in future, but we would need to think about it more
21:27:06 <nikos> shepazu: I think the easiest for us is to not allow use, and we can re-visit in future if there's a need
21:27:19 <nikos> ... shouldn't work for 'g' either, should only work on a single shape
21:27:35 <nikos> ... doesn't address the problem of pointing to itself
21:28:11 <nikos> ... where the path being animated is the path being followed
21:28:52 <nikos> heycam: I think we should check the spec to make sure we are defining what happens in that situation
21:30:38 <nikos> resolution: simple shapes such as circle, rect, etc, will be supported by animateMotion. use and groups will not be supported.
21:31:13 <Zakim> +[IPcaller]
21:31:43 <nikos> shepazu: I want to make sure, with the recursion question, that pointing to paths or mutiple elements isn't any more of a problem than with simple shapes
21:32:13 <richardschwerdtfeger> zakim +[IPCaller is Rich
21:32:33 <richardschwerdtfeger> zakim [IPCaller is Rich
21:32:58 <richardschwerdtfeger> zakim, +[IPCaller is Rich
21:32:58 <Zakim> sorry, richardschwerdtfeger, I do not recognize a party named '+[IPCaller'
21:33:14 <nikos> ed: I don't think its harder to deal with recursion, we already have loop detection algorithms that can be tweaked. Implementation wise, tracking multiple elements is a bit more work, so there is a cost.
21:33:15 <heycam> http://mcc.id.au/temp/motion.svg
21:34:45 <nikos> heycam: I think, looking at that, the animateMotion is only looking at the base path
21:36:44 <nikos> shepazu: did we decide whether the animation should be taken into account when recursion is used?
21:36:48 <nikos> heycam: I think it cant'
21:37:00 <nikos> s/cant'/can't
21:38:05 <nikos> note for the minutes: cam's file changed from animating along a linear path to animating around a circular path
21:40:35 <nikos> krit: maybe we could copy what clip path is defining in regards to a set of objects
21:42:34 <nikos> resolution:The element that mpath references should not look at the motion animation of that element
21:44:28 <nikos> action: Brian to ensure the specification explicitly disallows the element that mpath references from looking at the motion animation of that element
21:44:28 <trackbot> Created ACTION-3408 - Ensure the specification explicitly disallows the element that mpath references from looking at the motion animation of that element [on Brian Birtles - due 2013-01-17].
21:45:36 <nikos> action: Brian to update SVG 2 specification to allow simple shapes to be referenced by animateMotion
21:45:36 <trackbot> Created ACTION-3409 - Update SVG 2 specification to allow simple shapes to be referenced by animateMotion [on Brian Birtles - due 2013-01-17].
21:45:53 <nikos> Topic: xml{base,lang,space} IDL attributes
21:46:01 <ed> http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDec/0077.html
21:46:12 <nikos> heycam: FireFox currently doesn't implement the DOM properties for these attributes
21:46:29 <nikos> ... somebody wrote a patch to implement them
21:46:48 <nikos> ... this made me wonder if we should implement all, or some, because we are trying t move away from xml:space
21:47:27 <nikos> ... I think we want to keep the xml :space behaviour, but using a white space property instead
21:47:42 <nikos> shepazu: I don't agree that we should keep around xml: space
21:47:51 <nikos> ... I think we should deprecate the attribute
21:47:56 <nikos> ed: we already agreed on that
21:48:01 <nikos> heycam: but we keep the behaviour
21:48:20 <nikos> ... are you suggesting we removing processing the attribute even if you do use it?
21:48:25 <nikos> shepazu: why do we need to keep it?
21:48:28 <nikos> heycam: a lot of people use it
21:49:28 <nikos> shepazu: are we making SVG 2 into HTML5 where the behaviour of SVG is the same. i.e. where SVG 2 is to SVG 1.1 what HTML 5 is to HTML 4.
21:50:40 <nikos> shepazu: I think the changes in SVG 2 are so profound (some change existing SVG behaviour), and the effect of xml: space are actually fairly rare. People use it, but the only thing it means is don't get rid of the spaces
21:50:58 <nikos> ... I think the only place it has an effect is when you put in multiple spaces and you want those kept in the content - not collapsed
21:51:22 <nikos> ... so the only side effect of not supporting it is that white space which before kept multiple spaces between letters will now collapse down to a single space
21:51:30 <nikos> ... I don't think that's enough of a reason to keep it
21:53:30 <nikos> krit: I'm fine with deprecating it, but not sure about removing it.  A lot of implementations support it
21:53:58 <nikos> heycam: my suggestion was to handle xml space as a user style sheet rule, so it gets mapped to an appropriate property value
21:54:03 <nikos> ... that would remove the need for special implementation for it
21:54:12 <nikos> ... but would allow it to be used in content
21:55:08 <nikos> shepazu: I would like to obsolete it and say user agents are not required to do anything with it. If UAs want to behave like SVG 1.1 they could
21:55:21 <nikos> ... but I don't think its that important
21:55:29 <Zakim> -Tav
21:56:18 <Zakim> +Tav
21:56:21 <nikos> ... we should at least deprecate it, which means we will still define behaviour for it and authoring tools should still implement it but authors shouldn't use it.
21:59:32 <nikos> action: Cameron to investigate xml base, and other xml attributes in the IDL and whether they're implemented
21:59:32 <trackbot> Created ACTION-3410 - Investigate xml base, and other xml attributes in the IDL and whether they're implemented [on Cameron McCormack - due 2013-01-17].
21:59:55 <Zakim> -birtles
22:00:58 <nikos> ARIA markup
22:01:02 <nikos> Topic: ARIA markup
22:01:13 <ed> http://lists.w3.org/Archives/Public/public-svg-wg/2013JanMar/0006.html
22:01:42 <nikos> krit: I agree with the list in that email
22:02:14 <nikos> krit: it's every element that has no content
22:02:21 <nikos> heycam: I think theres a couple that might want ARIA markup
22:02:26 <nikos> ... like tspan
22:02:31 <nikos> shepazu: title, metadata, desc
22:02:45 <nikos> richardschwerdtfeger: desc is a description for something else right?
22:02:54 <nikos> shepazu: correct, it is a child of an element
22:03:06 <nikos> richardschwerdtfeger: you wouldn't navigate to it or anything
22:03:22 <nikos> ... the criteria we used is in the post
22:04:08 <nikos> shepazu: I thought with ARIA you define the behaviour in the DOM
22:04:40 <nikos> richardschwerdtfeger: the description would be applied to an object and exposed as the description for that object
22:05:51 <nikos> shepazu: there would be a native mapping of some SVG elements to acce APIs and among those would be title and description which would have a native mapping, they describe what they are a child of. So we don't need to apply ARIA attributes to those at all.
22:05:54 <nikos> richardschwerdtfeger: correct
22:06:13 <nikos> ... SVG already has relationships that can be used already
22:06:18 <nikos> shepazu: what about tspan?
22:06:34 <nikos> richardschwerdtfeger: I understood that tspan doesn't include content in your page, it is a reference within a span of text
22:06:48 <nikos> heycam: it's a span element itself
22:07:01 <nikos> richardschwerdtfeger: tspan should not be in the list then
22:07:13 <nikos> ed: same for textpath as well
22:08:07 <nikos> richardschwerdtfeger: We will remove tspan and textpath from the list
22:08:30 <nikos> shepazu: in SVG 1.2 tiny we said that you could apply the ARIA property 'tooltip' to a title which was a child of an element
22:08:43 <nikos> ... that might give behaviour of providing a tooltip
22:09:24 <ed> http://www.w3.org/TR/SVGTiny12/struct.html#uiTitleDescBehavior
22:09:28 <nikos> ... maybe what we should do is not tie it to ARIA but tie it to a CSS property so you can use hover
22:09:49 <nikos> richardschwerdtfeger: by default, in HTML, the title attribute will give you a tooltip
22:09:53 <nikos> ... does that happen in SVG?
22:09:57 <nikos> krit: in some browsers it does
22:10:20 <nikos> richardschwerdtfeger: it's nice for people with cognitive impairments, but there's some situations where you don't want to do that
22:12:15 <nikos> ... we have aria-label property, which Google asked for, which is more specific
22:12:33 <nikos> shepazu: I think the best way to define the behaviour is through a CSS property
22:13:51 <nikos> shepazu: title in HTML pretty reliably gives you a tooltip. In SVG thats not the case, so there may be content out there that assumes title has different behaviour
22:14:43 <nikos> ... my proposed solution is that we say title should be displayed as a tooltip, but that you can control that in SVG using display:none
22:16:13 <nikos> ... right now authors can't rely on the behaviour, we need to specify the behaviour clearly
22:16:39 <nikos> richardschwerdtfeger: why would people use titles that aren't ever going to be visually rendered?
22:17:00 <nikos> ... the reason I'm asking is you could use aria-label which computes to a name
22:17:49 <nikos> shepazu: some people want to have metadata, particularly title
22:18:43 <nikos> ... I would say the title on the SVG root shouldn't not be displayed
22:18:52 <nikos> richardschwerdtfeger: I agree
22:19:34 <nikos> shepazu: the behaviour I favour is to make the title of the root element not appear as a tooltip, the title of anything else does. Unless you apply css display:none
22:19:58 <nikos> shepazu: I think that solves most cases
22:20:37 <nikos> richardschwerdtfeger: that makes sense to me
22:20:50 <krit> <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
22:20:50 <krit> <rect width="100" height="100">
22:20:50 <krit> 	<title>TEST</title>
22:20:50 <krit> </rect>
22:20:50 <krit> </svg>
22:20:54 <nikos> shepazu: I would go further and say, from an ARIA perspective, title is always a label.
22:21:19 <nikos> krit: with this example, FireFox and Opera show the tooltip
22:21:28 <nikos> ed: I don't think display:none would affect it in Opera
22:22:10 <nikos> heycam: I think we made title and desc styleable in SVG 2
22:22:19 <nikos> ... with the intention of it being used for something like this
22:23:24 <krit> krit: It seems to be styleable in SVG 1.1 also
22:23:33 <nikos> ... I think display:none or the other values affect what gets rendered inside the document, while the tooltip is outside the document so it's a little disconcerting using display:none
22:23:48 <nikos> richardschwerdtfeger: maybe we would need a different property?
22:24:00 <nikos> shepazu: I was trying not to add extra properties
22:24:37 <nikos> heycam: would this discussion affect whether aria attributes would go on title?
22:24:55 <nikos> shepazu: I think it doesn't, but has an inherent characteristic
22:24:57 <shepazu> http://dabblet.com/gist/4506341
22:34:23 <nikos> Tav: question, ARIA things are attributes, but title is an element. Is that ok?
22:34:25 <nikos> richardschwerdtfeger: yes
22:35:01 <nikos> Tav: FireFox will display a title attribute
22:35:06 <nikos> heycam: are you thinking of xlink:title?
22:35:13 <nikos> Tav: no, just title=
22:35:36 <nikos> shepazu: that's because in HTML, if you put the title attribute on an element it always displays as a tooltip
22:35:41 <heycam> data:image/svg+xml,<svg+xmlns="http://www.w3.org/2000/svg"><circle+r="100"+title="blah"/></svg>
22:35:43 <nikos> ... it's not SVG behaviour but it's inheriting from HTML
22:36:05 <nikos> Tav: there's a reason to use the element, at the last F2F we made it internationalisable
22:36:14 <nikos> shepazu: we should define what happens when there's a title attribute on an element
22:38:56 <nikos> richardschwerdtfeger: If you have an element that you want to expose to assisted technology you can use the name or the description. These properties are exposed to the API. For performance reasons, I wouldn't map that to an accessibility object unless you apply a role to it.
22:40:01 <nikos> shepazu: We have addressed the issue of performance for title
22:40:17 <nikos> ... if the first element of a shape is not its title it is not rendered as a tooltip and it should not map to the name of the thing
22:40:26 <nikos> ... title has to be the first child of an element for it to be the label
22:40:34 <nikos> ... and I would say that description has to be the second
22:40:44 <nikos> ... this helps resolve multiple titles, etc
22:40:51 <Zakim> -Tav
22:40:54 <nikos> richardschwerdtfeger: let me explain what I mean by performance
22:41:13 <nikos> ... the browser takes elements out of the DOM and creates accessibility objects, this is a lot of load on the browser
22:41:36 <nikos> ... so unless the object has semantic meaning to the AT then you probably don't want to map to an accessible object
22:41:52 <nikos> ... if you really want to support an AT, you want to apply a role to it
22:42:06 <nikos> shepazu: I think if we are worried about performance we should define the behaviour in terms of parsing processing
22:42:30 <nikos> ... in general I would say that SVG does not have semantics, but from the specification and the accompanying note is that there is a strong semantic with title
22:43:38 <nikos> shepazu: I'll make a proposal on the list for this
22:43:51 <Zakim> -krit
22:45:39 <Zakim> -cabanier
22:45:42 <Zakim> -Doug_Schepers
22:45:43 <Zakim> -ed
22:46:13 <nikos> RRSAgent, make minutes
22:46:13 <RRSAgent> I have made the request to generate http://www.w3.org/2013/01/10-svg-minutes.html nikos
22:46:22 <Zakim> -nikos
22:48:49 <richardschwerdtfeger> hg clone ssh://svgwg@svgwg.org/hg/svg2 local/path/svg2
22:50:09 <heycam> ssh -vvv svgwg@svgwg.org
22:51:05 <heycam> http://pastebin.mozilla.org/
22:51:48 <richardschwerdtfeger> OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
22:51:48 <richardschwerdtfeger> debug1: Reading configuration data /etc/ssh_config
22:51:50 <richardschwerdtfeger> debug1: Applying options for *
22:51:51 <richardschwerdtfeger> debug2: ssh_connect: needpriv 0
22:51:53 <richardschwerdtfeger> debug1: Connecting to svgwg.org [75.119.204.68] port 22.
22:51:54 <richardschwerdtfeger> debug1: Connection established.
22:51:56 <richardschwerdtfeger> debug3: Not a RSA1 key file /Users/richardschwerdtfeger/.ssh/id_rsa.
22:51:57 <richardschwerdtfeger> debug2: key_type_from_name: unknown key type '-----BEGIN'
22:51:59 <richardschwerdtfeger> debug3: key_read: missing keytype
22:52:00 <richardschwerdtfeger> debug2: key_type_from_name: unknown key type 'Proc-Type:'
22:52:02 <richardschwerdtfeger> debug3: key_read: missing keytype
22:52:03 <richardschwerdtfeger> debug2: key_type_from_name: unknown key type 'DEK-Info:'
22:52:05 <richardschwerdtfeger> debug3: key_read: missing keytype
22:52:06 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:08 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:09 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:11 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:12 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:14 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:15 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:17 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:18 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:20 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:21 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:23 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:24 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:26 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:27 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:29 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:30 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:32 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:33 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:35 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:36 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:38 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:39 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:41 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:42 <richardschwerdtfeger> debug3: key_read: missing whitespace
22:52:44 <richardschwerdtfeger> debug2: key_type_from_name: unknown key type '-----END'
22:52:45 <richardschwerdtfeger> debug3: key_read: missing keytype
22:52:47 <richardschwerdtfeger> debug1: identity file /Users/richardschwerdtfeger/.ssh/id_rsa type 1
22:52:48 <richardschwerdtfeger> debug1: identity file /Users/richardschwerdtfeger/.ssh/id_rsa-cert type -1
22:52:50 <richardschwerdtfeger> debug1: identity file /Users/richardschwerdtfeger/.ssh/id_dsa type -1
22:52:51 <richardschwerdtfeger> debug1: identity file /Users/richardschwerdtfeger/.ssh/id_dsa-cert type -1
22:52:53 <richardschwerdtfeger> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze2
22:52:54 <richardschwerdtfeger> debug1: match: OpenSSH_5.5p1 Debian-6+squeeze2 pat OpenSSH*
22:52:56 <richardschwerdtfeger> debug1: Enabling compatibility mode for protocol 2.0
22:52:57 <richardschwerdtfeger> debug1: Local version string SSH-2.0-OpenSSH_5.6
22:52:59 <richardschwerdtfeger> debug2: fd 3 setting O_NONBLOCK
22:53:00 <richardschwerdtfeger> debug1: SSH2_MSG_KEXINIT sent
22:53:02 <richardschwerdtfeger> debug1: SSH2_MSG_KEXINIT received
22:53:03 <richardschwerdtfeger> debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
22:53:05 <richardschwerdtfeger> debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
22:53:06 <richardschwerdtfeger> debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
22:53:08 <richardschwerdtfeger> debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
22:53:09 <richardschwerdtfeger> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
22:53:11 <richardschwerdtfeger> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
22:53:12 <richardschwerdtfeger> debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
22:53:14 <richardschwerdtfeger> debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
22:53:15 <richardschwerdtfeger> debug2: kex_parse_kexinit:
22:53:17 <richardschwerdtfeger> debug2: kex_parse_kexinit:
22:53:18 <richardschwerdtfeger> debug2: kex_parse_kexinit: first_kex_follows 0
22:53:20 <richardschwerdtfeger> debug2: kex_parse_kexinit: reserved 0
22:53:21 <richardschwerdtfeger> debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
22:53:23 <richardschwerdtfeger> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
22:53:24 <richardschwerdtfeger> debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
22:53:26 <richardschwerdtfeger> debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
22:53:27 <richardschwerdtfeger> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
22:53:29 <richardschwerdtfeger> debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
22:53:30 <richardschwerdtfeger> debug2: kex_parse_kexinit: none,zlib@openssh.com
22:53:32 <richardschwerdtfeger> debug2: kex_parse_kexinit: none,zlib@openssh.com
22:53:33 <richardschwerdtfeger> debug2: kex_parse_kexinit:
22:53:35 <richardschwerdtfeger> debug2: kex_parse_kexinit:
22:53:36 <richardschwerdtfeger> debug2: kex_parse_kexinit: first_kex_follows 0
22:53:38 <richardschwerdtfeger> debug2: kex_parse_kexinit: reserved 0
22:53:39 <richardschwerdtfeger> debug2: mac_setup: found hmac-md5
22:53:41 <richardschwerdtfeger> debug1: kex: server->client aes128-ctr hmac-md5 none
22:53:42 <richardschwerdtfeger> debug2: mac_setup: found hmac-md5
22:53:44 <richardschwerdtfeger> debug1: kex: client->server aes128-ctr hmac-md5 none
22:53:45 <richardschwerdtfeger> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
22:53:47 <richardschwerdtfeger> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
22:53:48 <richardschwerdtfeger> debug2: dh_gen_key: priv key bits set: 126/256
22:53:50 <richardschwerdtfeger> debug2: bits set: 531/1024
22:53:51 <richardschwerdtfeger> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
22:53:53 <richardschwerdtfeger> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
22:53:54 <richardschwerdtfeger> debug3: check_host_in_hostfile: host svgwg.org filename /Users/richardschwerdtfeger/.ssh/known_hosts
22:53:56 <richardschwerdtfeger> debug3: check_host_in_hostfile: host svgwg.org filename /Users/richardschwerdtfeger/.ssh/known_hosts
22:53:57 <richardschwerdtfeger> debug3: check_host_in_hostfile: match line 4
22:53:59 <richardschwerdtfeger> debug3: check_host_in_hostfile: host 75.119.204.68 filename /Users/richardschwerdtfeger/.ssh/known_hosts
22:54:00 <richardschwerdtfeger> debug3: check_host_in_hostfile: host 75.119.204.68 filename /Users/richardschwerdtfeger/.ssh/known_hosts
22:54:02 <richardschwerdtfeger> debug3: check_host_in_hostfile: match line 4
22:54:03 <richardschwerdtfeger> debug1: Host 'svgwg.org' is known and matches the RSA host key.
22:54:05 <richardschwerdtfeger> debug1: Found key in /Users/richardschwerdtfeger/.ssh/known_hosts:4
22:54:06 <richardschwerdtfeger> debug2: bits set: 504/1024
22:54:08 <richardschwerdtfeger> debug1: ssh_rsa_verify: signature correct
22:54:09 <richardschwerdtfeger> debug2: kex_derive_keys
22:54:11 <richardschwerdtfeger> debug2: set_newkeys: mode 1
22:54:12 <richardschwerdtfeger> debug1: SSH2_MSG_NEWKEYS sent
22:54:14 <richardschwerdtfeger> debug1: expecting SSH2_MSG_NEWKEYS
22:54:15 <richardschwerdtfeger> debug2: set_newkeys: mode 0
22:54:17 <richardschwerdtfeger> debug1: SSH2_MSG_NEWKEYS received
22:54:18 <richardschwerdtfeger> debug1: Roaming not allowed by server
22:54:20 <richardschwerdtfeger> debug1: SSH2_MSG_SERVICE_REQUEST sent
22:54:21 <richardschwerdtfeger> debug2: service_accept: ssh-userauth
22:54:23 <richardschwerdtfeger> debug1: SSH2_MSG_SERVICE_ACCEPT received
22:54:24 <richardschwerdtfeger> debug2: key: /Users/richardschwerdtfeger/.ssh/id_rsa (0x10e824210)
22:54:26 <richardschwerdtfeger> debug2: key: /Users/richardschwerdtfeger/.ssh/id_dsa (0x0)
22:54:27 <richardschwerdtfeger> debug1: Authentications that can continue: publickey,password
22:54:29 <richardschwerdtfeger> debug3: start over, passed a different list publickey,password
22:54:30 <richardschwerdtfeger> debug3: preferred publickey,keyboard-interactive,password
22:54:32 <richardschwerdtfeger> debug3: authmethod_lookup publickey
22:54:33 <richardschwerdtfeger> debug3: remaining preferred: keyboard-interactive,password
22:54:35 <richardschwerdtfeger> debug3: authmethod_is_enabled publickey
22:54:36 <richardschwerdtfeger> debug1: Next authentication method: publickey
22:54:38 <richardschwerdtfeger> debug1: Offering RSA public key: /Users/richardschwerdtfeger/.ssh/id_rsa
22:54:39 <richardschwerdtfeger> debug3: send_pubkey_test
22:54:41 <richardschwerdtfeger> debug2: we sent a publickey packet, wait for reply
22:54:42 <richardschwerdtfeger> debug1: Authentications that can continue: publickey,password
22:54:44 <richardschwerdtfeger> debug1: Trying private key: /Users/richardschwerdtfeger/.ssh/id_dsa
22:54:45 <richardschwerdtfeger> debug3: no such identity: /Users/richardschwerdtfeger/.ssh/id_dsa
22:54:47 <richardschwerdtfeger> debug2: we did not send a packet, disable method
22:54:48 <richardschwerdtfeger> debug3: authmethod_lookup password
22:54:50 <richardschwerdtfeger> debug3: remaining preferred: ,password
22:54:51 <richardschwerdtfeger> debug3: authmethod_is_enabled password
22:54:53 <richardschwerdtfeger> debug1: Next authentication method: password
22:54:54 <richardschwerdtfeger> svgwg@svgwg.org's password:
22:55:33 <cabanier> richardschwerdtfeger: how did you do this?
22:56:07 <heycam> cabanier, a paste that went on a bit :)
23:06:29 <heycam> hg clone ssh://svgwg@svgwg.org/hg/svg2-tools
23:10:03 <birtles> birtles has joined #svg
23:14:16 <Zakim> -heycam
23:14:20 <Zakim> -richardschwerdtfeger
23:14:22 <Zakim> GA_SVGWG(SVG1)4:00PM has ended
23:14:22 <Zakim> Attendees were krit, +61.2.980.5.aaaa, nikos, cabanier, ed, heycam, birtles, +33.9.53.77.aabb, Tav, Doug_Schepers, richardschwerdtfeger
23:26:44 <krit> heycam|away: ping
23:35:00 <Zakim> Zakim has left #svg
23:55:36 <heycam> krit, pong
23:57:09 <krit> heycam: A friend at google and I want to prototype the new IDL defintions into WebKit. Any suggestions at this point?
23:57:29 <krit> heycam: (no SVGDefintionElement, that is what I understood :P)
23:57:47 <heycam> yes no SVGDefinitionElement
23:57:53 <heycam> but SVGGraphicsElement is still there
23:58:03 <heycam> are you looking for a summary of the interface structure changes?