IRC log of svg on 2008-07-08

Timestamps are in UTC.

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:22 [Zakim]: Zakim has joined #svg
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