See also: IRC log
<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
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: 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 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_, http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A524E3D4EA5@mailkeeper.mdigitalm.com
ed_, are you able to call in now?
<aemmons> 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
<aemmons> 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 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)
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 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
<aemmons> 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__> http://www.w3.org/TR/progress-events/
http://dev.w3.org/2006/webapi/progress/Progress.html
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 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 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 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)
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
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> 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
<aemmons> 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 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 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 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 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 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 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> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0015.html
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 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
<aemmons> 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 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> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0017.html
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 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].
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
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at 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: http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A524E3D4EA9@mailkeeper.mdigitalm.com Found Date: 08 Jul 2008 Guessing minutes URL: http://www.w3.org/2008/07/08-svg-minutes.html People with action items: andrew anthony cameron doug emmons WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]