See also: IRC log
<trackbot> Date: 25 September 2008
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
CM: none of the implementations i tested put the event target in the scope chain
ED: there was a reply on the public list
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 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].
<anthony> http://dev.w3.org/SVG/profiles/1.2T/master/intro.html#TermRenderingTree
<ed_> 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> http://dev.w3.org/SVG/profiles/1.2T/master/painting.html#DisplayProperty
<ed_> 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> 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
<ed_> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0326.html
NH: starting from interact-focus-208
<ed_> 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 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_> 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_> 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 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 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_> 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 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_> 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 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 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_> 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_> 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 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_> 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 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_> 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 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_> 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_> 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)
<ed_> 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> 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 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> 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 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_> 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> 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> 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 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
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/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: 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: http://www.w3.org/2008/09/25-svg-minutes.html People with action items: cameron doug erik niklas WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]