20:29:59 <RRSAgent> RRSAgent has joined #svg
20:29:59 <RRSAgent> logging to http://www.w3.org/2013/09/05-svg-irc
20:30:01 <trackbot> RRSAgent, make logs public
20:30:01 <Zakim> Zakim has joined #svg
20:30:03 <trackbot> Zakim, this will be GA_SVGWG
20:30:03 <Zakim> ok, trackbot, I see GA_SVGWG(SVG1)4:30PM already started
20:30:04 <trackbot> Meeting: SVG Working Group Teleconference
20:30:04 <trackbot> Date: 05 September 2013
20:30:24 <birtles> Zakim, who is on the call?
20:30:24 <Zakim> On the phone I see +1.425.373.aaaa, luc, [IPcaller]
20:30:33 <birtles> Zakim, [ is me
20:30:33 <Zakim> +birtles; got it
20:30:40 <Zakim> +Doug_Schepers
20:30:43 <Zakim> +??P8
20:31:06 <Zakim> +[IPcaller]
20:31:27 <richardschwerdtfeger> zakim, IPcaller is Rich
20:31:27 <Zakim> +Rich; got it
20:31:44 <krit> Zakim, ??P8 is me
20:31:44 <Zakim> +krit; got it
20:31:46 <Zakim> +[IPcaller]
20:31:47 <heycam> Zakim, [ is me
20:31:47 <Zakim> +heycam; got it
20:32:59 <Zakim> +[IPcaller]
20:33:09 <Zakim> +??P13
20:33:33 <ed> Zakim, [IPcaller] is me
20:33:33 <Zakim> +ed; got it
20:33:54 <Tav> zakim, ??P13 is me
20:33:54 <Zakim> +Tav; got it
20:34:31 <heycam> Chair: Cameron
20:34:35 <heycam> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0080.html
20:38:01 <birtles> scribenick: birtles
20:38:17 <birtles> topic: Review comments on css-variables
20:38:32 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Review_comments_on_css-variables-1_2013-08-29
20:38:36 <birtles> heycam: I put together some comments ^
20:38:46 <birtles> ... technically comments were due yesterday but Tab said today is fine
20:38:55 <birtles> ... there wasn't anything we really needed to point out
20:38:56 <Zakim> +nikos
20:39:12 <shepazu> q+
20:39:13 <birtles> ... I wanted to bring attention to how variables in SVG-in-OpenType
20:39:22 <birtles> ... or at least what's currently in the document
20:39:38 <birtles> ... so that's just declaring a UA stylesheet with variable names to reflect color palette stuff
20:39:47 <birtles> ... I doubt it's a misuse of variables but I just wanted to bring it up
20:40:02 <birtles> ... secondly, I think it would be good to be able to animate the variables
20:40:15 <birtles> ... you can't do that yet but I think it's on track for a subsequent revision of the spec
20:40:20 <birtles> ... but that's all for now
20:41:01 <birtles> shepazu: I'll review it shortly but I'm particularly interested in being able to pass in parameters
20:41:14 <birtles> ... I'm not sure you can do that with css variables
20:41:21 <birtles> ... for example, css icon fonts
20:41:51 <TabAtkins> As shep and I discussed last year, I think it's completely reasonable to define a way for variables to be initialized from outside data.  That way we can completely eclipse the functionality of SVG Parameters.
20:42:09 <shepazu> http://css-tricks.com/examples/IconFont/
20:42:29 <birtles> shepazu: see the link above ^
20:42:41 <birtles> ... say I want to style a button with an icon next to it
20:43:04 <birtles> ... I want to be able to position it next to the text
20:43:10 <birtles> ... I want to be able to change the color
20:43:15 <birtles> ... I want to be able to scale it
20:43:23 <birtles> ... based on the font-size
20:43:35 <birtles> ... but I can't shadow it like they do on this page
20:43:43 <birtles> ... so it's like the problem we have with markers
20:44:00 <birtles> ... people want to be able to define a single arrow head and use it on any color line and have that color follow through
20:44:10 <birtles> ... so while I've been experimenting with SVG icons
20:44:26 <birtles> ... I could do a couple of things I wanted to do
20:44:41 <birtles> ... I couldn't change the color
20:44:48 <birtles> ... I couldn't reference an SVG fragment in the page
20:44:59 <birtles> ... I couldn't pass in the color I wanted the SVG to use
20:45:06 <birtles> ... which might be the fill or the stroke
20:45:22 <birtles> ... this seems like an obvious use case (esp. with retina displays)
20:45:35 <birtles> ... with CSS variables I would like to have some way of passing in a color value or something else
20:45:56 <birtles> ... to make a given instance of the SVG take on that style etc.
20:46:14 <birtles> ... does that make sense?
20:46:38 <birtles> ... can you do that with CSS variables today?
20:47:01 <birtles> heycam: I'm not sure what level of detail of comments you want to send about that
20:47:12 <birtles> ... we could just tack on another bullet point about that unless you want to add more detail?
20:47:37 <birtles> shepazu: how about "we'd like to be able to send color values into an SVG file so they can be used in a similar way to icon fonts" + a link to the icon fonts page
20:48:06 <birtles> birtles: does context-fill / context-stroke help?
20:48:17 <birtles> heycam: I don't think that works for completely separate documents
20:48:22 <birtles> ... unless we define some mechanism for that
20:48:52 <birtles> ... but I think the general case of being able to pass in arbitrary values is still worth saving
20:49:30 <birtles> shepazu: yes, sometimes you don't know if it's the fill or stroke you want to change
20:49:40 <richardschwerdtfeger> ok. dropping.
20:49:42 <richardschwerdtfeger> thanks
20:49:48 <Zakim> -Rich
20:49:50 <richardschwerdtfeger> richardschwerdtfeger has left #svg
20:50:21 <birtles> ... and you might have multiple objects with multiple colors with a simple replace fill / stroke doesn't work
20:50:38 <birtles> birtles: so color by number, do we have that for SVG-in-OpenType
20:50:55 <birtles> heycam: at TypeCon they were having a bit of a discussion about that
20:51:48 <birtles> ... microsoft brought up a proposal had a facility to have palettes within a font
20:52:21 <birtles> ... so we've taken that idea on board for SVG-in-opentype to have both predefined palettes and also to specify from the outside
20:52:31 <Tav> http://tavmjong.free.fr/SVG/BUTTON_TEST/button_test.xhtml
20:52:44 <birtles> Tav: there's probably more to it than just color: stroke width, dash-array
20:53:10 <birtles> heycam: I think this proposal would allow you to specify arbitary paints from the outside
20:53:19 <birtles> ... but we haven't really considered other properties
20:53:40 <birtles> Tav: the link above is my attempts to re-use a button
20:54:31 <birtles> heycam: whatever mechanism we come up with passing variables down into a document could be used for fonts as well
20:56:05 <Tavmjong> Tavmjong has joined #svg
20:56:42 <shepazu> TabAtkins, yes, agreed, just need to sort the details
20:56:45 <birtles> heycam: if people are happy with me adding a sentence to my review comments about that ability and pointing to the icon fonts and saying that's something we wanted to solve with reference to parameters then I can send that along today
20:57:12 <birtles> topic: Replacing feImage's xlink:href with href
20:57:18 <krit> http://dev.w3.org/fxtf/filters/#feImageElement
20:57:29 <glenn_> random input from IRC: blink folks propose removing tref functionality; https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/vnpLfBOsZf4
20:57:48 <glenn_> svgers might wish to comment on that thread
20:57:49 <birtles> krit: the question is: do we want to replace href with xlink:href? deprecate xlink:href?
20:58:05 <birtles> heycam: I think we want to do what we're doing elsewhere (although it's not in the spec yet)
20:58:23 <birtles> ... which is to allow both so that existing content work but when both are specified href (without namespace) wins
20:58:32 <birtles> krit: so do we deprecate xlink:href?
20:58:44 <birtles> shepazu: what is the proposal?
20:58:52 <birtles> krit: we keep both but deprecate the one with the prefix
20:59:16 <birtles> shepazu: we wrote up proposals in the past and went through the use cases... is this different?
20:59:20 <nikos> See http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSep/0211.html
20:59:26 <birtles> krit: no
20:59:42 <birtles> heycam: you should do what we resolved there
20:59:56 <birtles> nikos: I think we talked about it at rigi, see the link above
21:00:07 <birtles> krit: do we fully support xlink:href or do we want to deprecate it?
21:00:28 <birtles> shepazu: I think we should deprecate it but user agents still need to support it
21:00:45 <birtles> ... users shouldn't do it
21:00:50 <birtles> ... we have a resolution
21:01:15 <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Href
21:01:53 <birtles> shepazu: see the above ^
21:02:34 <birtles> ... we need to transition away from xlink:href
21:02:43 <birtles> ... I think you can already drop it in IE9
21:03:51 <birtles> ... so, from a deployment point of view, if it's already in IE the timeframe before it's possible to drop xlink:href is not so long
21:04:24 <birtles> heycam: I've checked and you don't need xlink in IE10 at least
21:05:52 <birtles> shepazu: if we can get the other browsers to do barename href soon then I'd be comfortable with making the authoring requirement for not using xlink:href a SHOULD
21:06:01 <birtles> ... my proposal is to deprecate xlink across the board
21:06:09 <birtles> ... say browsers MUST support it
21:06:15 <birtles> ... and authors SHOULD NOT use it
21:06:35 <birtles> ... and decide which takes precedent
21:07:20 <birtles> birtles: should barename href should win
21:07:37 <birtles> heycam: that seems to be what happens in IE
21:09:17 <birtles> ... in the previous attribute we decided to allow the src attribute for script etc.
21:09:44 <birtles> ... do we want that on feImage
21:09:51 <birtles> ... and as well as or instead of href?
21:10:23 <birtles> shepazu: in some browsers image is replaced with img and if you give it a src if follows that
21:10:36 <birtles> ... and then src wins over href
21:11:42 <birtles> heycam: someone came up with a way for doing fallback that browsers that don't do svg
21:11:58 <birtles> ... using the fact that an element that is named image is interpreted differently in html / svg
21:12:03 <heycam> http://lynn.ru/examples/svg/en.html
21:12:51 <birtles> shepazu: so does that mean we should or should not replace href with src?
21:13:14 <birtles> ... we should support src which takes precedence over href...
21:13:25 <birtles> heycam: it would have to be the opposite in order for this technique to work
21:13:36 <birtles> shepazu: yes, that's right
21:13:50 <birtles> ... then if someone wants to use this as a fallback they can
21:13:59 <birtles> ... since src will be overwritten in newer browsers
21:14:07 <birtles> ... so href would have to win over src
21:14:19 <birtles> heycam: but I don't know how many people are using this
21:14:42 <birtles> shepazu: but it would help people get over the pain of using SVG
21:14:46 <birtles> ... let people have their fallback
21:15:13 <birtles> heycam: anyone else have any views here?
21:15:42 <birtles> birtles: so href > xlink:href > src ?
21:17:27 <birtles> heycam: I think we want people to use href
21:17:50 <birtles> s/heycam: I think/shepazu: I think/
21:18:25 <birtles> shepazu: we are introducing href because it will be easier and it will be the default
21:18:33 <birtles> ... we are allowing xlink:href for legacy content
21:18:51 <birtles> ... and we are allowing src not as the preferred option but as a fallback for browsers that don't support SVG
21:18:58 <birtles> krit: what about feImage?
21:19:00 <Zakim> -Tav
21:19:03 <birtles> shepazu: it doesn't matter
21:19:46 <Zakim> +??P3
21:19:53 <birtles> heycam: prior to this article about fallback
21:20:06 <birtles> ... we were going to encourage authors to use src
21:20:15 <birtles> ... and make it the primary option
21:20:22 <birtles> shepazu: I agree with that rationale
21:20:34 <birtles> ... however I think this is new information
21:20:46 <birtles> ... that shows that we are suggesting a change in behavior which I think is a bad idea
21:20:57 <birtles> ... and it gets rid of a clever fallback hack
21:21:03 <birtles> ... that we get for free
21:21:30 <birtles> krit: I'm not sure this technique is actually useful
21:21:39 <birtles> ... who is actually putting an image in an inline SVG like this?
21:22:00 <birtles> shepazu: if you want to make a fallback image for browsers that don't support SVG
21:23:27 <birtles> krit: but this is only a fallback for really old versions of IE
21:23:54 <birtles> ... especially by the time we publish SVG2
21:25:32 <birtles> heycam: the whole point of this technique is to support either a PNG or an SVG image depending on whether the browser supports SVG or not
21:27:00 <birtles> (discussion about this fallback technique and how useful it is)
21:27:54 <birtles> shepazu: let's take this to email
21:28:04 <birtles> heycam: I just want to bring up the ordering of attributes
21:28:18 <birtles> ... I think we can still support this technique whilst still suggesting that src is the way forward
21:28:38 <birtles> ... there's nothing in this technique that requires that authors prefer one attribute or the other
21:28:54 <birtles> shepazu: as I recall, we liked the idea of using src
21:28:59 <birtles> ... but there were also problems with it?
21:29:28 <birtles> heycam: the resolution indicates src, but doesn't specify an ordering
21:30:22 <birtles> shepazu: we need to sort out the different use cases based on a matrix of different cases of browser support
21:31:01 <birtles> ... by the way, there's a lot of content made for ASV that doesn't work in current browsers since current browsers require the SVG namespace declaration
21:31:12 <birtles> ... if we dropped that requirement we would enable a bunch of existing content
21:32:17 <birtles> heycam: anyone want to take the action for looking at href etc. and emailing the list?
21:32:36 <Zakim> - +1.425.373.aaaa
21:32:42 <birtles> ... I'll do it
21:33:23 <birtles> ACTION: Cameron to investigate the xlink:href, href, and src ordering in terms of fallback behavior and mail the list
21:33:23 <trackbot> Created ACTION-3523 - Investigate the xlink:href, href, and src ordering in terms of fallback behavior and mail the list [on Cameron McCormack - due 2013-09-12].
21:34:05 <Zakim> -ed
21:34:07 <Zakim> -nikos
21:34:07 <Zakim> -heycam
21:34:08 <Zakim> -luc
21:34:08 <Zakim> -Doug_Schepers
21:34:09 <Zakim> -krit
21:34:12 <Zakim> -??P3
21:34:17 <Luc> Luc has left #svg
21:34:20 <birtles> anyone able to help send the minutes?
21:34:26 <Zakim> -birtles
21:34:28 <Zakim> GA_SVGWG(SVG1)4:30PM has ended
21:34:28 <Zakim> Attendees were +1.425.373.aaaa, luc, birtles, Doug_Schepers, Rich, krit, heycam, ed, Tav, nikos
21:34:31 <heycam> RRSAgent, make minutes
21:34:31 <RRSAgent> I have made the request to generate http://www.w3.org/2013/09/05-svg-minutes.html heycam
21:34:58 <heycam> then you know the drill? mail www-svg, bcc public-svg-wg, with a link and the contents of http://www.w3.org/2013/09/05-svg-minutes.html,text
21:35:41 <birtles> can I do it in a couple of hours?
21:40:22 <birtles> sent, I think
21:40:44 <birtles> if it doesn't come through, I'll send again in a couple of hours
21:44:21 <shepazu> heycam, Tavmjong, TabAtkins, http://www.schepers.cc/svg/icons/svg-sprites-simple.html
21:45:03 <heycam> sprites, cool :)
21:46:02 <pdr> shepzau, I tried to implement the google +1 button in SVG and failed :( We need subpixel hinting for paths to do really great svg-based iconography
21:46:29 <pdr> iconography is not the right words. "icons" is what I meant
21:46:47 <shepazu> pdr, what are you, russian orthodox?
21:46:53 <shepazu> :P
21:47:23 <shepazu> pdr, what about a media query for smaller sizes?
21:47:27 <glenn_> heycam: still around?
21:47:52 <pdr> shepazu, that could work but if that's the case, why use SVG at all? Bake all the sizes into png and be happy
21:47:59 <heycam> hi glenn_
21:48:07 <pdr> shepazu, the SVG advantage here is being able to make the icon once
21:48:17 <glenn_> heycam: did you see my comment above about blink folks removing tref support?
21:48:20 <shepazu> pdr, can you show me how it failed? maybe make a blog post?
21:48:26 <heycam> glenn_, oh no I missed it
21:48:43 <heycam> glenn_, thanks for that link
21:48:44 <glenn_> heycam: let me find the link again, you might wish to comment
21:48:48 <heycam> I've got it
21:49:12 <glenn_> heycam: good deal, ttyl
21:49:13 <pdr> shepazu, I can explain: if you try to make a pixel-perfect +1, it will either be blurry or the 1 and the vertial + will not be exactly the same width due to pixel snapping
21:49:19 <shepazu> glenn_, heycam, what's the link?
21:49:22 <heycam> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/vnpLfBOsZf4
21:49:45 <shepazu> pdr, what's your proposed solution?
21:50:37 <pdr> shepazu, path hints are an idea, like fonts
21:54:36 <shepazu> pdr, on the <tref> thread, why didn't you make the suggestion that came out of the www-svg thread, to make it a special case of <use>?
21:57:54 <pdr> shepazu, I think it's worse for the web to leave tref working at all since it's not supported by other vendors. By removing it completely, I think we'll make things easier on web devs. Duplicating <use> with a different node name is a hacky solution to not wanting to break existing content
22:01:28 <shepazu> pdr, then why didn't you say that on www-svg, instead of saying "we couldn't find a good reason to keep it"?
22:04:37 <pdr> I think those are the same thing, I just expanded on it a bit more
22:07:51 <krit> pdr: we have thought about hinting paths (to avoid aliasing) as well here
22:08:11 <krit> pdr: it is a very difficult topic and chances are high that implementations don't follow it
22:08:16 <pdr> yeah :/
22:08:30 <krit> pdr: I don't think that path hinting really solves the issues here
22:08:37 <krit> pdr: well it would kind of
22:08:50 <krit> pdr: but just don't use icon fonts on basis of SVG :)
22:08:54 <pdr> krit, I'm not sure how to handle the google +1 button use case. I had a team come to me and ask me to solve that problem, and I couldn't give them a solution :/
22:09:20 <krit> pdr: well, PDF does it
22:09:34 <pdr> media queries was my best answer, but to do that it was just easier to go the standard png + pngcrush route
22:09:40 <pdr> s/was/were
22:09:56 <krit> pdr: no, it needs direct support of the platform
22:10:05 <krit> pdr: users can not fake it
22:10:19 <krit> pdr: you need information about the pixel density and position
22:10:23 <pdr> yeah
22:10:28 <krit> pdr: just the UA has these information
22:10:42 <pdr> well, you can fake it a bit since images will be placed on integer boundaries
22:10:48 <krit> pdr: if we could agree on such a feature, it could be enabled by a CSS property
22:10:58 <pdr> (images don't have to be, but in this case they are)
22:11:09 <cabanier> cabanier has joined #svg
22:11:11 <krit> pdr: in HTML, yes
22:11:17 <shepazu> pdr, can you show me what you had for the g+ button? I'm curious if I can come up with a solution
22:12:03 <krit> pdr: problem is also that 1CSS pixel doesn't need to be a full factor of device pixels
22:12:31 <krit> pdr: and with some devices (nexus?) the resolution is different on width to height of a pixel
22:12:45 <pdr> shepazu, just try to make two vertical bars, like "1 1 1 1 1 1" or "L L L L L L", and have the widths of the 1's or L's stay the same under zoom. Under some zoom value, one of the L's will snap to 2 pixels and one will still be 1 pixel wide.
22:13:03 <pdr> some android devices do indeed use 1.2 :P
22:17:00 <cabanier> cabanier has joined #svg
22:17:09 <cabanier> cabanier has joined #svg
22:17:36 <cabanier> cabanier has joined #svg
22:18:30 <TabAtkins> Androids use a ton of numbers between 1 and 2, and there's even some that are <1 I heard.
22:19:31 <cabanier> cabanier has joined #svg
22:19:56 <pdr> TabAtkins, I think there's one coming out that uses imaginary numbers
22:20:09 <TabAtkins> The pixels show colors from beyond space.
22:20:14 <pdr> :D
22:32:59 <shepazu> pdr, it would be much easier to see the problem if you'd just make a simple test case
22:33:25 <shepazu> TabAtkins, elder colors?
22:33:49 <TabAtkins> non-euclidean colors
22:34:25 <shepazu> colors that sit at the center of the universe and gibber
22:36:25 <shepazu> colors like #tekelili
22:37:04 <shepazu> glenn_, thanks for letting us know about the tref thing
22:37:47 <glenn_> shepazu: sure thing, i'm not always completely worthless ;)
22:38:00 <shepazu> :P
22:40:05 <TabAtkins> I presume that basilisk colors fit in this category too.
22:40:26 <TabAtkins> Anyway, about variables/parameters.
22:41:04 <TabAtkins> All a given context needs to do is define, on its own, how to use some outside information to set the initial values for certain properties.  It can be done at the UA stylesheet level, effectively.
22:41:20 <shepazu> TabAtkins, colors that Pickman used in his paintings
22:41:37 <shepazu> ok, back to variables
22:42:01 <TabAtkins> For SVG, I think something in <desc> would work.  SVG doesn't seem to have a generic metadata element like HTML's <meta>, though.
22:42:23 <heycam> we should just have <meta>, if <meta> is the right answer
22:42:30 <heycam> merge all the elements :)
22:42:34 <TabAtkins> Something like that, sure.
22:43:01 <TabAtkins> <meta name=variable content="foo red" />
22:43:21 <pdr> shepazu, here's an example of the icon problem: pr.gg/pdricons.svg
22:43:45 <pdr> shepazu, the goal is to make this svg file zoomable while keeping all the widths equal, and crisp
22:46:16 <shepazu> pdr, I'd love to see a concrete proposal for sub-pixel rendering or hinting
22:47:48 <pdr> shepazu, Sadly, I don't have one outside of some crazy embedded language like fonts use :/
22:49:23 <shepazu> pdr, it's outside my area of expertise, so I don't have anything to offer here… Alex Danilo might
22:49:41 <shepazu> TabAtkins, that would be a misuse of <desc>, we should make a <meta> or something if that's what is needed
22:49:51 <pdr> It's possible that the font world has solved this problem. IIRC, most fonts don't fully flex the embedded hinting languages (if only because the authoring tools would be hard for artists)
22:49:54 <TabAtkins> Yeah, whatever is needed to send this stuff in.
22:50:50 <shepazu> TabAtkins, I'd like to have a conversation with you about this sometime, when I've loaded it in memory
22:50:53 <heycam> as display pixel density increases, hinting becomes less useful. and OS X doesn't hint at all (right?). is it worth having hinting ability in SVG?
22:51:23 <pdr> that's a fair point
22:51:47 <pdr> For practical reasons, in the near future, sites like google+ will have to keep using pngs for icons though
22:52:59 <TabAtkins> shepazu: Just ping me whenever.
22:53:07 <TabAtkins> absolutize is a correct word.  It's in the dictionary.
22:54:24 <krit> shepazu: yes! We have enough examples where you see antialiasing on Mac retina
22:54:44 <krit> heycam: --^
22:55:01 <heycam> I like OS X's text rendering, so maybe I'm biased
22:55:07 <krit> heycam: And I am not sure when retina will replace all other displays anyway
22:55:09 <shepazu> krit, you're a smart guy, make a proposal
22:55:25 <shepazu> it's not like you're busy or anything
22:55:42 <heycam> krit, sure. just pointing out that for me, at least, hinting is not required for text. even on my pre-Retina Mac. :)
22:55:44 <krit> shepazu: no, it is 1AM here … have enough time :)
22:56:17 <krit> heycam: for text I agree, but I also need some new glasses :P
22:56:25 <pdr> heycam, don't they greyscale anti alias though?
22:56:30 <heycam> pdr, sure
22:56:55 <heycam> you could make that argument too -- that high enough dpi displays obviate the need for antialiasing
22:57:00 <heycam> but that's even further out than getting rid of hinting
22:57:10 <pdr> they do, but it's a very long term thing. 10+ years
22:57:29 <heycam> so just in time for SVG 2 then  </dirk-joke>
22:57:32 <pdr> lol
23:06:25 <Zakim> Zakim has left #svg
23:13:02 <thorton> thorton has joined #svg
23:33:46 <nikos> heycam|away: Are there any minutes available from the Typecon meeting?
23:34:08 <heycam> do I appear as "heycam|away"?
23:34:11 <heycam> my client says "heycam"
23:34:21 <heycam> but I wouldn't be surprised if it's lying to me
23:34:39 <heycam> nikos, there aren't minutes that I've seen, but there are a couple of summaries which I'll give you links to
23:35:05 <heycam> Adam Twardoch's summary here: http://typophile.com/node/105612#comment-563733
23:35:39 <heycam> and a writeup in LWN: http://lwn.net/SubscriberLink/564944/12df516e13c2bf9b/
23:50:43 <nikos> heycam, the Thunderbird irc client doesn't like to update it's list of names very often
23:50:47 <nikos> and thanks for the links =)
23:50:52 <heycam> ah ok :)
23:50:53 <heycam> np