- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 25 Sep 2008 22:09:23 +1000
- To: public-svg-wg@w3.org
http://www.w3.org/2008/09/25-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
25 Sep 2008
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0353.html
See also: [3]IRC log
[3] http://www.w3.org/2008/09/25-svg-irc
Attendees
Present
NH, +1.613.445.aaaa, anthony, [IPcaller], heycam, ed_,
Doug_Schepers, aemmons
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Cameron
Contents
* [4]Topics
1. [5]Scope chain modification for <handler>s
2. [6]review of some proposed changes
3. [7]Test suite comments
4. [8]last call comments
* [9]Summary of Action Items
_________________________________________________________
<trackbot> Date: 25 September 2008
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
Scope chain modification for <handler>s
CM: none of the implementations i tested put the event target in the
scope chain
ED: there was a reply on the public list
[10]http://lists.w3.org/Archives/Public/www-svg/2008Sep/0111.html
[10] http://lists.w3.org/Archives/Public/www-svg/2008Sep/0111.html
CM: that mail's on a related issue
... erik thought it might be useful to have
ED: that's the only objection i could have to removing it
... don't have a strong opinion
... it'd be easier for me if we removed it, then we wouldn't have to
change our implementation
CM: does the ikivo player add the event target into the scope chain
when running handlers?
NH: we also do not do that, so we're the same as opera and bitflash
CM: since it doesn't happen in HTML, and since all the
implementations agree, i think we should remove it
ED: any objections to removing it?
(silence)
RESOLUTION: Remove the scope chain wording from the spec
<scribe> ACTION: Cameron remove the scope chain wording from the
<handler> section [recorded in
[11]http://www.w3.org/2008/09/25-svg-minutes.html#action01]
<trackbot> Created ACTION-2214 - Remove the scope chain wording from
the <handler> section [on Cameron McCormack - due 2008-10-02].
review of some proposed changes
<anthony>
[12]http://dev.w3.org/SVG/profiles/1.2T/master/intro.html#TermRender
ingTree
[12] http://dev.w3.org/SVG/profiles/1.2T/master/intro.html#TermRenderingTree
<ed_>
[13]http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/intro.html.dif
f?r1=1.122&r2=1.123&f=h
[13] http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/intro.html.diff?r1=1.122&r2=1.123&f=h
AG: the addition is in the last sentence of that definition
... i put that in so that it implies <audio> also sits in the
rendering tree
... it was a clarification, not changing conformance
... the other change was in the painting chapter
<anthony>
[14]http://dev.w3.org/SVG/profiles/1.2T/master/painting.html#Display
Property
[14] http://dev.w3.org/SVG/profiles/1.2T/master/painting.html#DisplayProperty
<ed_>
[15]http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/painting.html.
diff?r1=1.118&r2=1.119&f=h
[15] http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/painting.html.diff?r1=1.118&r2=1.119&f=h
AG: I added in the media elements to the list of elements the
property applies to
... and that pulls in graphics elements and the <audio> element
... also enhanced the wording to talk about the audibility of the
<audio> element, and what each value does to it
ED: what was the action?
<anthony> ACTION-2207?
<trackbot> ACTION-2207 -- Anthony Grasso to review the wording of
visibility relating to audio -- due 2008-09-30 -- PENDINGREVIEW
<trackbot> [16]http://www.w3.org/Graphics/SVG/WG/track/actions/2207
[16] http://www.w3.org/Graphics/SVG/WG/track/actions/2207
CM: the paragraph starting "Depending on the value of property
'pointer-events'" doesn't really apply to <audio>
... are <video> and <animation> media elements?
ED: yes
AG: i'll remove mention of media elements from that sentence
<ed_> <video> and <animation> are also graphics elements
<ed_> as well as being media elements
ED: pending that last change i'd be ok with closing the action
AG: i raised an issue on Core 2.0 on this issue too, since we should
be able to control audio separately from video
Test suite comments
<ed_>
[17]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/032
6.html
[17] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0326.html
NH: starting from interact-focus-208
<ed_>
[18]http://dev.w3.org/SVG/profiles/1.2T/test/svg/interact-focus-208-
t.svg
[18] http://dev.w3.org/SVG/profiles/1.2T/test/svg/interact-focus-208-t.svg
NH: the test description is wrong i think
... the test also says that "jumped" should be focussed at the same
time as "frogs" and "in"
ED: I agree it's not fully clear
... for the first paragraph i agree with you that it should say
something like you say (about "frogs" and "in" before "jumped")
... i agree "in" is not focusable by itself
... "frogs" "in" is in one <tspan>, so they must be focussed
together
NH: and when after frogs you get jumped
... the test says when jumped is focussed, frogs and in should be
focussed
ED: green, not focussed
NH: yes
... but i don't think that's true, because the animations trigger on
focusout and focusin
ED: i think it's correct, because the tspan has a focusin listener
which will be triggered by the event on the jumped
... because it bubbles it will still trigger the parent tspan's
animation
NH: no it would be blue?
... when you go from frogs/in to jumped, you get focus out, so it
will be blue
ED: it would be blue for an instant
NH: but this is the same animation time
... when there are two events at the same time, the document order
determines precedence
... so the blue set is the one that is applied
ED: it's not how we do it currently
... bitflash passes at least
CM: using the mouse to change the focus in batik results in the
frogs/in staying blue
... i do remember in SMIL about the document order determining
precedence when multiple animations start at the same time
<scribe> ACTION: Niklas to send more information with links to SMIL
spec supporting the fact that it should be blue [recorded in
[19]http://www.w3.org/2008/09/25-svg-minutes.html#action02]
<trackbot> Created ACTION-2215 - Send more information with links to
SMIL spec supporting the fact that it should be blue [on Niklas
Hagelroth - due 2008-10-02].
AG: will we take the test back to unapproved?
ED: probably good to get it reviewed again
AG: i don't think there was any description to begin with, so i
added it based on what opera/bitflash did
ED: we'll come back to it when ACTION-2215 is finished
... next is udom-svg-228-t.svg
<ed_>
[20]http://dev.w3.org/SVG/profiles/1.2T/test/svg/udom-svg-228-t.svg
[20] http://dev.w3.org/SVG/profiles/1.2T/test/svg/udom-svg-228-t.svg
NH: i think it should have "url()" around it
ED: i agree
<ed_> [21]http://www.w3.org/TR/SVGMobile12/interact.html#navigation
[21] http://www.w3.org/TR/SVGMobile12/interact.html#navigation
NH: i'll change it
<scribe> ACTION: Niklas to fix udom-svg-228-t.svg [recorded in
[22]http://www.w3.org/2008/09/25-svg-minutes.html#action03]
<trackbot> Created ACTION-2216 - Fix udom-svg-228-t.svg [on Niklas
Hagelroth - due 2008-10-02].
ED: next is struct-use-207-t.svg
NH: this is just using an invalid colour keyword
DS: did i make this one?
ED: looks like an SVG 1.1 one
... change it to white?
NH: yes
<scribe> ACTION: Niklas to change ghostwhite to white in
test/images/svgRef13.svg [recorded in
[23]http://www.w3.org/2008/09/25-svg-minutes.html#action04]
<trackbot> Created ACTION-2217 - Change ghostwhite to white in
test/images/svgRef13.svg [on Niklas Hagelroth - due 2008-10-02].
ED: next is udom-svg-220-t.svg
<ed_>
[24]http://dev.w3.org/SVG/profiles/1.2T/test/svg/udom-svg-220-t.svg
[24] http://dev.w3.org/SVG/profiles/1.2T/test/svg/udom-svg-220-t.svg
CM: I probably meant to put a .split(' ') on the end of that string
there
... to make it a list
<scribe> ACTION: Cameron to fix the set() call in udom-svg-220-t
[recorded in
[25]http://www.w3.org/2008/09/25-svg-minutes.html#action05]
<trackbot> Created ACTION-2218 - Fix the set() call in
udom-svg-220-t [on Cameron McCormack - due 2008-10-02].
ED: next is coords-constr-202-t.svg
<ed_>
[26]http://dev.w3.org/SVG/profiles/1.2T/test/svg/coords-constr-202-t
.svg
[26] http://dev.w3.org/SVG/profiles/1.2T/test/svg/coords-constr-202-t.svg
NH: on row 58
ED: yes i agree
... either put an xlink:href to the root element, or move it
NH: can we move it outside the test-body-content?
ED: i think it's ok, some of the tests have content outside that
element
... but might be clearer if we use xlink:href
<scribe> ACTION: Niklas to add an xlink:href to the animate element
in coords-constr-202-t [recorded in
[27]http://www.w3.org/2008/09/25-svg-minutes.html#action06]
<trackbot> Created ACTION-2219 - Add an xlink:href to the animate
element in coords-constr-202-t [on Niklas Hagelroth - due
2008-10-02].
ED: next is udom-svgcolor-201-t.svg
NH: i'm not sure about this one
ED: i disagree with your conclusion, since they're not said to be
readonly
NH: are they supposed to be live?
ED: does the test require it to be live?
... it's creating a color then setting some values on it
... it doesn't need to be live to pass the test, and i don't think
it should be live either
... but they should be writable
... ok with leaving it as is?
NH: yes
ED: last one interact-event-201
NH: just a minor error
ED: should just get rid of the nav-index
<scribe> ACTION: Niklas to remove the nav-index in
interact-event-201-t [recorded in
[28]http://www.w3.org/2008/09/25-svg-minutes.html#action07]
<trackbot> Created ACTION-2220 - Remove the nav-index in
interact-event-201-t [on Niklas Hagelroth - due 2008-10-02].
<ed_>
[29]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/034
6.html
[29] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0346.html
ED: i sent some comments as well, we could go through some of the
important ones
... text-area-206
<ed_>
[30]http://dev.w3.org/SVG/profiles/1.2T/test/svg/text-area-206-t.svg
[30] http://dev.w3.org/SVG/profiles/1.2T/test/svg/text-area-206-t.svg
ED: does ikivo put the textArea contents on the blue lines?
NH: no not on the lines
ED: slightly overlapping?
NH: yes
ED: i think the problem with the test is that the font was changed
but the test wasn't updated
... should have a smaller font size for the textArea
... how about bitflash?
LM: currently the text is on the blue lines in all cases
... how far off is it in other implementations?
ED: quite far, half the line
NH: i don't think you can count on our interpretation, since we
don't use the right font
ED: could we move it back to review, and i'll give a proposal for
what i think is a good change?
AG: it looks like the font size hasn't changed in the test
... so maybe just move it back to review
ED: i can come up with a fix that i think would be ok, and we can
discuss it
<scribe> ACTION: Erik to send comments about text-area-206 to the
list for review [recorded in
[31]http://www.w3.org/2008/09/25-svg-minutes.html#action08]
<trackbot> Created ACTION-2221 - Send comments about text-area-206
to the list for review [on Erik Dahlström - due 2008-10-02].
<ed_>
[32]http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-svg-204-t.sv
g
[32] http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-svg-204-t.svg
ED: next is struct-svg-204-t.svg
... the problem with this test is that it's testing a negative value
for width/height on the svg element
... shouldn't render anything. opera doesn't if it's standalone, but
if you use it in an <object> like in the harness, it overrides those
and actually renders it.
... this is supported by the spec. maybe we could tweak the pass
criteria?
... e.g. by saying you should open it standalone
... i'd be happy to take an action to add some pass criteria for the
test
<scribe> ACTION: Erik to propose some pass criteria for
struct-svg-204-t [recorded in
[33]http://www.w3.org/2008/09/25-svg-minutes.html#action09]
<trackbot> Created ACTION-2222 - Propose some pass criteria for
struct-svg-204-t [on Erik Dahlström - due 2008-10-02].
<ed_> linking-refs-203-t.svg
<ed_>
[34]http://dev.w3.org/SVG/profiles/1.2T/test/svg/linking-refs-203-t.
svg
[34] http://dev.w3.org/SVG/profiles/1.2T/test/svg/linking-refs-203-t.svg
ED: here the test is requiring the alphabet a-j in a textarea should
be broken into two lines
... but we don't mandate breaking of words in the spec
... so it'd be good if that was split into two words
AG: put it in the content so it does break?
ED: yes
... the second thing about the test is that the bottom right-most
subtest is assuming that <use> renders if there was a circular
reference
... and i'm not sure that it's possible to make a hard requirement
on what's rendered in those cases
... it'd have to be a bit more loose in the pass criteria
AG: it can't really test for that i guess
... we do have circular reference tests
ED: one simple way to resolve this is to remove that subtest, since
we have other tests for it
AG: i'd be happy with removing that bottom right-most subtest
ED: i'd be ok with making those changes as well
AG: this doesn't test anything the others don't?
ED: no i don't think so
LM: we're happy with that
<scribe> ACTION: Erik to remove that bottomright subtest from
linking-refs-203 [recorded in
[35]http://www.w3.org/2008/09/25-svg-minutes.html#action10]
<trackbot> Created ACTION-2223 - Remove that bottomright subtest
from linking-refs-203 [on Erik Dahlström - due 2008-10-02].
<ed_>
[36]http://dev.w3.org/SVG/profiles/1.2T/test/svg/interact-event-201-
t.svg
[36] http://dev.w3.org/SVG/profiles/1.2T/test/svg/interact-event-201-t.svg
ED: interact-event-201, i believe it's listening for the wrong event
... the test is adding listeners for "focusin" and "focusout", but
the events are named "DOMFocusIn" and "DOMFocusOut"
... it's only in the animation begin/end attributes that you can use
those former names
CM: so focusin/focusout are special keywords in timing specifiers?
<ed_> [37]http://www.w3.org/TR/SVGMobile12/interact.html#SVGEvents
[37] http://www.w3.org/TR/SVGMobile12/interact.html#SVGEvents
ED: the events table gives both the event type and the animation
event name, which is different
CM: why do we use a different name?
ED: good question
... i would guess historical reasons, it was in 1.1
AG: the change to the test isn't that drastic
(anthony fixes it now)
ED: udom-glob-201, i think we should remove it
... this tests the GlobalException interface that was removed with
the last publication
NH: i agree
(anthony removes udom-glob-201)
last call comments
<ed_> [38]http://www.w3.org/Graphics/SVG/WG/track/products/11
[38] http://www.w3.org/Graphics/SVG/WG/track/products/11
ED: any that we can close?
(doesn't seem to be)
ISSUE-2065?
<trackbot> ISSUE-2065 -- Text selection - but what about Find Text ?
-- RAISED
<trackbot> [39]http://www.w3.org/Graphics/SVG/WG/track/issues/2065
[39] http://www.w3.org/Graphics/SVG/WG/track/issues/2065
ED: jeff suggests that the spec recommends that browser that support
searching for text in the page that it searches through svg text
... would just be a suggestion
DS: commented a bit in a mozilla bug a while ago
<scribe> ACTION: Doug to propose some wording to suggest that
searching for text should search through SVG text elements [recorded
in [40]http://www.w3.org/2008/09/25-svg-minutes.html#action11]
<trackbot> Created ACTION-2224 - Propose some wording to suggest
that searching for text should search through SVG text elements [on
Doug Schepers - due 2008-10-02].
DS: should look for text that is embedded or inline, and it should
scroll/pan the viewport such that it shows and highlights the text
that is found
... kinda works in safai for examples that are embedded, but not as
well for those that are standalone svg
ED: so even if you have some text outside the viewport does safari
pan the viewport?
DS: no it doesn't
... i'd only make it a recommendation
ED: there might be differences in UAs, so wouldn't be good to
mandate, but suggestion is good
... it'd be useful to pan to the text, but exactly where it would
position it i'm not sure we should say
DS: as long as it's visible
... maybe the entire text run should be centered
... it should probably operate on the element level, so the whole
element is centered
... i'll work something up
ISSUE-2066?
<trackbot> ISSUE-2066 -- datatype (5.10.1) -- RAISED
<trackbot> [41]http://www.w3.org/Graphics/SVG/WG/track/issues/2066
[41] http://www.w3.org/Graphics/SVG/WG/track/issues/2066
CM: you already replied and added some clarifications, yes?
DS: i did put some prose in yes
<scribe> ACTION: Doug Clarify the metadata attributes [recorded in
[42]http://www.w3.org/2008/09/25-svg-minutes.html#action12]
<trackbot> Created ACTION-2225 - Clarify the metadata attributes [on
Doug Schepers - due 2008-10-02].
<ed_>
[43]http://dev.w3.org/SVG/profiles/1.2T/publish/struct.html#Datatype
Attribute
[43] http://dev.w3.org/SVG/profiles/1.2T/publish/struct.html#DatatypeAttribute
ED: there's some new wording in cvs i see
ISSUE-2068?
<trackbot> ISSUE-2068 -- focusHighlight must be inheritable --
RAISED
<trackbot> [44]http://www.w3.org/Graphics/SVG/WG/track/issues/2068
[44] http://www.w3.org/Graphics/SVG/WG/track/issues/2068
ED: so focusHighlight is an attribute, not a property
DS: and attributes don't inherit?
ED: some of them do, but it's different
DS: how can i tell if it's inheritable? in the attribute table?
AE: it's usually in the definition of each attribute/property
CM: it does have it in the definition for properties, but i'm not
sure for attributes
<shepazu>
[45]http://dev.w3.org/SVG/profiles/1.2T/publish/interact.html#FocusH
ighlight
[45] http://dev.w3.org/SVG/profiles/1.2T/publish/interact.html#FocusHighlight
DS: doesn't say if it's inherited, just animatable
... it would be better as a property rather than attribute
ED: i'm wondering if there's something in CSS already that does the
same
... there is the 'outline' property for example
DS: but it wouldn't conflict, right?
... if we made it a property it wouldn't conflict, since there's no
CSS property 'focusHighlight'
ED: but then should would use a dash instead of a capital H?
DS: should be...
ED: it would be hard to change for us at this point
NH: for us too
DS: we could introduce, needn't be in 1.2T, an equivalent property
focus-highlight
... and reexamine all of this stuff in light of CSS
ED: that would make sense to revisit it in Core 2
... in the meantime i hope there's a bugfix that will satisfy him,
which will be not to draw borders when you click on elements, only
when you keyboard navigate
... i think the complaint is about those blue highlights showing on
everything you click on
... it is annoying sometimes
... otoh you really want the highlights there when you're doing
keyboard navigation
DS: he had that concern, but jonathan chetwynd has the opposite
... the commentor would have to change his content, but it shouldn't
be hard to change with a regex for example
... or could we make the attribute inheritable?
ED: i think it's clear
DS: because it's an attribute?
ED: yes, and because it doesn't have 'inherit' as a value
NH: but if you click an element it shouldn't focus by default,
should it?
... our interpretation is that it shouldn't
... then you wouldn't get the highlight when clicking
CM: batik is doing focus on mouseover
... that sends the DOMFocusIn event
ED: still need to send a reply
... do we agree that we don't change it now, but revisit it for
Core2?
(yes)
DS: could change the behaviour in opera depending on the document
version?
ED: can't change it for already released 9.5
RESOLUTION: we don't make a change to focusHighlight, but we'll
revisit it for Core 2.0
<scribe> ACTION: Doug to reply to Chris to state that we won't
change focusHighlight [recorded in
[46]http://www.w3.org/2008/09/25-svg-minutes.html#action13]
<trackbot> Created ACTION-2226 - Reply to Chris to state that we
won't change focusHighlight [on Doug Schepers - due 2008-10-02].
ED: the changed focus highlight behaviour should be in opera's 9.6
release
DS: didn't we sort of say that it should only be on keyboard? or is
it also on mouse?
... we could clarify that it is for keyboard navigation and not
keyboard navigation
AE: that's an interesting change, because i think bitflash does
change focus on click, and there's content that relies on that
... it's ambiguous in the DOM Events spec about focussing on click
ED: the default value is 'auto' anyway, so the UA can still choose
not to draw highlights
DS: we agree that it does need to be clarified in Core
AE: and it's unrelated to focusHighlight, it's focus in general
ED: he also comments on the focusable attribute
... since that's not inheritable
... but inheriting focusable would be strange i think
AE: yes
... it'd be hard to use content
DS: why strange?
AE: it'd be hard to debug, you get elements focused that you don't
expect etc.
NH: on group elements you get all of the elements within the group
separately focusable
... which usually isn't what you want
... if you have a group element with ten circles in it, and you set
focusable='true' on the group, then in the focus ring you'd have all
the ten circles
DS: that makes sense from an accessibility standpoint, someone would
want to focus on the group, then go in and drill down and focus on
each individual one
... first you'd focus the group as a whole, then you'd go in and
focus each individual item
AE: in a typical gui you might have a matrix of buttons, typically
you want the toplevel group to be focussed, and each button might
have 20 or 50 elements under there
... and you don't want all of those focusable
... in that use case having all of them inheritable would be wrong
... you could put another group under that group and say
focusable='false' to get around it
... in typical use cases you don't want to focus each of the child
elements
ED: i think it's more common to focus as a whole rather than
individually
<ed_> It's a more common usecase to want few items focusable, rather
than many
<ed_> probably not
<ed_> although mabe thursday?
<ed_> we did say we'd allocate one day for a WG meeting
<anthony> I might not be able to make Thursday evening next week now
<anthony> I'll be flying up north next thursday
Summary of Action Items
[NEW] ACTION: Cameron remove the scope chain wording from the
<handler> section [recorded in
[47]http://www.w3.org/2008/09/25-svg-minutes.html#action01]
[NEW] ACTION: Cameron to fix the set() call in udom-svg-220-t
[recorded in
[48]http://www.w3.org/2008/09/25-svg-minutes.html#action05]
[NEW] ACTION: Doug Clarify the metadata attributes [recorded in
[49]http://www.w3.org/2008/09/25-svg-minutes.html#action12]
[NEW] ACTION: Doug to propose some wording to suggest that searching
for text should search through SVG text elements [recorded in
[50]http://www.w3.org/2008/09/25-svg-minutes.html#action11]
[NEW] ACTION: Doug to reply to Chris to state that we won't change
focusHighlight [recorded in
[51]http://www.w3.org/2008/09/25-svg-minutes.html#action13]
[NEW] ACTION: Erik to propose some pass criteria for
struct-svg-204-t [recorded in
[52]http://www.w3.org/2008/09/25-svg-minutes.html#action09]
[NEW] ACTION: Erik to remove that bottomright subtest from
linking-refs-203 [recorded in
[53]http://www.w3.org/2008/09/25-svg-minutes.html#action10]
[NEW] ACTION: Erik to send comments about text-area-206 to the list
for review [recorded in
[54]http://www.w3.org/2008/09/25-svg-minutes.html#action08]
[NEW] ACTION: Niklas to add an xlink:href to the animate element in
coords-constr-202-t [recorded in
[55]http://www.w3.org/2008/09/25-svg-minutes.html#action06]
[NEW] ACTION: Niklas to change ghostwhite to white in
test/images/svgRef13.svg [recorded in
[56]http://www.w3.org/2008/09/25-svg-minutes.html#action04]
[NEW] ACTION: Niklas to fix udom-svg-228-t.svg [recorded in
[57]http://www.w3.org/2008/09/25-svg-minutes.html#action03]
[NEW] ACTION: Niklas to remove the nav-index in interact-event-201-t
[recorded in
[58]http://www.w3.org/2008/09/25-svg-minutes.html#action07]
[NEW] ACTION: Niklas to send more information with links to SMIL
spec supporting the fact that it should be blue [recorded in
[59]http://www.w3.org/2008/09/25-svg-minutes.html#action02]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [60]scribe.perl version 1.133
([61]CVS log)
$Date: 2008/09/25 12:05:58 $
_________________________________________________________
[60] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[61] 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 [62]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[62] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/issues/issue/
Succeeded: s/changing/closing/
Succeeded: s/defintion/definition/
Succeeded: s/send/sends/
Found Scribe: Cameron
Found ScribeNick: heycam
Default Present: NH, +1.613.445.aaaa, anthony, [IPcaller], heycam, ed_,
Doug_Schepers, aemmons
Present: NH +1.613.445.aaaa anthony [IPcaller] heycam ed_ Doug_Schepers
aemmons
Agenda: [63]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSe
p/0353.html
[63] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0353.html
WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth
Found Date: 25 Sep 2008
Guessing minutes URL: [64]http://www.w3.org/2008/09/25-svg-minutes.html
People with action items: cameron doug erik niklas
[64] http://www.w3.org/2008/09/25-svg-minutes.html
WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
End of [65]scribe.perl diagnostic output]
[65] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 25 September 2008 12:10:18 UTC