W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2008

Minutes, Tuesaday July 8, 2008

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>
Message-ID: <20080708121936.GB7129@arc.mcc.id.au>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:09 UTC