IRC log of svg on 2013-01-10

Timestamps are in UTC.

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?