10:31:20 <RRSAgent> RRSAgent has joined #svg
10:31:20 <RRSAgent> logging to http://www.w3.org/2008/07/08-svg-irc
10:31:22 <trackbot> RRSAgent, make logs public
10:31:24 <trackbot> Zakim, this will be GA_SVGWG
10:31:24 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
10:31:25 <trackbot> Meeting: SVG Working Group Teleconference
10:31:25 <trackbot> Date: 08 July 2008
10:31:46 <heycam> oh, right
10:32:03 <heycam> shepazu, can you prod Zakim into allowing us in?
10:32:06 <aemmons> oh, can we change this dynamically?
10:32:18 <heycam> Zakim, room for 8?
10:32:20 <Zakim> ok, heycam; conference Team_(svg)10:32Z scheduled with code 26631 (CONF1) for 60 minutes until 1132Z
10:32:28 <shepazu> Zakim, room for 6?
10:32:28 <Zakim> shepazu, an adhoc conference was scheduled here less than 2 minutes ago
10:32:36 <shepazu> grr
10:32:38 <heycam> =P
10:32:41 <aemmons> wow, the power!
10:32:47 <heycam> i didn't think i could do it
10:33:01 <Zakim> Team_(svg)10:32Z has now started
10:33:08 <Zakim> +??P0
10:33:11 <heycam> Zakim, ??P0 is me
10:33:11 <Zakim> +heycam; got it
10:33:12 <shepazu> Zakim, this will be SVG
10:33:12 <Zakim> ok, shepazu, I see Team_(svg)10:32Z already started
10:33:27 <Zakim> +[IPcaller]
10:33:35 <Zakim> +Doug_Schepers
10:33:38 <aemmons> zakim, [IPcaller] is me
10:33:38 <Zakim> +aemmons; got it
10:39:26 <heycam> Scribe: Cameron
10:39:28 <heycam> ScribeNick: heycam
10:39:33 <heycam> Chair: Andrew
10:39:50 <heycam> Agenda: http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A524E3D4EA9@mailkeeper.mdigitalm.com
10:40:30 <heycam> Topic: SVG WG Review of XHTML Access Module
10:40:54 <heycam> AE: we should be getting this out asap
10:40:57 <heycam> DS: i wrote in a few more notes
10:41:08 <heycam> DS: it'd be nice if other people confirmed that they seem reasonable
10:41:18 <heycam> CM: i haven't looked at them
10:42:28 <heycam> CM: good point to use dom 3 events key identifiers instead of characters
10:42:39 <heycam> CM: except that that's in a state of flux atm
10:42:55 <heycam> DS: not sure implementors are rushing to implement this right now, so shouldn't be a problem
10:44:57 <shepazu> my personal review: http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0052.html
10:46:59 <heycam> AE: i'm happy with those mails be sent out on behalf of the group
10:48:32 <heycam> DS: i hope to get some comments from chris
10:48:39 <heycam> AE: should we wait?
10:48:45 <heycam> DS: it is due in 2 days, so we can wait until then at least
10:49:00 <heycam> ACTION: Doug to write up the XHTML Access review
10:49:06 <trackbot> Created ACTION-2083 - Write up the XHTML Access review [on Doug Schepers - due 2008-07-15].
10:49:36 <heycam> ed_, http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A524E3D4EA5@mailkeeper.mdigitalm.com
10:49:40 <heycam> ed_, are you able to call in now?
10:50:00 <heycam> Topic: SVG Tiny 1.2 comparisons of IRIs for resource documents
10:50:05 <aemmons> http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0166.html
10:52:35 <heycam> CM: after finding out that bitflash didn't have this behaviour, it made me wonder whether it was bitflash that had that behaviour in the first place
10:52:57 <heycam> AE: once ed's on we could decide on that
10:53:25 <heycam> Topic: SVGt 1.2 Tests: Rationale of fonts-elem-05-t
10:53:30 <aemmons> http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0160.html
10:54:22 <heycam> CM: looks like someone should review that test offline now
10:54:29 <heycam> ACTION: Andrew to review fonts-elem-05-t
10:54:29 <trackbot> Sorry, amibiguous username (more than one match) - Andrew
10:54:29 <trackbot> Try using a different identifier, such as family name or username (eg. asledd, aemmons)
10:54:46 <ed__> ed__ has joined #svg
10:55:11 <heycam> Zakim, code?
10:55:11 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), heycam
10:55:32 <Zakim> +??P3
10:55:42 <ed__> Zakim, ??P3 is me
10:55:42 <Zakim> +ed__; got it
10:57:56 <heycam> Topic: SVG Tiny 1.2 comparisons of IRIs for resource documents
10:58:16 <heycam> ED: nobody's saying we should use the post-redirect IRIs, so it looks like we're agreed
10:59:08 <heycam> ACTION: Cameron to remove the post-redirect IRI stuff and reply to roc
10:59:09 <trackbot> Created ACTION-2084 - Remove the post-redirect IRI stuff and reply to roc [on Cameron McCormack - due 2008-07-15].
10:59:48 <heycam> RESOLUTION: Comparisons of IRIs to determine whether another resource document is created should be performed on the pre-redirect IRI, not post-redirect
11:00:07 <heycam> Topic: progress event implementer feedback
11:00:09 <aemmons> http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0092.html
11:00:32 <heycam> AE: we're finally implementing these, and we'll have some tests to contribute
11:00:51 <heycam> AE: when loading a resource that could be local or external, we want to discuss why local should be allowed
11:00:55 <heycam> AE: seems to be an implementation burden
11:01:15 <heycam> AE: don't know what the standalone progress event spec says about that
11:01:26 <heycam> ED: it's kind of weird, it doesn't seem like it's a big use case to have
11:01:37 <heycam> AE: the only thing i could think of is for progressively rendering UAs
11:01:50 <heycam> AE: you are parsing the stream, rendering as it goes, maybe you have something local that is big
11:01:56 <heycam> AE: e.g. a base64 <image>
11:02:10 <heycam> AE: since you're progressively rendering you could get some progress events on that
11:02:31 <heycam> AE: i haven't really seen any progressively rendering UAs in the wild anyway
11:03:20 <heycam> CM: maybe for consistency, if your application could get an arbitrary IRI, you want the events to be the same
11:03:24 <heycam> CM: so the app doesn't have to check
11:03:38 <ed__> http://www.w3.org/TR/progress-events/
11:04:16 <heycam> http://dev.w3.org/2006/webapi/progress/Progress.html
11:04:24 <shepazu> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.21&content-type=text/html;%20charset=iso-8859-1
11:07:26 <heycam> DS: it's something we could potentially add to full if we find we've made a mistake
11:07:48 <heycam> RESOLUTION: Progress events will only fire for resources that are external
11:08:05 <heycam> ACTION: Andrew to edit the spec to say that progress events fire only for external resources
11:08:05 <trackbot> Sorry, amibiguous username (more than one match) - Andrew
11:08:05 <trackbot> Try using a different identifier, such as family name or username (eg. asledd, aemmons)
11:08:20 <heycam> AE: another issue is progress events on audio/video
11:08:44 <heycam> AE: the events are for loading a resource, and typically with audio/video we don't get to know when the resource is fully loaded
11:08:49 <heycam> AE: usually it's abstracted by the codecs
11:08:54 <heycam> AE: even if it's a local file, it starts streaming it locally
11:09:16 <heycam> AE: i think that's where MAE come in, to really do the proper handling of the streamed state of these streamed media files
11:09:27 <heycam> AE: i think it's not relevant to have progress events on the audio/video files because of that
11:09:39 <heycam> DS: i'm a bit skeptical
11:09:53 <heycam> ED: i'm wondering as well.  we do have some ongoing implementation of this.
11:10:06 <heycam> ED: there seems to be some overlap, but at the same time i'm not sure MAE is really that useful unless you have streaming
11:10:19 <heycam> ED: so if you don't support any streaming protocols, then MAE don't add as much value
11:10:40 <heycam> AE: one of the issues with progress events is that it deals with bytes, but typically for audio/video progress is reported in time
11:10:50 <heycam> AE: the implementation issue is that the codecs don't give the level of detail to report the bytes
11:10:56 <heycam> AE: it's always in time
11:11:15 <heycam> AE: i think it'd be an implementation burden to have to implement the codec just to get this information
11:11:34 <heycam> AE: e.g. on symbian you really can't change the API, and there's no way for us to get this information in bytes
11:11:44 <heycam> ED: isn't that the same in MAE?
11:12:07 <heycam> AE: yes but MAE is a higher level committment.  when you commit to doing MAE, you're really doing mobile tv type apps, where you're investing more into the codecs.
11:12:17 <heycam> AE: then you might dive into codec writing, or licensing the codec source
11:12:29 <heycam> AE: but yes it is a concern for MAE to get at that lower level information, too
11:12:41 <heycam> DS: i'm kind of uncomfortable changing this, since it's a pretty major change
11:12:48 <heycam> DS: without more discussion
11:13:15 <heycam> DS: getting ikivo and chris to chime in would be helpful
11:13:31 <heycam> AE: erik, if you have a partial implementation, have you got it working for audio/video?
11:13:42 <heycam> ED: we do have progress events working for video (more HTML5 video, but should work for SVG too)
11:14:11 <heycam> AE: the last point my mail then is the bubbling of progress events
11:14:19 <heycam> AE: when we were reviewing at the F2F is that they removed the bubbling phase
11:14:32 <heycam> ED: i'm wondering what you can benefit from using bubbling vs. not
11:14:44 <heycam> ED: for progress you'll get many events, bubbling them in the tree might be heavy
11:14:48 <heycam> AE: yes
11:14:56 <heycam> AE: heavy even without bubbling.
11:15:13 <heycam> AE: the use case here is that you may not want to have an event listener on all of the elements, but just have one on the top-level <svg>
11:15:16 <heycam> AE: and check the .target
11:15:40 <heycam> ED: you still wouldn't get the total loaded bytes, you'd have to do it yourself
11:15:50 <heycam> ED: is it worth the additional overhead of bubbling?
11:15:56 <heycam> AE: our experience says that it's not worth it
11:16:05 <heycam> AE: firstly it's an implementation burden, secondly a performance burden
11:16:30 <heycam> CM: what about throttling the dispatch of the events?
11:16:45 <heycam> AE: if you fire too few then progress isn't useful, so it's a balance
11:17:02 <heycam> CM: and you still have to do the capture phase?
11:17:07 <heycam> AE: in 1.2 full, but not in tiny
11:17:08 <heycam> CM: ok
11:17:50 <heycam> ED: imo i would like to see us align with the progress events spec to say that it doesn't bubble
11:18:06 <heycam> ED: not sure about the other postload/preload, if those are usable or useful to have bubbling
11:18:34 <heycam> AE: you want them to not bubble, but then doesn't that mean postload/preload don't bubble either?
11:18:56 <heycam> ED: it seems that a host language could say something else
11:19:14 <heycam> ED: i'd prefer the bubbling to be the same as in progress events
11:19:22 <heycam> ED: less burden on us for implementing
11:19:43 <heycam> CM: i'm happy with making that align
11:19:45 <heycam> DS: fine by me
11:19:59 <heycam> RESOLUTION: Progress events won't bubble, aligning with the standalone progress events spec
11:20:06 <heycam> ACTION: Andrew to edit the spec to make progress events not bubble
11:20:06 <trackbot> Sorry, amibiguous username (more than one match) - Andrew
11:20:06 <trackbot> Try using a different identifier, such as family name or username (eg. asledd, aemmons)
11:20:12 <heycam> AE: erik do you have some tests?
11:20:21 <heycam> ED: not sure i'll have time for it before vacation, maybe in time for the f2f
11:21:01 <heycam> AE: do you want to talk about the names of the events?
11:21:23 <heycam> ED: i was wondering if we wanted to change the SVG event names
11:21:35 <heycam> ED: but there's not a simple mapping for postload, since progress events have three different events (load, error, abort)
11:21:41 <heycam> ED: all of those three are covered by SVGPostLoad
11:22:39 <heycam> ED: it's basically a question of if you receive one of those three events you would dispatch an extra SVGPostLoad
11:22:49 <heycam> ED: or not to dispatch the extra one, and let script deal with it
11:22:56 <heycam> AE: if we changed these names, would that be a normative reference?
11:23:05 <heycam> ED: no, but you'd just have to keep the specs in sync
11:23:33 <heycam> DS: any alignment is good, but i'm also cautious of us changing things
11:23:41 <heycam> DS: it seems late to be changing things, and progress events is a moving target
11:24:04 <heycam> AE: my main concern is that there are specs that are using svg that would rely on these, e.g. OMA/JSRs
11:24:18 <heycam> DS: can you find out andrew if they do, and if it would be a problem to change them?
11:24:20 <heycam> AE: ok
11:24:48 <heycam> AE: so leave this one open for discussion, and i'll contact oma/jsr to get back to us?
11:24:49 <heycam> DS: yes
11:25:04 <heycam> ACTION: Andrew to contact OMA/JSRs about changing progress event names
11:25:04 <trackbot> Sorry, amibiguous username (more than one match) - Andrew
11:25:04 <trackbot> Try using a different identifier, such as family name or username (eg. asledd, aemmons)
11:25:33 <heycam> Topic: XHTML Access review
11:25:36 <heycam> DS: erik did you have anything to add?
11:25:55 <heycam> ED: you covered most of it.  the other ones were discussed in the telcon last time, about the order, and about having several keys trigerring something.
11:25:59 <heycam> ED: which may not be the main use case anyway
11:26:04 <heycam> DS: can you send in an email about that?
11:26:05 <heycam> ED: sure
11:26:11 <heycam> DS: i'll integrate the comments by thursday
11:26:39 <heycam> Topic: SVG in HTML
11:26:50 <heycam> DS: we've made some good progress on that, and i want to send it off soon
11:26:55 <heycam> ED: i added a few comments
11:27:06 <heycam> DS: i added a couple of examples, the more i think about it the more i like the <foreignObject> thing for fallback
11:27:27 <anthony> anthony has joined #svg
11:28:39 <heycam> DS: so is this a complete proposal., or is this a diff to what's in the spec today, or is it a diff to the previous svg text that was in the html5 spec?
11:28:58 <heycam> ED: it's difficult to say.  they still have the bold stuff in the html5 spec but commented out.
11:29:14 <heycam> ED: this proposal doesn't say put all of that back, it says keep it removed, and additionally remove some more stuff, and redefine some other things as well
11:29:32 <heycam> DS: it's really dense
11:29:58 <heycam> DS: it seems like it's a diff to what's in html5 today
11:29:59 <heycam> Zakim, code?
11:29:59 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), heycam
11:30:18 <heycam> DS: so it might be good if we also summarised exactly point-by-point what these changes to the algorithm mean
11:30:43 <heycam> ED: why we have the requirements we do?
11:31:32 <heycam> DS: i guess i want a top level summary of what these changes achieve
11:32:14 <heycam> AE: when i read it, i also wanted a high level summary
11:32:48 <heycam> DS: i'd like to send it off by friday
11:33:26 <shepazu> http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html
11:33:37 <heycam> ED: i'm just noting that <foreignObject> with <switch> example doesn't have any <foreignObject> in it
11:33:42 <heycam> ED: it just has <image>, which is fine
11:33:57 <heycam> ED: you don't have to put your HTML elements inside a <foreignObject>, as long as they're well formed
11:35:23 <ed__> s/<image>/<img>
11:35:31 <ed__> s/<image>/<img>/
11:35:56 <heycam> DS: i wonder about the last requirement/use case
11:36:34 <heycam> ED: are you suggesting we take that out, and add a higher level description of what we want to change?
11:38:18 <heycam> DS: we could say something about well defined error handling, tolerant attribute values
11:38:26 <heycam> ED: i'll work on it and add a high level description
11:38:33 <anthony> Zakim, room for one more
11:38:33 <Zakim> I don't understand 'room for one more', anthony
11:38:45 <Zakim> -ed__
11:39:20 <Zakim> -Doug_Schepers
11:39:21 <Zakim> -aemmons
11:39:21 <Zakim> -heycam
11:39:23 <Zakim> Team_(svg)10:32Z has ended
11:39:24 <Zakim> Attendees were heycam, Doug_Schepers, aemmons, ed__
11:39:30 <shepazu> Zakim, room for 5?
11:39:31 <Zakim> ok, shepazu; conference Team_(svg)11:39Z scheduled with code 26631 (CONF1) for 60 minutes until 1239Z
11:39:40 <shepazu> Zakim, this will be SVG
11:39:40 <Zakim> "SVG" matches Team_(svg)11:39Z, and GA_SVGWG()8:30AM, shepazu
11:39:52 <Zakim> Team_(svg)11:39Z has now started
11:39:53 <shepazu> Zakim, call shepazu 
11:39:53 <Zakim> ok, shepazu; the call is being made
11:40:00 <Zakim> +??P1
11:40:01 <heycam> Zakim, ??P1 is me
11:40:01 <Zakim> +heycam; got it
11:40:22 <shepazu> Zakim, call shepazu 
11:40:22 <Zakim> ok, shepazu; the call is being made
11:40:23 <Zakim> -heycam
11:40:23 <Zakim> +heycam
11:40:23 <Zakim> +Shepazu
11:40:23 <Zakim> +??P0
11:40:26 <aemmons> zakim, ??p0 is me
11:40:26 <Zakim> +aemmons; got it
11:40:52 <heycam> Topic: error in (draft) test struct-discard-202-t.svg
11:40:54 <aemmons> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0014.html
11:41:13 <heycam> AE: this particular test has a few subcases
11:41:23 <heycam> AE: we patched in the description for the discard3 subtest
11:41:24 <Zakim> +??P2
11:41:29 <heycam> AE: and it has an invalid value for the begin=""
11:41:37 <anthony> Zakim, ??P2 is me
11:41:37 <Zakim> +anthony; got it
11:42:33 <heycam> AE: the test is saying that it should use the lacuna value, 0s
11:42:45 <heycam> AE: however the smil spec says that when there's an invalid value it should use indefinite instead
11:43:09 <heycam> AE: my suspicion is that we passed the test before we changed some text in the <discard> section of the spec
11:43:20 <heycam> AE: so it looks like the test wasn't updated
11:43:33 <heycam> CM: i took a look at this, and agree
11:43:56 <heycam> AE: it is a draft test anyway, still to be approved, but if we agree, then i'll make this change and keep it as reviewed
11:44:22 <heycam> ACTION: Andrew to fix struct-discard-202-t
11:44:22 <trackbot> Sorry, amibiguous username (more than one match) - Andrew
11:44:22 <trackbot> Try using a different identifier, such as family name or username (eg. asledd, aemmons)
11:45:42 <heycam> ACTION: emmons to review fonts-elem-05-t
11:45:42 <trackbot> Created ACTION-2085 - Review fonts-elem-05-t [on Andrew Emmons - due 2008-07-15].
11:45:59 <heycam> ACTION: emmons to edit the spec to say that progress events fire only for external resources
11:46:00 <trackbot> Created ACTION-2086 - Edit the spec to say that progress events fire only for external resources [on Andrew Emmons - due 2008-07-15].
11:46:12 <heycam> ACTION: emmons to edit the spec to make progress events not bubble
11:46:12 <trackbot> Created ACTION-2087 - Edit the spec to make progress events not bubble [on Andrew Emmons - due 2008-07-15].
11:46:21 <heycam> ACTION: emmons to contact OMA/JSRs about changing progress event names
11:46:21 <trackbot> Created ACTION-2088 - Contact OMA/JSRs about changing progress event names [on Andrew Emmons - due 2008-07-15].
11:46:29 <heycam> ACTION: emmons to fix struct-discard-202-t
11:46:29 <trackbot> Created ACTION-2089 - Fix struct-discard-202-t [on Andrew Emmons - due 2008-07-15].
11:46:44 <aemmons> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0015.html
11:46:45 <heycam> Topic: paint-other-202-t.svg regression
11:47:11 <heycam> AE: the test defines solid colours
11:47:23 <heycam> AE: the previous version of the test uses them, but the new version doesn't use them
11:47:50 <heycam> AE: we should add those paint server references back in
11:48:00 <heycam> AE: and then reapprove, i guess
11:48:44 <heycam> CM: should we always remove the approved status when we edit an approved test?
11:48:50 <heycam> AE: i think so, then get approval again
11:50:03 <heycam> ACTION: Anthony to fix paint-other-202-t to reinstate the paint server references
11:50:09 <trackbot> Created ACTION-2090 - Fix paint-other-202-t to reinstate the paint server references [on Anthony Grasso - due 2008-07-15].
11:50:58 <heycam> AE: so that one should be set back to created
11:51:04 <heycam> AE: then i'll review it
11:51:20 <heycam> Topic: error in paint-nsstroke-202-t.svg
11:51:23 <aemmons> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0016.html
11:51:37 <heycam> AE: a simple thing again
11:51:53 <heycam> AE: the description says that the test has fixed dimensions, doesn't have a viewBox=""
11:51:57 <heycam> AE: but our template has a viewBox=""
11:52:12 <heycam> AE: so with the new template that viewBox="" got put back in.  we just need to remove it.
11:53:10 <heycam> ACTION: Anthony to fix paint-nsstroke-202-t by removing the viewBox=""
11:53:10 <trackbot> Created ACTION-2091 - Fix paint-nsstroke-202-t by removing the viewBox=\"\" [on Anthony Grasso - due 2008-07-15].
11:53:42 <aemmons> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0017.html
11:53:44 <heycam> Topic: animate-elem-60-t.svg and animate-elem-62-t.svg using wallclock
11:53:56 <heycam> AE: these are definitely old issues
11:54:14 <heycam> AE: these were moved over from 1.1 and use wallclock, but wallclock isn't part of tiny
11:54:31 <heycam> AE: we should remove the subtest for wallclock, or put in a description of what should happen
11:54:50 <heycam> CM: i'd be happy with just removing them
11:55:20 <heycam> ACTION: Anthony to fix animate-elem-60-t and -elem-61-t to remove the wallclock subtests
11:55:26 <trackbot> Created ACTION-2092 - Fix animate-elem-60-t and -elem-61-t to remove the wallclock subtests [on Anthony Grasso - due 2008-07-15].
11:56:03 <heycam> Topic: telcon time
11:56:06 <heycam> DS: chris was ok with this time before
11:56:10 <heycam> DS: and it's ok with me
11:56:17 <heycam> AE: i don't want to force everyone to change
11:57:19 <heycam> AG: this time is fine for me
11:57:21 <heycam> CM: me too
11:57:40 <Zakim> -Shepazu
11:58:05 <heycam> AE: i'll update the wiki with this new tuesday time
11:58:09 <Zakim> -aemmons
11:58:11 <Zakim> -heycam
11:58:18 <Zakim> -anthony
11:58:19 <Zakim> Team_(svg)11:39Z has ended
11:58:21 <Zakim> Attendees were heycam, Shepazu, aemmons, anthony
11:58:23 <heycam> RRSAgent, bye
11:58:23 <RRSAgent> I see 15 open action items saved in http://www.w3.org/2008/07/08-svg-actions.rdf :
11:58:23 <RRSAgent> ACTION: Doug to write up the XHTML Access review [1]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T10-49-00
11:58:23 <RRSAgent> ACTION: Andrew to review fonts-elem-05-t [2]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T10-54-29
11:58:23 <RRSAgent> ACTION: Cameron to remove the post-redirect IRI stuff and reply to roc [3]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T10-59-08
11:58:23 <RRSAgent> ACTION: Andrew to edit the spec to say that progress events fire only for external resources [4]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T11-08-05
11:58:23 <RRSAgent> ACTION: Andrew to edit the spec to make progress events not bubble [5]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T11-20-06
11:58:23 <RRSAgent> ACTION: Andrew to contact OMA/JSRs about changing progress event names [6]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T11-25-04
11:58:23 <RRSAgent> ACTION: Andrew to fix struct-discard-202-t [7]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T11-44-22
11:58:23 <RRSAgent> ACTION: emmons to review fonts-elem-05-t [8]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T11-45-42
11:58:23 <RRSAgent> ACTION: emmons to edit the spec to say that progress events fire only for external resources [9]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T11-45-59
11:58:23 <RRSAgent> ACTION: emmons to edit the spec to make progress events not bubble [10]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T11-46-12
11:58:23 <RRSAgent> ACTION: emmons to contact OMA/JSRs about changing progress event names [11]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T11-46-21
11:58:23 <RRSAgent> ACTION: emmons to fix struct-discard-202-t [12]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T11-46-29
11:58:23 <RRSAgent> ACTION: Anthony to fix paint-other-202-t to reinstate the paint server references [13]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T11-50-03
11:58:23 <RRSAgent> ACTION: Anthony to fix paint-nsstroke-202-t by removing the viewBox="" [14]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T11-53-10
11:58:23 <RRSAgent> ACTION: Anthony to fix animate-elem-60-t and -elem-61-t to remove the wallclock subtests [15]
11:58:23 <RRSAgent>   recorded in http://www.w3.org/2008/07/08-svg-irc#T11-55-20
11:59:53 <RRSAgent> RRSAgent has joined #svg
11:59:53 <RRSAgent> logging to http://www.w3.org/2008/07/08-svg-irc
11:59:57 <heycam> RRSAgent, make minutes
11:59:57 <RRSAgent> I have made the request to generate http://www.w3.org/2008/07/08-svg-minutes.html heycam
12:02:27 <heycam> shepazu, could you fix the permissions on http://www.w3.org/2008/07/08-svg-minutes.html?
12:02:29 <heycam> i think i fucked it up
12:19:52 <heycam> shepazu, nm it's done
13:56:35 <ChrisL> ChrisL has joined #svg
13:58:58 <Zakim> Zakim has left #svg
15:19:15 <ed_> ed_ has joined #svg
15:33:04 <aemmons> aemmons has joined #svg