- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 8 Jul 2008 22:19:36 +1000
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
http://www.w3.org/2008/07/08-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
08 Jul 2008
[2]Agenda
[2] http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A524E3D4EA9@mailkeeper.mdigitalm.com
See also: [3]IRC log
[3] http://www.w3.org/2008/07/08-svg-irc
Attendees
Present
heycam, Shepazu, aemmons, anthony
Regrets
Chair
Andrew
Scribe
Cameron
Contents
* [4]Topics
1. [5]SVG WG Review of XHTML Access Module
2. [6]SVG Tiny 1.2 comparisons of IRIs for resource documents
3. [7]SVGt 1.2 Tests: Rationale of fonts-elem-05-t
4. [8]SVG Tiny 1.2 comparisons of IRIs for resource documents
5. [9]progress event implementer feedback
6. [10]XHTML Access review
7. [11]SVG in HTML
8. [12]error in (draft) test struct-discard-202-t.svg
9. [13]paint-other-202-t.svg regression
10. [14]error in paint-nsstroke-202-t.svg
11. [15]animate-elem-60-t.svg and animate-elem-62-t.svg using
wallclock
12. [16]telcon time
* [17]Summary of Action Items
_________________________________________________________
<trackbot> Date: 08 July 2008
oh, right
shepazu, can you prod Zakim into allowing us in?
<aemmons> oh, can we change this dynamically?
<shepazu> grr
=P
<aemmons> wow, the power!
i didn't think i could do it
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
SVG WG Review of XHTML Access Module
AE: we should be getting this out asap
DS: i wrote in a few more notes
... it'd be nice if other people confirmed that they seem reasonable
CM: i haven't looked at them
... good point to use dom 3 events key identifiers instead of
characters
... except that that's in a state of flux atm
DS: not sure implementors are rushing to implement this right now,
so shouldn't be a problem
<shepazu> my personal review:
[18]http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0
052.html
[18] http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0052.html
AE: i'm happy with those mails be sent out on behalf of the group
DS: i hope to get some comments from chris
AE: should we wait?
DS: it is due in 2 days, so we can wait until then at least
<scribe> ACTION: Doug to write up the XHTML Access review [recorded
in [19]http://www.w3.org/2008/07/08-svg-minutes.html#action01]
<trackbot> Created ACTION-2083 - Write up the XHTML Access review
[on Doug Schepers - due 2008-07-15].
ed_,
[20]http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A524E3D4EA5
@mailkeeper.mdigitalm.com
[20] http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A524E3D4EA5@mailkeeper.mdigitalm.com
ed_, are you able to call in now?
SVG Tiny 1.2 comparisons of IRIs for resource documents
<aemmons>
[21]http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/016
6.html
[21] http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0166.html
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
AE: once ed's on we could decide on that
SVGt 1.2 Tests: Rationale of fonts-elem-05-t
<aemmons>
[22]http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/016
0.html
[22] http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0160.html
CM: looks like someone should review that test offline now
<scribe> ACTION: Andrew to review fonts-elem-05-t [recorded in
[23]http://www.w3.org/2008/07/08-svg-minutes.html#action02]
<trackbot> Sorry, amibiguous username (more than one match) - Andrew
<trackbot> Try using a different identifier, such as family name or
username (eg. asledd, aemmons)
SVG Tiny 1.2 comparisons of IRIs for resource documents
ED: nobody's saying we should use the post-redirect IRIs, so it
looks like we're agreed
<scribe> ACTION: Cameron to remove the post-redirect IRI stuff and
reply to roc [recorded in
[24]http://www.w3.org/2008/07/08-svg-minutes.html#action03]
<trackbot> Created ACTION-2084 - Remove the post-redirect IRI stuff
and reply to roc [on Cameron McCormack - due 2008-07-15].
RESOLUTION: Comparisons of IRIs to determine whether another
resource document is created should be performed on the pre-redirect
IRI, not post-redirect
progress event implementer feedback
<aemmons>
[25]http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/009
2.html
[25] http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0092.html
AE: we're finally implementing these, and we'll have some tests to
contribute
... when loading a resource that could be local or external, we want
to discuss why local should be allowed
... seems to be an implementation burden
... don't know what the standalone progress event spec says about
that
ED: it's kind of weird, it doesn't seem like it's a big use case to
have
AE: the only thing i could think of is for progressively rendering
UAs
... you are parsing the stream, rendering as it goes, maybe you have
something local that is big
... e.g. a base64 <img>
... since you're progressively rendering you could get some progress
events on that
... i haven't really seen any progressively rendering UAs in the
wild anyway
CM: maybe for consistency, if your application could get an
arbitrary IRI, you want the events to be the same
... so the app doesn't have to check
<ed__> [26]http://www.w3.org/TR/progress-events/
[26] http://www.w3.org/TR/progress-events/
[27]http://dev.w3.org/2006/webapi/progress/Progress.html
[27] http://dev.w3.org/2006/webapi/progress/Progress.html
<shepazu>
[28]http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progres
s.html?rev=1.21&content-type=text/html;%20charset=iso-8859-1
[28] http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.21&content-type=text/html;%20charset=iso-8859-1
DS: it's something we could potentially add to full if we find we've
made a mistake
RESOLUTION: Progress events will only fire for resources that are
external
<scribe> ACTION: Andrew to edit the spec to say that progress events
fire only for external resources [recorded in
[29]http://www.w3.org/2008/07/08-svg-minutes.html#action04]
<trackbot> Sorry, amibiguous username (more than one match) - Andrew
<trackbot> Try using a different identifier, such as family name or
username (eg. asledd, aemmons)
AE: another issue is progress events on audio/video
... the events are for loading a resource, and typically with
audio/video we don't get to know when the resource is fully loaded
... usually it's abstracted by the codecs
... even if it's a local file, it starts streaming it locally
... i think that's where MAE come in, to really do the proper
handling of the streamed state of these streamed media files
... i think it's not relevant to have progress events on the
audio/video files because of that
DS: i'm a bit skeptical
ED: i'm wondering as well. we do have some ongoing implementation of
this.
... there seems to be some overlap, but at the same time i'm not
sure MAE is really that useful unless you have streaming
... so if you don't support any streaming protocols, then MAE don't
add as much value
AE: one of the issues with progress events is that it deals with
bytes, but typically for audio/video progress is reported in time
... the implementation issue is that the codecs don't give the level
of detail to report the bytes
... it's always in time
... i think it'd be an implementation burden to have to implement
the codec just to get this information
... e.g. on symbian you really can't change the API, and there's no
way for us to get this information in bytes
ED: isn't that the same in MAE?
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.
... then you might dive into codec writing, or licensing the codec
source
... but yes it is a concern for MAE to get at that lower level
information, too
DS: i'm kind of uncomfortable changing this, since it's a pretty
major change
... without more discussion
... getting ikivo and chris to chime in would be helpful
AE: erik, if you have a partial implementation, have you got it
working for audio/video?
ED: we do have progress events working for video (more HTML5 video,
but should work for SVG too)
AE: the last point my mail then is the bubbling of progress events
... when we were reviewing at the F2F is that they removed the
bubbling phase
ED: i'm wondering what you can benefit from using bubbling vs. not
... for progress you'll get many events, bubbling them in the tree
might be heavy
AE: yes
... heavy even without bubbling.
... 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>
... and check the .target
ED: you still wouldn't get the total loaded bytes, you'd have to do
it yourself
... is it worth the additional overhead of bubbling?
AE: our experience says that it's not worth it
... firstly it's an implementation burden, secondly a performance
burden
CM: what about throttling the dispatch of the events?
AE: if you fire too few then progress isn't useful, so it's a
balance
CM: and you still have to do the capture phase?
AE: in 1.2 full, but not in tiny
CM: ok
ED: imo i would like to see us align with the progress events spec
to say that it doesn't bubble
... not sure about the other postload/preload, if those are usable
or useful to have bubbling
AE: you want them to not bubble, but then doesn't that mean
postload/preload don't bubble either?
ED: it seems that a host language could say something else
... i'd prefer the bubbling to be the same as in progress events
... less burden on us for implementing
CM: i'm happy with making that align
DS: fine by me
RESOLUTION: Progress events won't bubble, aligning with the
standalone progress events spec
<scribe> ACTION: Andrew to edit the spec to make progress events not
bubble [recorded in
[30]http://www.w3.org/2008/07/08-svg-minutes.html#action05]
<trackbot> Sorry, amibiguous username (more than one match) - Andrew
<trackbot> Try using a different identifier, such as family name or
username (eg. asledd, aemmons)
AE: erik do you have some tests?
ED: not sure i'll have time for it before vacation, maybe in time
for the f2f
AE: do you want to talk about the names of the events?
ED: i was wondering if we wanted to change the SVG event names
... but there's not a simple mapping for postload, since progress
events have three different events (load, error, abort)
... all of those three are covered by SVGPostLoad
... it's basically a question of if you receive one of those three
events you would dispatch an extra SVGPostLoad
... or not to dispatch the extra one, and let script deal with it
AE: if we changed these names, would that be a normative reference?
ED: no, but you'd just have to keep the specs in sync
DS: any alignment is good, but i'm also cautious of us changing
things
... it seems late to be changing things, and progress events is a
moving target
AE: my main concern is that there are specs that are using svg that
would rely on these, e.g. OMA/JSRs
DS: can you find out andrew if they do, and if it would be a problem
to change them?
AE: ok
... so leave this one open for discussion, and i'll contact oma/jsr
to get back to us?
DS: yes
<scribe> ACTION: Andrew to contact OMA/JSRs about changing progress
event names [recorded in
[31]http://www.w3.org/2008/07/08-svg-minutes.html#action06]
<trackbot> Sorry, amibiguous username (more than one match) - Andrew
<trackbot> Try using a different identifier, such as family name or
username (eg. asledd, aemmons)
XHTML Access review
DS: erik did you have anything to add?
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.
... which may not be the main use case anyway
DS: can you send in an email about that?
ED: sure
DS: i'll integrate the comments by thursday
SVG in HTML
DS: we've made some good progress on that, and i want to send it off
soon
ED: i added a few comments
DS: i added a couple of examples, the more i think about it the more
i like the <foreignObject> thing for fallback
... 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?
ED: it's difficult to say. they still have the bold stuff in the
html5 spec but commented out.
... 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
DS: it's really dense
... it seems like it's a diff to what's in html5 today
... so it might be good if we also summarised exactly point-by-point
what these changes to the algorithm mean
ED: why we have the requirements we do?
DS: i guess i want a top level summary of what these changes achieve
AE: when i read it, i also wanted a high level summary
DS: i'd like to send it off by friday
<shepazu>
[32]http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html
[32] http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html
ED: i'm just noting that <foreignObject> with <switch> example
doesn't have any <foreignObject> in it
... it just has <img>, which is fine
... you don't have to put your HTML elements inside a
<foreignObject>, as long as they're well formed
DS: i wonder about the last requirement/use case
ED: are you suggesting we take that out, and add a higher level
description of what we want to change?
DS: we could say something about well defined error handling,
tolerant attribute values
ED: i'll work on it and add a high level description
error in (draft) test struct-discard-202-t.svg
<aemmons>
[33]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/001
4.html
[33] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0014.html
AE: this particular test has a few subcases
... we patched in the description for the discard3 subtest
... and it has an invalid value for the begin=""
... the test is saying that it should use the lacuna value, 0s
... however the smil spec says that when there's an invalid value it
should use indefinite instead
... my suspicion is that we passed the test before we changed some
text in the <discard> section of the spec
... so it looks like the test wasn't updated
CM: i took a look at this, and agree
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
<scribe> ACTION: Andrew to fix struct-discard-202-t [recorded in
[34]http://www.w3.org/2008/07/08-svg-minutes.html#action07]
<trackbot> Sorry, amibiguous username (more than one match) - Andrew
<trackbot> Try using a different identifier, such as family name or
username (eg. asledd, aemmons)
<scribe> ACTION: emmons to review fonts-elem-05-t [recorded in
[35]http://www.w3.org/2008/07/08-svg-minutes.html#action08]
<trackbot> Created ACTION-2085 - Review fonts-elem-05-t [on Andrew
Emmons - due 2008-07-15].
<scribe> ACTION: emmons to edit the spec to say that progress events
fire only for external resources [recorded in
[36]http://www.w3.org/2008/07/08-svg-minutes.html#action09]
<trackbot> Created ACTION-2086 - Edit the spec to say that progress
events fire only for external resources [on Andrew Emmons - due
2008-07-15].
<scribe> ACTION: emmons to edit the spec to make progress events not
bubble [recorded in
[37]http://www.w3.org/2008/07/08-svg-minutes.html#action10]
<trackbot> Created ACTION-2087 - Edit the spec to make progress
events not bubble [on Andrew Emmons - due 2008-07-15].
<scribe> ACTION: emmons to contact OMA/JSRs about changing progress
event names [recorded in
[38]http://www.w3.org/2008/07/08-svg-minutes.html#action11]
<trackbot> Created ACTION-2088 - Contact OMA/JSRs about changing
progress event names [on Andrew Emmons - due 2008-07-15].
<scribe> ACTION: emmons to fix struct-discard-202-t [recorded in
[39]http://www.w3.org/2008/07/08-svg-minutes.html#action12]
<trackbot> Created ACTION-2089 - Fix struct-discard-202-t [on Andrew
Emmons - due 2008-07-15].
<aemmons>
[40]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/001
5.html
[40] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0015.html
paint-other-202-t.svg regression
AE: the test defines solid colours
... the previous version of the test uses them, but the new version
doesn't use them
... we should add those paint server references back in
... and then reapprove, i guess
CM: should we always remove the approved status when we edit an
approved test?
AE: i think so, then get approval again
<scribe> ACTION: Anthony to fix paint-other-202-t to reinstate the
paint server references [recorded in
[41]http://www.w3.org/2008/07/08-svg-minutes.html#action13]
<trackbot> Created ACTION-2090 - Fix paint-other-202-t to reinstate
the paint server references [on Anthony Grasso - due 2008-07-15].
AE: so that one should be set back to created
... then i'll review it
error in paint-nsstroke-202-t.svg
<aemmons>
[42]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/001
6.html
[42] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0016.html
AE: a simple thing again
... the description says that the test has fixed dimensions, doesn't
have a viewBox=""
... but our template has a viewBox=""
... so with the new template that viewBox="" got put back in. we
just need to remove it.
<scribe> ACTION: Anthony to fix paint-nsstroke-202-t by removing the
viewBox="" [recorded in
[43]http://www.w3.org/2008/07/08-svg-minutes.html#action14]
<trackbot> Created ACTION-2091 - Fix paint-nsstroke-202-t by
removing the viewBox=\"\" [on Anthony Grasso - due 2008-07-15].
<aemmons>
[44]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/001
7.html
[44] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0017.html
animate-elem-60-t.svg and animate-elem-62-t.svg using wallclock
AE: these are definitely old issues
... these were moved over from 1.1 and use wallclock, but wallclock
isn't part of tiny
... we should remove the subtest for wallclock, or put in a
description of what should happen
CM: i'd be happy with just removing them
<scribe> ACTION: Anthony to fix animate-elem-60-t and -elem-61-t to
remove the wallclock subtests [recorded in
[45]http://www.w3.org/2008/07/08-svg-minutes.html#action15]
<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].
telcon time
DS: chris was ok with this time before
... and it's ok with me
AE: i don't want to force everyone to change
AG: this time is fine for me
CM: me too
AE: i'll update the wiki with this new tuesday time
Summary of Action Items
[NEW] ACTION: Andrew to contact OMA/JSRs about changing progress
event names [recorded in
[46]http://www.w3.org/2008/07/08-svg-minutes.html#action06]
[NEW] ACTION: Andrew to edit the spec to make progress events not
bubble [recorded in
[47]http://www.w3.org/2008/07/08-svg-minutes.html#action05]
[NEW] ACTION: Andrew to edit the spec to say that progress events
fire only for external resources [recorded in
[48]http://www.w3.org/2008/07/08-svg-minutes.html#action04]
[NEW] ACTION: Andrew to fix struct-discard-202-t [recorded in
[49]http://www.w3.org/2008/07/08-svg-minutes.html#action07]
[NEW] ACTION: Andrew to review fonts-elem-05-t [recorded in
[50]http://www.w3.org/2008/07/08-svg-minutes.html#action02]
[NEW] ACTION: Anthony to fix animate-elem-60-t and -elem-61-t to
remove the wallclock subtests [recorded in
[51]http://www.w3.org/2008/07/08-svg-minutes.html#action15]
[NEW] ACTION: Anthony to fix paint-nsstroke-202-t by removing the
viewBox="" [recorded in
[52]http://www.w3.org/2008/07/08-svg-minutes.html#action14]
[NEW] ACTION: Anthony to fix paint-other-202-t to reinstate the
paint server references [recorded in
[53]http://www.w3.org/2008/07/08-svg-minutes.html#action13]
[NEW] ACTION: Cameron to remove the post-redirect IRI stuff and
reply to roc [recorded in
[54]http://www.w3.org/2008/07/08-svg-minutes.html#action03]
[NEW] ACTION: Doug to write up the XHTML Access review [recorded in
[55]http://www.w3.org/2008/07/08-svg-minutes.html#action01]
[NEW] ACTION: emmons to contact OMA/JSRs about changing progress
event names [recorded in
[56]http://www.w3.org/2008/07/08-svg-minutes.html#action11]
[NEW] ACTION: emmons to edit the spec to make progress events not
bubble [recorded in
[57]http://www.w3.org/2008/07/08-svg-minutes.html#action10]
[NEW] ACTION: emmons to edit the spec to say that progress events
fire only for external resources [recorded in
[58]http://www.w3.org/2008/07/08-svg-minutes.html#action09]
[NEW] ACTION: emmons to fix struct-discard-202-t [recorded in
[59]http://www.w3.org/2008/07/08-svg-minutes.html#action12]
[NEW] ACTION: emmons to review fonts-elem-05-t [recorded in
[60]http://www.w3.org/2008/07/08-svg-minutes.html#action08]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [61]scribe.perl version 1.133
([62]CVS log)
$Date: 2008/07/08 12:00:03 $
_________________________________________________________
[61] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[62] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51
Check for newer version at [63]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[63] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/<image>/<img>/
Succeeded: s/<image>/<img>/
Found Scribe: Cameron
Found ScribeNick: heycam
WARNING: Replacing list of attendees.
Old list: heycam Doug_Schepers aemmons ed__
New list: heycam Shepazu aemmons anthony
Default Present: heycam, Shepazu, aemmons, anthony
Present: heycam Shepazu aemmons anthony
Agenda: [64]http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A524E3
D4EA9@mailkeeper.mdigitalm.com
Found Date: 08 Jul 2008
Guessing minutes URL: [65]http://www.w3.org/2008/07/08-svg-minutes.html
People with action items: andrew anthony cameron doug emmons
[64] http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A524E3D4EA9@mailkeeper.mdigitalm.com
[65] http://www.w3.org/2008/07/08-svg-minutes.html
WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
End of [66]scribe.perl diagnostic output]
[66] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 8 July 2008 12:20:33 UTC