20:26:58 <RRSAgent> RRSAgent has joined #svg
20:26:58 <RRSAgent> logging to http://www.w3.org/2015/05/07-svg-irc
20:27:00 <trackbot> RRSAgent, make logs public
20:27:00 <Zakim> Zakim has joined #svg
20:27:02 <trackbot> Zakim, this will be GA_SVGWG
20:27:02 <Zakim> ok, trackbot, I see GA_SVGWG()4:30PM already started
20:27:03 <trackbot> Meeting: SVG Working Group Teleconference
20:27:03 <trackbot> Date: 07 May 2015
20:27:22 <heycam> Zakim, who is on the call?
20:27:22 <Zakim> On the phone I see Thomas_Smailus
20:27:35 <Zakim> +[IPcaller]
20:27:37 <heycam> Zakim, [ is me
20:27:38 <Zakim> +heycam; got it
20:27:59 <Zakim> +??P2
20:28:01 <heycam> Regrets: Brian, Doug
20:28:03 <heycam> Chair: Cameron
20:28:17 <Zakim> +[IPcaller]
20:28:25 <ed_work> Zakim, [IP is me
20:28:25 <Zakim> +ed_work; got it
20:28:34 <AmeliaBR> zakim, ??P2 is me
20:28:34 <Zakim> +AmeliaBR; got it
20:28:51 <AmeliaBR> zakim, mute me
20:28:51 <Zakim> AmeliaBR should now be muted
20:29:19 <heycam> Agenda: https://lists.w3.org/Archives/Public/www-svg/2015May/0003.html
20:31:14 <shepazu> heycam, can't make the telcon today, but +1 on making SVG case-insensitive https://lists.w3.org/Archives/Public/www-svg/2015May/0010.html
20:31:39 <shepazu> maybe we could even define a lightweight syntax/parser for it
20:32:20 <heycam> shepazu, thanks. can you respond on https://www.w3.org/2002/09/wbs/19480/Linkoping2015 when you get a chance.
20:32:33 <shepazu> heycam, will do
20:32:33 <Zakim> +??P3
20:32:36 <heycam> Zakim, who is on the call?
20:32:36 <Zakim> On the phone I see Thomas_Smailus, heycam, AmeliaBR (muted), ed_work, ??P3
20:32:41 <shepazu> heycam, probably can't make it :(
20:33:01 <Tav> zakim, ??P3 is me
20:33:01 <Zakim> +Tav; got it
20:33:55 <TabAtkins> I can call in. One sec.
20:33:56 <Zakim> +??P5
20:33:56 <stakagi> stakagi has joined #svg
20:34:38 <jdaggett> jdaggett has joined #svg
20:34:38 <fantasai> fantasai has joined #svg
20:34:55 <Zakim> +[Microsoft]
20:34:57 <Zakim> +??P6
20:35:06 <heycam> Zakim, pick a scribe
20:35:06 <Zakim> Not knowing who is chairing or who scribed recently, I propose Thomas_Smailus
20:35:14 <stakagi> zakim, ??P6 is me
20:35:14 <Zakim> +stakagi; got it
20:35:16 <BogdanBrinza> BogdanBrinza has joined #svg
20:35:50 <nikos_> scribe: nikos_
20:36:01 <nikos_> scribe: Nikos
20:36:01 <Zakim> +TabAtkins
20:36:04 <nikos_> scribenick: nikos_
20:36:39 <nikos_> Topic: HTML parser lowercasing SVG names
20:37:30 <nikos_> TabAtkins: dealing with matching SVG elements and attributes case sensitively in selectors
20:37:38 <nikos_> ... is annoying in our code and we do it wrong in blink
20:37:44 <nikos_> ... we currently always lowercsae it
20:37:56 <nikos_> ... which makes it impossible to select an svg element that uses camel case
20:38:06 <nikos_> ... had someone try to plumb the code - works but it's nasty
20:38:21 <nikos_> ... instead we committed a patch that always matches case insensitively
20:38:37 <nikos_> ...not sure of the exact details how that works
20:38:43 <nikos_> ... so can we make that official in the spec?
20:39:04 <nikos_> ... Doug added that we just always lowercase
20:39:13 <nikos_> ... at least when included in HTML
20:39:22 <nikos_> heycam: what does the spec say about query selector?
20:39:41 <Zakim> +Doug
20:39:43 <nikos_> TabAtkins: selectors by default will be case sensitive but individual host languages can specify that matching should be done case insensitively
20:39:46 <nikos_> ... HTML does this
20:39:53 <nikos_> ... SVG does not currently
20:40:11 <nikos_> heycam: what is it that makes general style sheets work to match mixed case names?
20:40:30 <nikos_> TabAtkins: most aren't camel case so they work - the few that are don't have many properties that can be played with
20:40:42 <nikos_> ... it's only that it can't select by tag name or attribute name - class works fine
20:40:52 <nikos_> heycam: so in Blink yo ucouldn't select clipPath element by name?
20:40:55 <nikos_> TabAtkins: yes
20:41:11 <nikos_> heycam: so the patch that landed implements what you're suggesting?
20:41:20 <nikos_> TabAtkins: I think so - everything matches case insensitively in SVG
20:41:27 <nikos_> heycam: any idea what other implementations do?
20:41:42 <nikos_> TabAtkins: I believe FF matches correctly
20:42:01 <nikos_> ... not sure how they handle if you do a selector with an upercase D, how it matches a HTML element with a lower case d
20:42:17 <nikos_> Tav: so this only affects HTML and not xHTML?
20:42:25 <nikos_> TabAtkins: Either way is possible
20:42:30 <nikos_> ... we could do it just for SVG in HTML
20:42:39 <nikos_> ... or for SVG ENTIRELY
20:42:59 <nikos_> heycam: I would like there to be a way to select these elements in HTML
20:43:09 <nikos_> s/elements in HTML/elements in XML
20:43:35 <nikos_> shepazu: we talked in the past about making a lightweight serialisation/parsing thing for svg
20:43:38 <TabAtkins> XML5
20:43:39 <nikos_> ... dom based rather than syntax based
20:43:48 <TabAtkins> annevk has worked on that for a while
20:44:04 <AmeliaBR> q+
20:44:04 <nikos_> ... HTML has all these rules for backwards compat - we wouldn't need to do all that sort of stuff because SVG has always been well formed
20:44:15 <nikos_> ... is there any political will towards doing that as a general solution?
20:44:24 <nikos_> TabAtkins: We could make that opt in
20:44:40 <nikos_> ... stand alone SVGs need a doctype for example - and opt in to the HTML like parsing
20:44:52 <nikos_> ... but a standard XML declaration would use a standard XML parser
20:44:54 <TabAtkins> Like <!doctype svg>
20:44:58 <nikos_> shepazu: I'm allergic to doctype
20:45:04 <nikos_> ... recognise they're neccessary in HTML
20:45:05 <ed_work> in theory a specialized svg parser mode could filter out/throw away all textnodes that don't apply, they seldom make sense for svg
20:45:10 <nikos_> ... but would prefer to avoid them for SVG
20:45:32 <AmeliaBR> zakim, unmute me
20:45:32 <Zakim> AmeliaBR should no longer be muted
20:46:24 <nikos_> AmeliaBR: I don't see anything wrong with doing the same thing for SVG - to say this can be parsed as an XML document or it can be parsed using an HTML or HTML like parser that is case insensitive
20:46:49 <nikos_> ... but don't forget that it's not just HTML vs stand alone - there's other situations for SVG
20:46:55 <nikos_> ... as long as we say which parser can be used
20:47:17 <nikos_> ... and how it would filter down to other DOM methods - and whether it would create headaches with createElementNS, etc
20:47:23 <nikos_> ... would we need two versions of that element?
20:47:35 <TabAtkins> zakim, mute AmeliaBR
20:47:35 <Zakim> AmeliaBR should now be muted
20:47:36 <AmeliaBR> zakim, mute me
20:47:37 <Zakim> AmeliaBR was already muted, AmeliaBR
20:47:38 <nikos_> shepazu: we don't control a lot of xml pipeline stuff
20:47:42 <nikos_> ... tools are often quite old
20:47:48 <AmeliaBR> s/of that element/of that function/
20:48:09 <nikos_> ... think people will be resistant to changing parsing of these tools
20:48:25 <nikos_> ... I'm not so interested in solving that use case - for them it will always be case sensitive
20:48:32 <nikos_> ... I am interested in the DOM methods - which we control
20:48:36 <nikos_> ... assuming browsers are on board
20:48:45 <nikos_> ... we can say 'from now on, DOM methods are case insensitive'
20:49:03 <nikos_> heycam: earlier you asked if the group is amenable to a HTML like parser for SVG
20:49:16 <nikos_> ... I think we are - think we're at the point where someone needs to write down a proposal for how it would work
20:49:30 <nikos_> ... would be happy to start small - selectors in general, etc
20:49:36 <AmeliaBR> s/AmeliaBR: I don't/AmeliaBR: HTML has two syntaxes, parsed as HTML or parsed as XML. I don't/
20:49:40 <nikos_> ... think the general parsing issue will be a larger think to solve
20:50:02 <nikos_> shepazu: I also want to make sure that authoring tools have a clear path forward with this
20:50:10 <nikos_> ... specifically ones that are updated such as InkScape and Illustrator
20:50:32 <nikos_> ... I propose that we accept this notion pending some sort of actionable spec and definition that we can agree on
20:50:36 <nikos_> ... and find someone to take the action
20:50:53 <nikos_> TabAtkins: yes, and I can take the action
20:51:41 <nikos_> Tav: I want to make sure the XML part is maintained to some extent
20:51:45 <nikos_> ... in InkScape we use a lot of namespaces
20:52:04 <nikos_> TabAtkins: I expect it will be like HTML where we have the current syntax and the more permssive syntax
20:52:42 <nikos_> heycam: I would like to resolve today how querySelector works in current documents
20:53:14 <nikos_> TabAtkins: I propose: selectors in general are case insensitive for SVG elements, just like they are for HTML elements
20:53:17 <nikos_> shepazu: agree
20:53:20 <ed_work> +1
20:53:25 <nikos_> ... not just querySelector, but anything that uses selectors
20:53:31 <nikos_> TabAtkins: I'll drive it forward
20:53:58 <nikos_> RESOLUTION: selectors in general will match SVG attributes and elements case insensitively
20:54:42 <nikos_> RESOLUTION: We will work on a method for parsing SVG documents using case insensitive syntax like HTML - with all this would entail
20:55:06 <Zakim> -TabAtkins
20:55:08 <Zakim> -Doug
20:55:24 <nikos_> Topic: Continued SVG 2 open issue discussion
20:55:33 <nikos_> heycam: last time we finished embedded content chapter discussions
20:55:56 <nikos_> ... not sure which others needed discussion?
20:56:10 <nikos_> https://svgwg.org/svg2-draft/render.html#PaintingRasterImages
20:57:09 <nikos_> nikos: Not sure who added this issue - do people think there is something we should say with respect to animated bitmap images? Or can we drop the issue?
20:57:40 <nikos_> heycam: does the HTML spec say what happens with animated raster images?
20:57:57 <nikos_> ... if it mentions it at all that might give some ideas - otherwise could perhaps drop it
20:58:09 <nikos_> ... maybe a requirement that we don't need to render the animation
20:58:26 <nikos_> ed_work: I'm not sure we require running the animation
20:58:26 <AmeliaBR> HTML text on the subject: http://www.w3.org/TR/html5/rendering.html#images
20:58:38 <nikos_> heycam: I don't remember seeing it
20:58:41 <AmeliaBR> "All animated images with the same absolute URL and the same image data are expected to be rendered synchronized to the same timeline as a group, with the timeline starting at the time of the most recent addition to the group."
20:59:31 <AmeliaBR> zakim, unmute me
20:59:31 <Zakim> AmeliaBR should no longer be muted
20:59:34 <ed_work> s/running the animation/running the animation (or if we require support for any image formats that are animated)/
20:59:52 <nikos_> AmeliaBR: there's one sentence in HTML that says that if you have multiple copies of the same animated issue then they should be synchronised
21:00:11 <nikos_> ... I think anytime you add a copy you reset the synchronisation
21:00:20 <nikos_> ... we could reference that and encourage the same behaviour
21:00:21 <BogdanBrinza_> BogdanBrinza_ has joined #svg
21:00:40 <nikos_> but probably don't want to add additional rules regarding controlling timelines
21:00:47 <nikos_> ... but we probably don't want that to be SVG specific
21:00:54 <nikos_> heycam: agree we shouldn't have specific requirements
21:01:00 <nikos_> ... so do we need to say anything in our spec?
21:01:06 <nikos_> ... or is referencing HTML enough?
21:01:15 <nikos_> AmeliaBR: we could just reference the HTML spec
21:01:25 <nikos_> heycam: I'm assuming the sentence in the HTML spec is about html image elements
21:01:48 <nikos_> zakim, mute AmeliaBR
21:01:48 <Zakim> AmeliaBR should now be muted
21:02:19 <nikos_> heycam: there's a big section about how to handle image elments in html
21:02:26 <Smailus> q+
21:02:30 <nikos_> .. e.g. what happens to sizing, and if it has an alt attribute
21:02:47 <nikos_> ... not sure how many requirements are applicable to svg
21:03:00 <AmeliaBR> zakim, ack me
21:03:00 <Zakim> unmuting AmeliaBR
21:03:01 <Zakim> I see Smailus on the speaker queue
21:03:04 <nikos_> Smailus: only concern I have is to clarify that raster content in SVG is treated the same as raster content in HTML
21:03:06 <AmeliaBR> zakim, mute me
21:03:06 <Zakim> AmeliaBR should now be muted
21:03:09 <nikos_> ... it's different in current browsers
21:03:15 <AmeliaBR> q?
21:03:18 <nikos_> ... we're having an issue with down sampling
21:03:22 <nikos_> ... it's being done cheaply in SVG
21:03:35 <nikos_> ... whereas in HTML we are getting a much higher quality result
21:03:58 <nikos_> ... lines dissapear out of two colour TIFFs, etc
21:04:12 <nikos_> heycam: I suspect the definition of image-rendering
21:04:19 <nikos_> ... which should apply to HTML and SVG images
21:04:20 <AmeliaBR> s/same animated issue/same animated image/
21:04:26 <nikos_> ... should mean that the same things happen
21:04:51 <nikos_> ... I would be fine saying here or in image-rendering, to say the intention is for the sampling should be the same between HTML and SVG
21:04:59 <Smailus> q-
21:05:06 <ed_work> require the same image formats to be supported too?
21:05:12 <ed_work> (as in html)
21:06:02 <nikos_> ACTION: Nikos to look at definitions for image in HTML and see what applies to SVG as well - reference HTML spec from SVG where appropriate
21:06:02 <trackbot> Created ACTION-3788 - Look at definitions for image in html and see what applies to svg as well - reference html spec from svg where appropriate [on Nikos Andronikos - due 2015-05-14].
21:06:26 <AmeliaBR> zakim, unmute me
21:06:26 <Zakim> AmeliaBR should no longer be muted
21:06:29 <nikos_> Topic: Linking chapter issues
21:06:38 <nikos_> AmeliaBR: these have been lingering on the agenda for a while
21:07:26 <nikos_> ... issue 2 isn't one of mine - we have informal definitions that should be moved to formal definitions - not sure who could talk about that one
21:07:48 <AmeliaBR> https://svgwg.org/svg2-draft/linking.html#issue2
21:08:08 <stakagi_> stakagi_ has joined #svg
21:08:45 <AmeliaBR> zakim, mute me
21:08:45 <Zakim> AmeliaBR should now be muted
21:08:59 <nikos_> ed_work: I don't mind taking the action - but would be happy if someone else could
21:09:03 <Zakim> +??P8
21:09:12 <nikos_> ... I think it's probably pretty clear what the terms mean
21:09:16 <nikos_> botie:
21:09:16 <botie> nikos_: sorry...
21:09:24 <nikos_> BogdanBrinza_: would probably make sense for me to take hte action
21:09:25 <stakagi_> zakim, ??P8 is me
21:09:25 <Zakim> +stakagi_; got it
21:09:42 <nikos_> ACTION: Bogdan to resolve ISSUE 2 in linking chapter
21:09:42 <trackbot> Created ACTION-3789 - Resolve issue 2 in linking chapter [on Bogdan Brinza - due 2015-05-14].
21:10:06 <nikos_> BogdanBrinza_: I'm not sure these chapters were reviewed - so we may have more to do
21:10:21 <AmeliaBR> zakim, unmute me
21:10:21 <Zakim> AmeliaBR should no longer be muted
21:10:29 <nikos_> Topic: Linking chapter - issue 5
21:10:30 <AmeliaBR> https://svgwg.org/svg2-draft/linking.html#issue5
21:10:58 <nikos_> AmeliaBR: target media fragments have a way of saying whether units are pixels or percentages
21:11:05 <nikos_> ... assume they map to viewbox units and viewbox w/h
21:11:09 <nikos_> ... anyone have other ideas?
21:11:20 <nikos_> heycam: I don't have any opinion
21:11:22 <AmeliaBR> zakim, mute me
21:11:22 <Zakim> AmeliaBR should now be muted
21:11:43 <nikos_> ... but as part of last weeks action to look at how implemented media fragments are, maybe I should think about this at the same time
21:12:04 <nikos_> ... I'll do testing as part of that
21:12:31 <nikos_> Action: Cameron to resolve issue 5 in linking chapter as part of work on other media fragment actions
21:12:31 <trackbot> Created ACTION-3790 - Resolve issue 5 in linking chapter as part of work on other media fragment actions [on Cameron McCormack - due 2015-05-14].
21:12:46 <heycam> https://svgwg.org/svg2-draft/linking.html#issue7
21:12:48 <AmeliaBR> zakim, unmute me
21:12:48 <Zakim> AmeliaBR should no longer be muted
21:12:50 <nikos_> Topic: Linking chapter - issue 7
21:13:23 <nikos_> AmeliaBR: we've got an option of setting a transform on an SVG view target fragment
21:13:24 <AmeliaBR> https://svgwg.org/svg2-draft/linking.html#issue7
21:13:31 <nikos_> ... and it's a bit complicated how this maps to CSS transforms
21:13:35 <nikos_> ... currently browsers differ
21:13:40 <nikos_> ... wrt transform origin on the svg
21:13:44 <nikos_> ... no way to specify a different origin
21:14:03 <nikos_> ... my question is: should we expand it to any possible css transform property?
21:14:08 <nikos_> ... or should we keep it simple"?
21:14:23 <nikos_> ... I lean to keeping it simple
21:14:40 <nikos_> heycam: I feel like this syntax is a bit of a niche feature - and not too keen on expanding with transform origin or that sort of thing
21:14:57 <nikos_> AmeliaBR: so should we deprecate the idea of using transformations on an svg view?
21:15:12 <nikos_> ... think your plan of what to do with parameters is a good way of solving generally, how to control the rendering from outside
21:15:17 <nikos_> ... but we don't quite have that yet
21:15:22 <nikos_> ... so not sure we should deprecate it yet
21:15:25 <nikos_> AmeliaBR: I like that idea
21:15:35 <nikos_> ... with a better syntax in future we might be able to get rid of this - but don't break it yet
21:15:53 <nikos_> heycam: part of the issue is that different implementations use a different transform origin
21:15:58 <nikos_> ... so that behaviour should be nailed down
21:16:21 <nikos_> AmeliaBR: it's whether you treat the root svg as an element with a css layout box
21:16:33 <nikos_> ... may have been fixed, but last I tested browsers had that behaviour
21:16:43 <nikos_> heycam: have you written text? or can you?
21:17:22 <nikos_> s/writtten text/written tests
21:18:16 <nikos_> AmeliaBR: we'd be asking the CSS transform spec for a clarification - or we could add clarifications that 'the root element of an svg document is an element with a layout box for purposes of the css spec'
21:18:52 <nikos_> heycam: transforms spec has something that says the value of transform origin is (0,0) for something that doesn't have a layout box
21:19:04 <nikos_> AmeliaBR: that wording is so inline svg in html tranfsorms like any other css layout box
21:19:11 <nikos_> ... but child content transforms like svg transforms
21:19:29 <nikos_> heycam: then idea of clarifying sentence in our spec is good
21:20:18 <nikos_> AmeliaBR: do we want resolution on transforms on root svg element?
21:20:31 <nikos_> ... because that would change the behaviour of SVG on the canvas
21:20:43 <nikos_> heycam: I want it to be what implementations do currently
21:21:04 <nikos_> AmeliaBR: I'll come up with some text options and summary of behaviour
21:22:18 <nikos_> ... for other issues I think we agree that view in a target fragment should behave the same as on the svg root element - we debated previously whether the transform should accumulate or replace the transform
21:22:25 <nikos_> ... we tentatively resolved that it should accumulate
21:22:32 <nikos_> ... and I started looking to see how much of a mess that would be
21:22:51 <nikos_> heycam: is that captured by one of the issues here?
21:23:03 <nikos_> AmeliaBR: issue 6
21:23:22 <nikos_> ... not specifically, but it's related
21:23:28 <nikos_> heycam: what's the next step there?
21:24:10 <AmeliaBR> https://lists.w3.org/Archives/Public/www-svg/2015Mar/0017.html
21:24:20 <nikos_> AmeliaBR: that's my list of test cases and current behaviour
21:24:40 <nikos_> heycam: I'll need to read the email
21:24:47 <nikos_> AmeliaBR: we can talk about this next week maybe
21:25:07 <nikos_> ... my preference is 'whats the transform origin of the canvas'? Treat the root element as the layout box
21:25:16 <nikos_> ... everyone except FF implements that
21:25:20 <nikos_> ... maybe IE doesn't implement at all
21:25:31 <nikos_> ... I would recommend any svg view transform replaces transform on the root element
21:25:52 <nikos_> ... nobody quite implements that in a consistent way
21:26:07 <nikos_> ... FF only replaces transform attribute, not transform style
21:26:10 <ed_work> note that I have landed some patches a while back in blink that may have affected this (so, might be good to test in a canary build)
21:26:29 <nikos_> heycam: no consistency might be good as we can choose best behaviour
21:26:42 <nikos_> ... I'll read through the emails ready for next week
21:26:51 <AmeliaBR> s/my preference is/my preference for/
21:27:56 <nikos_> AmeliaBR: there are some issues with escaping - I would like to rewrite this to be more consistent with browsers
21:28:07 <nikos_> ... specifically that browsers should respect url escape notation
21:28:18 <nikos_> ... but in many cases browsers let you treat spaces as spaces
21:28:26 <nikos_> heycam: probably that section should just be informative
21:28:30 <AmeliaBR> https://svgwg.org/svg2-draft/linking.html#issue8
21:28:44 <nikos_> AmeliaBR: problem is browsers don't decode the url encoding in the target fragment - or at least only some do
21:28:58 <nikos_> ... we can def say 'don't use spaces'
21:29:11 <nikos_> ... think it makes sense t orequire them to decode the url encoding
21:29:24 <nikos_> heycam: not sure about that - I want to do some reading
21:29:42 <AmeliaBR> s/we can def say/we can definitely remove where it says/
21:29:47 <nikos_> ... I feel like at the time you're looking at the url here - in terms of parsing the view -
21:30:31 <nikos_> zakim, mute AmeliaBR
21:30:31 <Zakim> AmeliaBR should now be muted
21:31:00 <AmeliaBR> Can we get feedback from implementations?  Anyone want to look in the code and see how it works?
21:31:19 <nikos_> heycam: I agree that if we can turn this into a realistic informative statement about how to write things in the url so it's interpreted correctly, then I'm happy with that
21:31:50 <nikos_> ... I can look into what FF is doing and get back to you
21:32:14 <AmeliaBR> zakim, unmute me
21:32:14 <Zakim> AmeliaBR should no longer be muted
21:32:24 <nikos_> AmeliaBR: I did have a test case
21:32:33 <nikos_> ... I'll send it out again
21:33:05 <nikos_> AmeliaBR: only other issue in that chapter, Cam was going to follow up with CSS group
21:33:36 <nikos_> ... it's issue 12
21:33:42 <nikos_> https://svgwg.org/svg2-draft/linking.html#issue12
21:33:43 <AmeliaBR> zakim, mute me
21:33:43 <Zakim> AmeliaBR should now be muted
21:33:45 <AmeliaBR> https://svgwg.org/svg2-draft/linking.html#issue12
21:34:34 <nikos_> heycam: we can follow up linking issues next week and go through issues in the appendices
21:34:36 <Zakim> -Thomas_Smailus
21:34:38 <Zakim> -stakagi_
21:34:39 <nikos_> RRSAgent, make minutes public
21:34:39 <RRSAgent> I'm logging. I don't understand 'make minutes public', nikos_.  Try /msg RRSAgent help
21:34:39 <Zakim> -ed_work
21:34:40 <AmeliaBR> s/that chapter/that chapter, re viewTarget/
21:34:40 <Zakim> -heycam
21:34:42 <Zakim> -[Microsoft]
21:34:46 <Zakim> -??P5
21:34:52 <Zakim> -AmeliaBR
21:35:00 <Zakim> -Tav
21:39:16 <AmeliaBR> zakim, make logs public
21:39:16 <Zakim> I don't understand 'make logs public', AmeliaBR
21:39:21 <AmeliaBR> zakim, make log public
21:39:21 <Zakim> I don't understand 'make log public', AmeliaBR
21:39:39 <AmeliaBR> RRSAgent, make logs public
21:39:50 <AmeliaBR> RRSAgent, publish minutes
21:39:50 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/07-svg-minutes.html AmeliaBR
21:40:00 <Zakim> disconnecting the lone participant, stakagi, in GA_SVGWG()4:30PM
21:40:01 <Zakim> GA_SVGWG()4:30PM has ended
21:40:01 <Zakim> Attendees were Thomas_Smailus, [IPcaller], heycam, ed_work, AmeliaBR, Tav, [Microsoft], stakagi, fantasai, Doug, stakagi_
23:50:13 <jdaggett> jdaggett has joined #svg