00:17:23 <Zakim> ed, you asked to be reminded at this time to play some pool
00:19:55 <shepazu> Discussion on the topics of scripting interface design, Web IDL, and coordination between W3C Working Groups, ECMA TC-39, and other interested parties.
00:19:55 <shepazu> This list is not a forum for script authoring.
00:21:07 <ed> Zakim, again?
00:21:07 <Zakim> I don't understand your question, ed.
00:45:02 <ChrisL> ChrisL has joined #svg
00:45:13 <ChrisL> issue-2285?
00:45:13 <trackbot> ISSUE-2285 -- Resolving @primitiveUnits and z attribute discrepancies -- RAISED
00:45:13 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2285
02:09:08 <heycam> RRSAgent, make minutes
02:09:08 <RRSAgent> I have made the request to generate http://www.w3.org/2009/09/28-svg-minutes.html heycam
02:09:52 <heycam> Present: Anthony, Cameron, Chris, Doug, Erik, Jonathan
02:09:53 <heycam> RRSAgent, make minutes
02:09:53 <RRSAgent> I have made the request to generate http://www.w3.org/2009/09/28-svg-minutes.html heycam
02:10:03 <heycam> Chair: Erik
02:10:17 <heycam> RRSAgent, make minutes
02:10:17 <RRSAgent> I have made the request to generate http://www.w3.org/2009/09/28-svg-minutes.html heycam
02:26:57 <Zakim> Zakim has left #svg
03:45:13 <shepazu> shepazu has joined #svg
03:47:23 <heycam> heycam has joined #svg
03:47:41 <fat_tony> fat_tony has joined #svg
04:47:00 <ed> ed has joined #svg
04:47:03 <fat_tony> fat_tony has joined #svg
05:38:33 <ed> ed has joined #svg
07:19:46 <heycam> ok only five tests left to write, four of them filter ones
08:05:03 <heycam> nice one, shepazu 
08:05:05 <heycam> :)
08:10:30 <heycam> the footnote was a great touch too
08:22:09 <shepazu> heycam: thanks :)
16:34:30 <RRSAgent> RRSAgent has joined #svg
16:34:30 <RRSAgent> logging to http://www.w3.org/2009/09/28-svg-irc
16:34:32 <trackbot> RRSAgent, make logs public
16:34:32 <Zakim> Zakim has joined #svg
16:34:34 <trackbot> Zakim, this will be GA_SVGWG
16:34:34 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
16:34:35 <trackbot> Meeting: SVG Working Group Teleconference
16:34:35 <trackbot> Date: 28 September 2009
16:34:48 <heycam> Meeting: Mountain View 2009 SVG WG F2F Day 3
16:34:51 <heycam> Chair: Cameron
16:35:47 <ChrisL> ChrisL has joined #svg
16:36:09 <heycam> Scribe: Erik
16:36:19 <ed> scribeNick: ed
16:36:27 <heycam> Topic: SVG in HTML5
16:36:52 <ed> CM: looked at html5 wrt svg
16:37:01 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_HTML5_Notes
16:37:37 <ed> ...some notes from reading through the spec
16:37:49 <fat_tony> fat_tony has joined #svg
16:37:55 <ed> ...let's go through the list (link above)
16:38:01 <shepazu> shepazu has joined #svg
16:38:11 <ed> ...first point, requiring document to implement SVGDocument and HTMLDocument
16:38:35 <ed> ...required only if the UA supports svg
16:38:56 <ed> AG: what's the difference between HTMLDocument and SVGDocument
16:39:30 <ed> CM: they're similar, has title attribute and so on
16:39:54 <ed> ...SVGDocument also has rootElement which points to the root svg
16:40:33 <ed> ED: it's the same as documentElement, we added that to tiny12 IIRC
16:41:08 <ed> CM: the general approach of supporting all the document interfaces on document is the way to go
16:41:23 <ed> DS: i agree
16:41:41 <ed> ...it's a good way of testing if it supports a language
16:42:50 <ed> CL: so you can use document.createElement in an svgdocument to create non-svg elements?
16:43:01 <ed> DS: yes, I do that all the time
16:43:22 <ed> CM: yes, also works in HTML, it's in dom core
16:44:02 <ed> CM: one important thing to note is that html5 doesn't require svg to be implemented
16:44:51 <ed> DS: the argument from hixie has been that since certain formats are implemented anyway there's no point in actually requiring them
16:45:01 <ed> ...for png, jpeg etc
16:45:16 <ed> ...same thing with the video codec
16:46:39 <ed> ...so it's not inconsistent in the way that other formats aren't required either
16:46:48 <ed> CM: though canvas is required
16:47:14 <ed> DS: and png is required as an output format from canvas
16:47:25 <ed> ...we should push back on this issue
16:47:45 <ed> ...there needs to be a required video format
16:47:53 <ed> CM: though that's different from requiring svg
16:48:09 <ed> DS: it's similar though, not requiring common formats
16:48:42 <ed> ...hixie's stance that it's not required for interop I don't agree with
16:50:30 <ed> CM: when you say svg should be required there are many places where it could be supported, like img, object versus just supporting the dom (e.g the svg elements)
16:51:59 <ed> ...regardless of whether you support svg the elements should be put in the correct namespace
16:52:16 <ed> ...though the interfaces on those elements may not be supported
16:53:42 <ed> DS: would want the elements to render if they're parsed into the correct namespace
16:54:17 <ed> ED: would be nice to have a requirement, but i can understand why there might be resistance to that
16:55:36 <ed> DS: as an author i want to know what I can rely on, if you can require canvas you can require svg
16:56:22 <ed> CM: the requirement for rendering svg is in the svg spec
16:56:30 <ed> DS: what if i made an rss reader
16:56:45 <ed> ...should it also support svg?
16:56:58 <ed> ...or if i have a mobile UA
16:57:17 <ed> ...maybe it should be a should-level requirement
16:58:02 <ed> ED: there are different conformance-classes in HTML5 though, so may be that it is a must-level requirement for some conformance-class
16:58:51 <ed> DS: so a conformance class that requires support for svg, png, jpeg etc
16:58:59 <ed> ...that's what we should ask for
16:59:28 <ed> CM: (reads out current conformance classes in html5)
17:00:00 <ed> DS: maybe "web-application user agents"
17:00:29 <ed> ...distinction from "web browsers and other interactive user agents"
17:00:38 <ed> ...by requiring the image formats
17:05:59 <ed> CM: (reads thread on requirement for svg support)
17:06:10 <heycam> http://lists.w3.org/Archives/Public/public-html/2009Aug/1308.html
17:13:15 <ed> CM: added wording to say that interfaces must be implemented if you have e.g an SVGSVGElement
17:13:22 <ed> ED: still doesn't guarantee rendering
17:14:54 <ed> CM: ok, next point: html5 says that title from htmldocument wins over the svgdocument
17:15:07 <ed> ...depending on the root of the document
17:15:40 <ed> ED: though having an svg root in a text/html document wouldn't be conforming would it?
17:16:16 <ed> CM: yes, that's probably quite unlikely to occur
17:16:43 <ed> ...this is probably a minor detail, which won't cause many problems
17:18:55 <ed> CM: next point: html5 says "Elements that are from namespaces other than the HTML namespace and that convey content but not metadata, are embedded content for the purposes of the content models defined in this specification. (For example, MathML, or SVG.)"
17:19:15 <ed> ...only the 'svg' element can be embedded content
17:21:07 <ed> ED: only case I can think of is allowing non-rendering elements outside of <svg>, things like gradients
17:21:35 <ed> ...those don't depend on the coordinate system directly, so would be fine to have even outside of an svg fragment
17:21:47 <ed> ...but it's not that so important I think
17:22:21 <ed> CM: we can point out the inconsistency in the spec
17:24:06 <ed> CL: probably easier to always require an svg fragment, even though some elements don't depend on that
17:24:43 <ed> CM: we could define some specialcases for it though
17:25:19 <ed> ...next point: img element is forbidden to reference an svg document that has script inside
17:26:28 <ed> DS: the better requirement would be "the img element must not execute scripts in the referenced content"
17:26:51 <ed> CM: (reads out parts of the html5 img src definition)
17:28:26 <ed> ...so allowing the animation and not allowing scripting is what we wanted
17:29:14 <ed> ...not disagreeing with that, but referencing documents that have scripts inside should be allowed
17:29:50 <ed> AG: having to make new documents for the purpose of conforming would be silly
17:30:14 <ed> ...(regarding paged-media)
17:32:00 <ed> ...could show a particular page
17:32:52 <ed> CM: for the svg with script case I think it's conceivable that you don't expect scripts to run when you reference it from an img element
17:33:10 <ed> ...it's not clear what it means with non-interactive
17:33:38 <ed> ...what if you had a smil animation that had something depending on e.g click
17:33:46 <ed> ...that wouldn't conform
17:34:31 <ed> DS: i don't think html5 should say anything about what you can point to
17:34:37 <ed> ...from img
17:36:43 <ed> CM: i propose we ask for  saying that it's conforming to point to scripted and/or interactive svg content (just that those scripts shouldn't run, and any interaction would be disabled) 
17:37:53 <ed> ...next point: security and privacy considerations...
17:38:25 <ed> ...(reads out point from wikipage)
17:41:30 <ed> ...unlike the img element doesn't say anything about which documents video can reference
17:41:56 <ed> CL: not that strange to want to sandbox it for video
17:43:26 <ed> (discussion on animated gifs and whether that is video or image)
17:44:34 <ed> CM: it's a bit strange to reference svg from video, especially since you might have a foreignobject with html inside from there
17:45:03 <ed> ...next point; canvas getDataUri possible support for svg 
17:45:12 <ed> ...probably fine
17:47:07 <ed> ED: there's no one mapping, if we wanted the same output from ua:s then it'd need defining
17:47:25 <ed> CM: next point: exporting svg
17:47:57 <ed> ...requires that any HTML child elements of foreignObject must be flow content.
17:48:11 <ed> ...that is things that can be inside of body
17:50:06 <ed> ...think that's reasonable
17:50:40 <ed> ED: that would prohibit someone from putting a <head> element for example, right?
17:51:55 <ed> ...just thinking of e.g wanting to pull in external stylesheets for example
17:52:41 <ed> CM: and bgcolor maybe?
17:53:58 <ed> ... i think you should really be allowed to leave out the body element
17:54:08 <ed> ...inside foreignobject
17:59:32 <ed> (discussion on html elements outside of foreignobject in svg)
18:04:32 <ed> CL: we should have a specific element for embedding html in svg, with a different name and defined behaviour
18:04:41 <ed> ...in the integration spec maybe
18:06:50 <ed> CM: so having <html> or <body> in foreignObject in text/html would be causing problems for the html parser
18:07:05 <ed> ...so is it worth asking for these cases to be allowed
18:07:25 <ed> ED: it'd work fine in XHTML though
18:08:37 <ed> ...but I don't think it's any real problem to say it's non-conforming
18:08:58 <ed> CM: next one: Requires that <svg:title> inside HTML documents have only phrasing content.
18:10:40 <ed> AG: what is title used for mostly?
18:10:58 <ed> ...and what do we require in svg?
18:11:06 <ed> CL: we restricted it in svgt12
18:11:29 <ed> DS: it's just text in tiny12
18:13:02 <ed> CM: do we mind that html5 restricts what you can put inside of title?
18:13:15 <ed> CL: quite reasonable
18:13:20 <ed> DS: unless you have a switch
18:14:14 <ed> ...title inside of switch, or switch around title
18:14:36 <ed> ...using that with systemLanguage might be good
18:17:18 <ed> ...suggesting contentmodel of metadata or foreignobject
18:18:20 <ed> ...if tspan is child of title, ua should honor style but not positioning
18:18:30 <ed> CL: sounds like the tooltip element would be what you wnat
18:18:53 <ed> DS: still doesn't solve the contentmodel of title
18:20:04 <ed> CL: having markup there for i18n is common
18:20:18 <ed> ...but doesn't care much about what the elements are called (in xml anyway)
18:20:52 <ed> DS: maybe explaining why title is an element early in the svg spec would be good
18:22:46 <ed> DS: several usecases we are trying to address
18:23:13 <ed> ...allowing switch either inside or outside of title
18:23:21 <ed> ...styling for tooltips
18:23:39 <ed> ...structured content
18:24:45 <ed> ...must be internationalizable
18:25:00 <ed> ...structured and styled content are similar
18:25:08 <ed> ...we also want to have a clear content model
18:25:35 <aemmons> aemmons has joined #svg
18:27:23 <ed> CM: don't think we need to decide all this to resolve the html5 issue
18:30:32 <ed> DS: wrt to html i think it's reasoable to say that we don't want to restrict it to be phrasing content, it might be better to treat it the same way foreignobject
18:30:44 <ed> ...or text or metadata
18:31:09 <ed> CM: that's to allow e.g tspans inside title
18:33:16 <ed> ...the way the parser differentiates between elements with the same name depends on the context
18:34:40 <ed> DS: maybe we should restrict the elements that are allowed to be anything that can be inside of an <svg:text> element or any phrasing content
18:34:41 <Zakim> Zakim has left #svg
18:35:00 <Zakim> Zakim has joined #svg
18:35:09 <ed> Zakim, meeting spans midnight
18:35:09 <Zakim> I don't understand 'meeting spans midnight', ed
18:35:30 <ed> RRSAgent, meeting spans midnight
18:36:11 <ed> Zakim, remind me in 8 hours to finish the slides for svgopen :)
18:36:11 <Zakim> ok, ed
18:36:47 <ed> CM: for the tooltip case you might want to allow graphic elements, such as rects and other things
18:41:57 <ed> DS: don't think it's necessary to have a new element for tooltips, we already have title
18:45:27 <ed> CM: agree that title shouldn't have graphical content
18:46:02 <ed> DS: batik and opera shows the title as tooltip
18:47:49 <ed> DS: as long as phrasing content includes svg phrasing content (tspan, tref etc)
18:48:59 <ed> ...the UA may honor the styling (italics and bold perhaps, not colors)
18:49:24 <ed> CM: and switch?
18:49:30 <ed> DS: right
18:49:49 <ed> ...but restricted to the content model of its parent
18:53:36 <ed> ...so maybe say that we plan to allow switch, tspan, tref in title and calling that svg phrasing content
18:54:56 <jwatt> jwatt has joined #svg
18:55:32 <ed> CM: teh spec says that the semantics of svg elements are defined by the svg spec or by other relevant specs
18:56:16 <ed> CL: we should say that's good
18:56:59 <ed> CM: next one:
18:57:01 <ed> ..."The SVG specification states that elements that are not in the SVG namespace, that are in SVG fragments, and that are not included in a foreignObject element, are to be ignored. Similarly, this specification does not define any processing for elements in SVG fragments that are not in the HTML namespace; they are considered neither conforming nor non-conforming from the perspective of this specification."
18:57:28 <ed> ...doesn't affect the conformance of the html document, so you could have crazy invalid svg content inside, but the html could still be valid
18:57:32 <ed> CL: i think that's ok
18:58:04 <ed> CM: i asked for some explicit link for saying that svg fragments must be conforming svg document fragments
18:58:21 <ed> ...that would cause the html to become non-conforming in some cases
18:58:42 <ed> CL: but it's similar to how html is treated in svg
19:01:01 <ed> ED: it probably fine
19:05:18 <ChrisL> nvdl and relaxng - we define onl the validity of tyhe svg bits. its not 'ignoring', its 'splitting up and routing to the appropriate validator'.
19:07:04 <ed> CM: next one, Suggests that SVG could be used for tag clouds.
19:08:07 <ed> ... Allows <link rel="icon" sizes="any"> examples with svg
19:09:00 <ed> ... looking at the examples in 9.1.2
19:09:21 <ed> ...the example that has a prefixed element
19:10:58 <ed> JW: so prefixed elements would break the web?
19:11:21 <ed> CM: that's what I've heard from opera people anyway
19:13:21 <ed> ...also the argument that prefixes are hard
19:13:49 <ed> JW: prebound prefixes is easy, like for svg
19:14:48 <ed> ...seems like a bogus argument to avoid namespace prefixes
19:17:33 <ed> ...all comes down to extensibility
19:18:07 <ed> ...prebound prefixes would be good
19:29:52 <ed> DS: for svg and mathml that would be good
19:33:42 <ed> CM: maybe you should have a special namespace used for unrecognized prefixes
19:35:25 <ed> ...and maybe split the prefix and localname when creating the element
19:35:56 <ed> ...instead of doing something like localname=cdrU00003Alicense
19:43:52 <ed> CM: the table mapping svg element casing is stll missing textArea and solidColor from 1.2Tiny
19:47:57 <ed> ...we should push back on that
19:48:28 <ed> ...referencing SVGT12, because the scripting section is better there
19:48:46 <ed> ...asked why SVG 1.1 isn't there as a normative reference
19:48:58 <ed> DS: we should publish the svg integration spec
19:49:05 <ed> ...so that they could point to that spec
19:51:20 <ed> CM: would need to add the tables
19:53:21 <ed> DS: and links to the spec that defines the elements
19:53:42 <ed> CL: for elements defined in two versions?
19:53:52 <ed> DS: have one column for each
19:57:43 <shepazu> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
20:00:44 <ed> CM: that's the end of the html5 summary
20:02:10 <ed> ACTION: heycam to summarize the html5 conclusions from these minutes and send them to the HTML WG
20:02:10 <trackbot> Created ACTION-2675 - Summarize the html5 conclusions from these minutes and send them to the HTML WG [on Cameron McCormack - due 2009-10-05].
20:54:16 <eseidelDesk> eseidelDesk has joined #svg
21:52:07 <ed> ed has joined #svg
22:51:01 <ed> topic: canvas API
22:51:20 <ed> AG: do we need to define how it gets used in SVG?
22:51:22 <ed> DS: yes
22:51:58 <ed> ...the split out spec says which elements have the getContext method
22:52:42 <ed> s/split out spec says/split out spec says the host language defines/
22:53:12 <ed> CM: if it's a mixin interface then you wouldn't want it to inherit from element
22:54:49 <ed> ...would you expect that to be on the image element?
22:54:55 <ed> DS: and the video element
22:56:12 <ed> ED: not convinced about the video element having getContext
22:57:18 <shepazu> http://lists.w3.org/Archives/Public/public-canvas-api/2009JulSep/0021.html
22:59:50 <ed> CM: the rendering order would need to be defined
23:00:16 <ed> ...not sure about which usecases he expects to address
23:00:25 <ed> ...accessing pixel values, or something else
23:00:52 <ed> AG: in that last paragraph he says we can render to all these different elements
23:01:20 <ed> CM: assuming it's been implemented, what would it do when used in foreignObject?
23:01:36 <ed> ...ppl have wanted for ages to be able to read pixel values from svg
23:02:13 <ed> ...AG would you be able to find out the use-cases?
23:02:20 <ed> AG: sure
23:03:07 <ed> ...I think he wants to hear what the WG thinks too
23:03:25 <ed> ...I'll ask about the use-cases for each of these elements
23:04:34 <ed> DS: obviously it makes sense to allow getContext on the image element
23:05:10 <ed> ...if you have that image and you write upon that image, and you <use> that image, does it use the image that was drawn on by canvas?
23:08:23 <ed> CM: what happens when you resize, if the image element width/height are in user units?
23:09:39 <ed> ED: maybe it'd make more sense to introduce a new element in svg for canvas, stating that the width and height are in actual pixels
23:11:09 <ed> (discussion on user units vs pixels)
23:20:29 <ed> CM: in terms of pixel values, people want to know the value at some particular user units position
23:20:45 <ed> ...without having to get a context and draw a complex svg to it, then get the pixels
23:21:17 <ed> ED: for such cases it might be better to offer that functionatlity on the SVGSVGElement, since that holds the actual context for the entire svg
23:22:14 <ed> ED: also I wonder what to do about the case with image that has no xlink:href, which you mihgt wnat to use for a blank drawing area
23:24:52 <ed> CM: for the use-case of wanting to know color values somewhere
23:25:20 <ed> ...having some separate interface for getting color values at some certain position in user space
23:25:34 <ed> ....without having to explicitly render to some new buffer
23:26:56 <ed> ...so what about drawing trees of content to canvas
23:27:01 <ed> ...roc was working on that?
23:27:13 <ed> JW: no
23:27:33 <ed> ...basically the main thing is drawing svg documents as rasters
23:27:48 <ed> ...being able to reference svg images from img, css backgrounds etc
23:36:06 <ed> ED: opera supports rendering svg to canvas, but taints the canvas so that you can't get the pixels
23:37:35 <ed> ...we researched the various things that could make it crossdomain, and it'd need to be done on the document level (so that it includes stylesheets, things inside of foreignObject e.g iframe, and elements in svg referencing stuff
23:38:26 <ed> s/it'd/marking the canvas "safe" would/
23:40:06 <ed> DS: anything that can affect the rendering of the document including external resources (e.g css) should have dirty/clean flag
23:40:17 <ed> ...for the document
23:55:21 <ed> CM: what's the status of the split out canvas spec?
23:56:14 <ed> DS: one guy from microsoft will be added as editor
23:59:22 <ed> topic: random issues
23:59:31 <heycam> http://www.w3.org/mid/20090928065405.GC25086@wok.mcc.id.au
00:00:19 <ed> ED: agree
00:00:23 <heycam> http://www.w3.org/mid/20090928061536.GB25086@wok.mcc.id.au
00:03:40 <ed> ED: maybe we could say something like until the object is modified it's as if the element had not specified the attribute
00:12:53 <ed> http://www.w3.org/TR/SVG11/painting.html#StrokeProperties
00:53:25 <ed> CM: returning to http://www.w3.org/mid/20090928061536.GB25086@wok.mcc.id.au
00:53:33 <ChrisL> ChrisL has joined #svg
00:55:02 <ed> ED: would prefer the initial values to not be special computed values for things like textLength for example
00:55:48 <ed> ...IIRC what Opera is currently doing is to initialize to 0 but have the object be disconnected from the attribute until it's modified at which point it will become "live"
00:56:20 <ed> s/initial values/lacuna values/
00:59:43 <ChrisL> I suggest either having 'unknown' or calling the same dom method to compute the length
01:00:46 <heycam> http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview
01:00:51 <ed> CM: ok, but some may not have an unknown unit/type
01:08:29 <ChrisL> chrisl: (proposes a marvelous solution)
01:10:46 <ed> ACTION: fix the 1.1 second edition wording for values that are accessed where no attribute was provided, http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview and have it be NaN or 0 with unknown unit depending on the type of domobject
01:10:46 <trackbot> Sorry, couldn't find user - fix
01:11:00 <ed> ACTION: CL to fix the 1.1 second edition wording for values that are accessed where no attribute was provided, http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview and have it be NaN or 0 with unknown unit depending on the type of domobject
01:11:01 <trackbot> Created ACTION-2676 - Fix the 1.1 second edition wording for values that are accessed where no attribute was provided, http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview and have it be NaN or 0 with unknown unit depending on the type of domobject [on Chris Lilley - due 2009-10-06].
01:15:49 <ChrisL> getComputedTextLength()
01:19:05 <ChrisL> So, can I introduce lacuna values to make that write-up clearer
01:19:30 <heycam> ChrisL, yes but that is a large undertaking
01:25:27 <ChrisL> ok so its a zero value, not a lacuna value 
01:31:39 <heycam> action-2676?
01:31:39 <trackbot> ACTION-2676 -- Chris Lilley to fix the 1.1 second edition wording for values that are accessed where no attribute was provided, http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview and have it be NaN or 0 with unknown unit depending on the type of domobject -- due 2009-10-06 -- OPEN
01:31:39 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2676
02:22:42 <ed> rrs-agent, make minutes
02:22:49 <ed> RRSAgent, make minutes
02:22:49 <RRSAgent> I have made the request to generate http://www.w3.org/2009/09/28-svg-minutes.html ed
02:25:45 <heycam> heycam has joined #svg
02:36:12 <Zakim> ed, you asked to be reminded at this time to finish the slides for svgopen :)
03:02:53 <Zakim> Zakim has left #svg
05:25:56 <fat_tony> fat_tony has joined #svg
05:28:43 <shepazu> shepazu has joined #svg
05:37:12 <ed> ed has joined #svg
05:38:49 <heycam> heycam has joined #svg
08:10:45 <heycam> heycam has joined #svg
08:26:10 <shepazu> shepazu has joined #svg
08:43:04 <eseidel> eseidel has joined #svg
08:43:12 <eseidel_> eseidel_ has joined #svg
10:09:57 <karl> karl has joined #svg