10:31:03 <RRSAgent> RRSAgent has joined #svg
10:31:03 <RRSAgent> logging to http://www.w3.org/2008/09/25-svg-irc
10:31:05 <trackbot> RRSAgent, make logs public
10:31:05 <Zakim> Zakim has joined #svg
10:31:07 <trackbot> Zakim, this will be GA_SVGWG
10:31:07 <Zakim> ok, trackbot, I see GA_SVGWG()6:30AM already started
10:31:08 <trackbot> Meeting: SVG Working Group Teleconference
10:31:08 <trackbot> Date: 25 September 2008
10:33:05 <lmartine> lmartine has joined #svg
10:33:12 <Zakim> + +1.613.445.aaaa
10:33:44 <Zakim> +??P2
10:34:02 <anthony> Zakim, ??P2 is me
10:34:02 <Zakim> +anthony; got it
10:34:21 <anthony> Zakim,  +1.6 is NH
10:34:21 <Zakim> +NH; got it
10:35:31 <Zakim> +[IPcaller]
10:35:36 <heycam> Zakim, +[ is me
10:35:36 <Zakim> sorry, heycam, I do not recognize a party named '+['
10:35:43 <heycam> Zakim, [I is me
10:35:43 <Zakim> +heycam; got it
10:35:59 <heycam> Zakim, who is here?
10:35:59 <Zakim> On the phone I see NH, NH.a, anthony, heycam
10:36:00 <Zakim> On IRC I see lmartine, Zakim, RRSAgent, NH, heycam, ed_work, anthony, shepazu, trackbot
10:37:26 <ed_> ed_ has joined #svg
10:37:49 <Zakim> +??P4
10:37:56 <ed_> Zakim, ??P4 is me
10:37:56 <Zakim> +ed_; got it
10:38:18 <ed_> Zakim, who's here?
10:38:18 <Zakim> On the phone I see NH, NH.a, anthony, heycam, ed_
10:38:19 <Zakim> On IRC I see ed_, lmartine, Zakim, RRSAgent, NH, heycam, ed_work, anthony, shepazu, trackbot
10:38:45 <heycam> Scribe: Cameron
10:38:47 <heycam> ScribeNick: heycam
10:38:53 <ed_> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0353.html
10:39:15 <heycam> Topic: Scope chain modification for <handler>s
10:40:52 <heycam> CM: none of the implementations i tested put the event target in the scope chain
10:41:12 <heycam> ED: there was a reply on the public list
10:41:23 <heycam> http://lists.w3.org/Archives/Public/www-svg/2008Sep/0111.html
10:41:40 <heycam> CM: that mail's on a related issues
10:41:43 <heycam> s/issues/issue/
10:42:28 <heycam> CM: erik thought it might be useful to have
10:42:37 <heycam> ED: that's the only objection i could have to removing it
10:42:41 <heycam> ED: don't have a strong opinion
10:42:49 <heycam> ED: it'd be easier for me if we removed it, then we wouldn't have to change our implementation
10:43:28 <heycam> CM: does the ikivo player add the event target into the scope chain when running handlers?
10:43:57 <heycam> NH: we also do not do that, so we're the same as opera and bitflash
10:44:33 <heycam> CM: since it doesn't happen in HTML, and since all the implementations agree, i think we should remove it
10:44:46 <heycam> ED: any objections to removing it?
10:44:52 <heycam> (silence)
10:45:05 <heycam> RESOLUTION: Remove the scope chain wording from the spec
10:45:22 <heycam> ACTION: Cameron remove the scope chain wording from the <handler> section
10:45:23 <trackbot> Created ACTION-2214 - Remove the scope chain wording from the <handler> section [on Cameron McCormack - due 2008-10-02].
10:46:28 <heycam> Topic: review of some proposed changes
10:46:33 <anthony> http://dev.w3.org/SVG/profiles/1.2T/master/intro.html#TermRenderingTree
10:46:58 <ed_> http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/intro.html.diff?r1=1.122&r2=1.123&f=h
10:47:03 <heycam> AG: the addition is in the last sentence of that definition
10:47:19 <heycam> AG: i put that in so that it implies <audio> also sits in the rendering tree
10:47:45 <heycam> AG: it was a clarification, not changing conformance
10:47:50 <heycam> AG: the other change was in the painting chapter
10:48:11 <anthony> http://dev.w3.org/SVG/profiles/1.2T/master/painting.html#DisplayProperty
10:48:14 <ed_> http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/painting.html.diff?r1=1.118&r2=1.119&f=h
10:48:43 <heycam> AG: I added in the media elements to the list of elements the property applies to
10:48:52 <heycam> AG: and that pulls in graphics elements and the <audio> element
10:49:09 <heycam> AG: also enhanced the wording to talk about the audibility of the <audio> element, and what each value does to it
10:49:41 <heycam> ED: what was the action?
10:50:09 <anthony> ACTION-2207?
10:50:09 <trackbot> ACTION-2207 -- Anthony Grasso to review the wording of visibility relating to audio -- due 2008-09-30 -- PENDINGREVIEW
10:50:09 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2207
10:51:51 <heycam> CM: the paragraph starting "Depending on the value of property 'pointer-events'" doesn't really apply to <audio>
10:52:57 <heycam> CM: are <video> and <animation> media elements?
10:52:59 <heycam> ED: yes
10:53:10 <heycam> AG: i'll remove mention of media elements from that sentence
10:53:12 <ed_> <video> and <animation> are also graphics elements
10:53:21 <ed_> as well as being media elements
10:55:23 <heycam> ED: pending that last change i'd be ok with changing the action
10:55:27 <heycam> s/changing/closing/
10:56:04 <Zakim> +Doug_Schepers
10:56:06 <heycam> AG: i raised an issue on Core 2.0 on this issue too, since we should be able to control audio separately from video
10:56:23 <heycam> Topic: Test suite comments
10:56:33 <ed_> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0326.html
10:57:06 <heycam> NH: starting from interact-focus-208
10:57:35 <ed_> http://dev.w3.org/SVG/profiles/1.2T/test/svg/interact-focus-208-t.svg
10:58:32 <heycam> NH: the test description is wrong i think
10:59:48 <heycam> NH: the test also says that "jumped" should be focussed at the same time as "frogs" and "in"
11:00:11 <heycam> ED: I agree it's not fully clear
11:00:27 <heycam> ED: for the first paragraph i agree with you that it should say something like you say (about "frogs" and "in" before "jumped")
11:00:32 <heycam> ED: i agree "in" is not focusable by itself
11:01:29 <heycam> ED: "frogs" "in" is in one <tspan>, so they must be focussed together
11:01:36 <heycam> NH: and when after frogs you get jumped
11:01:48 <heycam> NH: the test says when jumped is focussed, frogs and in should be focussed
11:01:51 <heycam> ED: green, not focussed
11:01:53 <heycam> NH: yes
11:02:05 <heycam> NH: but i don't think that's true, because the animations trigger on focusout and focusin
11:02:47 <heycam> ED: i think it's correct, because the tspan has a focusin listener which will be triggered by the event on the jumped
11:03:00 <heycam> ED: because it bubbles it will still trigger the parent tspan's animation
11:03:04 <heycam> NH: no it would be blue?
11:03:14 <heycam> NH: when you go from frogs/in to jumped, you get focus out, so it will be blue
11:03:32 <heycam> ED: it would be blue for an instant
11:03:35 <heycam> NH: but this is the same animation time
11:03:47 <heycam> NH: when there are two events at the same time, the document order determines precedence
11:03:55 <heycam> NH: so the blue set is the one that is applied
11:04:18 <heycam> ED: it's not how we do it currently
11:04:28 <heycam> ED: bitflash passes at least
11:05:04 <heycam> CM: using the mouse to change the focus in batik results in the frogs/in staying blue
11:05:33 <heycam> CM: i do remember in SMIL about the document order determining precedence when multiple animations start at the same time
11:06:05 <heycam> ACTION: Niklas to send more information with links to SMIL spec supporting the fact that it should be blue
11:06:05 <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].
11:06:26 <heycam> AG: will we take the test back to unapproved?
11:06:37 <heycam> ED: probably good to get it reviewed again
11:06:56 <heycam> AG: i don't think there was any description to begin with, so i added it based on what opera/bitflash did
11:07:12 <stakagi> stakagi has joined #svg
11:07:35 <heycam> ED: we'll come back to it when ACTION-2215 is finished
11:07:44 <heycam> ED: next is udom-svg-228-t.svg
11:07:47 <ed_> http://dev.w3.org/SVG/profiles/1.2T/test/svg/udom-svg-228-t.svg
11:07:48 <stakagi> stakagi has left #svg
11:07:58 <heycam> NH: i think it should have "url()" around it
11:08:15 <heycam> ED: i agree
11:08:19 <ed_> http://www.w3.org/TR/SVGMobile12/interact.html#navigation
11:08:35 <heycam> NH: i'll change it
11:08:53 <heycam> ACTION: Niklas to fix udom-svg-228-t.svg
11:08:53 <trackbot> Created ACTION-2216 - Fix udom-svg-228-t.svg [on Niklas Hagelroth - due 2008-10-02].
11:09:03 <heycam> ED: next is struct-use-207-t.svg
11:09:23 <heycam> NH: this is just using an invalid colour keyword
11:09:30 <heycam> DS: did i make this one?
11:09:34 <heycam> ED: looks like an SVG 1.1 one
11:10:35 <heycam> ED: change it to white?
11:10:36 <heycam> NH: yes
11:10:49 <heycam> ACTION: Niklas to change ghostwhite to white in test/images/svgRef13.svg
11:10:49 <trackbot> Created ACTION-2217 - Change ghostwhite to white in test/images/svgRef13.svg [on Niklas Hagelroth - due 2008-10-02].
11:10:59 <heycam> ED: next is udom-svg-220-t.svg
11:11:01 <ed_> http://dev.w3.org/SVG/profiles/1.2T/test/svg/udom-svg-220-t.svg
11:12:08 <heycam> CM: I probably meant to put a .split(' ') on the end of that string there
11:12:12 <heycam> CM: to make it a list
11:12:30 <heycam> ACTION: Cameron to fix the set() call in udom-svg-220-t
11:12:30 <trackbot> Created ACTION-2218 - Fix the set() call in udom-svg-220-t [on Cameron McCormack - due 2008-10-02].
11:12:38 <heycam> ED: next is coords-constr-202-t.svg
11:12:42 <ed_> http://dev.w3.org/SVG/profiles/1.2T/test/svg/coords-constr-202-t.svg
11:13:12 <heycam> NH: on row 58
11:13:18 <heycam> ED: yes i agree
11:13:23 <heycam> ED: either put an xlink:href to the root element, or move it
11:13:33 <heycam> NH: can we move it outside the test-body-content?
11:13:49 <heycam> ED: i think it's ok, some of the tests have content outside that element
11:13:54 <heycam> ED: but might be clearer if we use xlink:href
11:14:07 <ed_> ed_ has joined #svg
11:14:12 <heycam> ACTION: Niklas to add an xlink:href to the animate element in coords-constr-202-t
11:14:12 <trackbot> Created ACTION-2219 - Add an xlink:href to the animate element in coords-constr-202-t [on Niklas Hagelroth - due 2008-10-02].
11:14:27 <heycam> ED: next is udom-svgcolor-201-t.svg
11:14:41 <heycam> NH: i'm not sure about this one
11:14:45 <heycam> ED: i disagree with your conclusion, since they're not said to be readonly
11:14:53 <heycam> NH: are they supposed to be live?
11:14:57 <heycam> ED: does the test require it to be live?
11:15:18 <heycam> ED: it's creating a color then setting some values on it
11:15:25 <heycam> ED: it doesn't need to be live to pass the test, and i don't think it should be live either
11:15:32 <heycam> ED: but they should be writable
11:15:36 <heycam> ED: ok with leaving it as is?
11:15:37 <heycam> NH: yes
11:15:43 <heycam> ED: last one interact-event-201
11:16:05 <heycam> NH: just a minor error
11:16:10 <heycam> ED: should just get rid of the nav-index
11:16:20 <heycam> ACTION: Niklas to remove the nav-index in interact-event-201-t
11:16:20 <trackbot> Created ACTION-2220 - Remove the nav-index in interact-event-201-t [on Niklas Hagelroth - due 2008-10-02].
11:16:37 <ed_> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0346.html
11:16:43 <heycam> ED: i sent some comments as well, we could go through some of the important ones
11:16:57 <heycam> ED: text-area-206
11:17:03 <ed_> http://dev.w3.org/SVG/profiles/1.2T/test/svg/text-area-206-t.svg
11:17:17 <heycam> ED: does ikivo put the textArea contents on the blue lines?
11:17:43 <heycam> NH: no not on the lines
11:17:46 <heycam> ED: slightly overlapping?
11:17:47 <heycam> NH: yes
11:17:56 <heycam> ED: i think the problem with the test is that the font was changed but the test wasn't updated
11:18:01 <heycam> ED: should have a smaller font size for the textArea
11:18:21 <heycam> ED: how about bitflash?
11:18:37 <heycam> LM: currently the text is on the blue lines in all cases
11:18:43 <heycam> LM: how far off is it in other implementations?
11:18:47 <heycam> ED: quite far, half the line
11:19:00 <heycam> NH: i don't think you can count on our interpretation, since we don't use the right font
11:19:19 <heycam> ED: could we move it back to review, and i'll give a proposal for what i think is a good change?
11:20:18 <heycam> AG: it looks like the font size hasn't changed in the test
11:20:28 <heycam> AG: so maybe just move it back to review
11:20:43 <heycam> ED: i can come up with a fix that i think would be ok, and we can discuss it
11:21:21 <heycam> ACTION: Erik to send comments about text-area-206 to the list for review
11:21:21 <trackbot> Created ACTION-2221 - Send comments about text-area-206 to the list for review [on Erik Dahlström - due 2008-10-02].
11:21:33 <ed_> http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-svg-204-t.svg
11:21:39 <heycam> ED: next is struct-svg-204-t.svg
11:21:52 <heycam> ED: the problem with this test is that it's testing a negative value for width/height on the svg element
11:22:13 <heycam> ED: 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.
11:22:29 <heycam> ED: this is supported by the spec.  maybe we could tweak the pass criteria?
11:22:34 <heycam> ED: e.g. by saying you should open it standalone
11:23:20 <heycam> ED: i'd be happy to take an action to add some pass criteria for the test
11:23:34 <heycam> ACTION: Erik to propose some pass criteria for struct-svg-204-t
11:23:34 <trackbot> Created ACTION-2222 - Propose some pass criteria for struct-svg-204-t [on Erik Dahlström - due 2008-10-02].
11:23:39 <ed_> linking-refs-203-t.svg
11:23:46 <ed_> http://dev.w3.org/SVG/profiles/1.2T/test/svg/linking-refs-203-t.svg
11:24:06 <heycam> ED: here the test is requiring the alphabet a-j in a textarea should be broken into two lines
11:24:14 <heycam> ED: but we don't mandate breaking of words in the spec
11:24:20 <heycam> ED: so it'd be good if that was split into two words
11:24:48 <heycam> AG: put it in the content so it does break?
11:24:49 <heycam> ED: yes
11:25:10 <heycam> ED: the second thing about the test is that the bottom right-most subtest is assuming that <use> renders if there was a circular reference
11:25:22 <heycam> ED: and i'm not sure that it's possible to make a hard requirement on what's rendered in those cases
11:25:30 <heycam> ED: it'd have to be a bit more loose in the pass criteria
11:25:39 <heycam> AG: it can't really test for that i guess
11:25:48 <heycam> AG: we do have circular reference tests
11:25:55 <heycam> ED: one simple way to resolve this is to remove that subtest, since we have other tests for it
11:26:02 <heycam> AG: i'd be happy with removing that bottom right-most subtest
11:26:20 <heycam> ED: i'd be ok with making those changes as well
11:26:38 <heycam> AG: this doesn't test anything the others don't?
11:26:40 <heycam> ED: no i don't think so
11:27:11 <heycam> LM: we're happy with that
11:27:22 <heycam> ACTION: Erik to remove that bottomright subtest from linking-refs-203
11:27:22 <trackbot> Created ACTION-2223 - Remove that bottomright subtest from linking-refs-203 [on Erik Dahlström - due 2008-10-02].
11:27:32 <ed_> http://dev.w3.org/SVG/profiles/1.2T/test/svg/interact-event-201-t.svg
11:27:33 <heycam> ED: interact-event-201, i believe it's listening for the wrong event
11:27:38 <aemmons> aemmons has joined #svg
11:28:09 <Zakim> +??P16
11:28:15 <heycam> ED: the test is adding listeners for "focusin" and "focusout", but the events are named "DOMFocusIn" and "DOMFocusOut"
11:28:21 <aemmons> zakim, ??p16 is me
11:28:21 <Zakim> +aemmons; got it
11:28:24 <heycam> ED: it's only in the animation begin/end attributes that you can use those former names
11:28:54 <heycam> CM: so focusin/focusout are special keywords in timing specifiers?
11:28:55 <ed_> http://www.w3.org/TR/SVGMobile12/interact.html#SVGEvents
11:29:13 <heycam> ED: the events table gives both the event type and the animation event name, which is different
11:29:26 <heycam> CM: why do we use a different name?
11:29:28 <heycam> ED: good question
11:29:36 <heycam> ED: i would guess historical reasons, it was in 1.1
11:29:48 <heycam> AG: the change to the test isn't that drastic
11:30:08 <heycam> (anthony fixes it now)
11:30:38 <heycam> ED: udom-glob-201, i think we should remove it
11:30:46 <heycam> ED: this tests the GlobalException interface that was removed with the last publication
11:31:00 <heycam> NH: i agree
11:31:20 <heycam> (anthony removes udom-glob-201)
11:32:07 <heycam> Topic: last call comments
11:32:16 <ed_> http://www.w3.org/Graphics/SVG/WG/track/products/11
11:32:33 <heycam> ED: any that we can close?
11:32:55 <heycam> (doesn't seem to be)
11:33:22 <heycam> ISSUE-2065?
11:33:22 <trackbot> ISSUE-2065 -- Text selection - but what about Find Text ? -- RAISED
11:33:22 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2065
11:34:11 <heycam> ED: jeff suggests that the spec recommends that browser that support searching for text in the page that it searches through svg text
11:34:17 <heycam> ED: would just be a suggestion
11:34:25 <heycam> DS: commented a bit in a mozilla bug a while ago
11:34:44 <heycam> ACTION: Doug to propose some wording to suggest that searching for text should search through SVG text elements
11:34:44 <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].
11:35:05 <heycam> 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
11:35:23 <heycam> DS: kinda works in safai for examples that are embedded, but not as well for those that are standalone svg
11:35:34 <heycam> ED: so even if you have some text outside the viewport does safari pan the viewport?
11:35:37 <heycam> DS: no it doesn't
11:35:48 <heycam> DS: i'd only make it a recommendation
11:36:39 <heycam> ED: there might be differences in UAs, so wouldn't be good to mandate, but suggestion is good
11:36:55 <heycam> ED: it'd be useful to pan to the text, but exactly where it would position it i'm not sure we should say
11:37:26 <heycam> DS: as long as it's visible
11:37:34 <heycam> DS: maybe the entire text run should be centered
11:38:43 <heycam> DS: it should probably operate on the element level, so the whole element is centered
11:38:49 <heycam> DS: i'll work something up
11:38:56 <heycam> ISSUE-2066?
11:38:56 <trackbot> ISSUE-2066 -- datatype (5.10.1) -- RAISED
11:38:56 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2066
11:39:58 <heycam> CM: you already replied and added some clarifications, yes?
11:40:03 <heycam> DS: i did put some prose in yes
11:40:25 <heycam> ACTION: Doug Clarify the metadata attributes
11:40:25 <trackbot> Created ACTION-2225 - Clarify the metadata attributes [on Doug Schepers - due 2008-10-02].
11:40:32 <ed_> http://dev.w3.org/SVG/profiles/1.2T/publish/struct.html#DatatypeAttribute
11:40:39 <heycam> ED: there's some new wording in cvs i see
11:40:41 <Zakim> -ed_
11:40:42 <Zakim> -anthony
11:41:06 <Zakim> +??P2
11:41:15 <ed_> Zakim, ??P2 is me
11:41:15 <Zakim> +ed_; got it
11:41:20 <Zakim> +??P4
11:41:33 <anthony> Zakim, ??P4 is me
11:41:33 <Zakim> +anthony; got it
11:42:12 <heycam> ISSUE-2068?
11:42:12 <trackbot> ISSUE-2068 -- focusHighlight must be inheritable -- RAISED
11:42:12 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2068
11:42:48 <heycam> ED: so focusHighlight is an attribute, not a property
11:43:00 <heycam> DS: and attributes don't inherit?
11:43:04 <heycam> ED: some of them do, but it's different
11:43:24 <heycam> DS: how can i tell if it's inheritable?  in the attribute table?
11:43:38 <heycam> AE: it's usually in the definition of each attribute/property
11:44:12 <heycam> CM: it does have it in the defintion for properties, but i'm not sure for attributes
11:44:14 <shepazu> http://dev.w3.org/SVG/profiles/1.2T/publish/interact.html#FocusHighlight
11:44:25 <heycam> s/defintion/definition/
11:44:52 <NH> NH has joined #svg
11:45:30 <heycam> DS: doesn't say if it's inherited, just animatable
11:46:09 <heycam> DS: it would be better as a property rather than attribute
11:46:18 <heycam> ED: i'm wondering if there's something in CSS already that does the same
11:46:54 <heycam> ED: there is the 'outline' property for example
11:47:01 <heycam> DS: but it wouldn't conflict, right?
11:47:23 <heycam> DS: if we made it a property it wouldn't conflict, since there's no CSS property 'focusHighlight'
11:47:29 <heycam> ED: but then should would use a dash instead of a capital H?
11:47:34 <heycam> DS: should be...
11:47:44 <heycam> ED: it would be hard to change for us at this point
11:47:48 <heycam> NH: for us too
11:48:07 <heycam> DS: we could introduce, needn't be in 1.2T, an equivalent property focus-highlight
11:48:15 <heycam> DS: and reexamine all of this stuff in light of CSS
11:48:21 <heycam> ED: that would make sense to revisit it in Core 2
11:48:53 <heycam> ED: 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
11:49:05 <heycam> ED: i think the complaint is about those blue highlights showing on everything you click on
11:49:07 <heycam> ED: it is annoying sometimes
11:49:18 <heycam> ED: otoh you really want the highlights there when you're doing keyboard navigation
11:49:29 <heycam> DS: he had that concern, but jonathan chetwynd has the opposite
11:50:14 <heycam> DS: the commentor would have to change his content, but it shouldn't be hard to change with a regex for example
11:50:33 <heycam> DS: or could we make the attribute inheritable?
11:50:38 <heycam> ED: i think it's clear
11:50:39 <heycam> DS: because it's an attribute?
11:50:48 <heycam> ED: yes, and because it doesn't have 'inherit' as a value
11:50:57 <heycam> NH: but if you click an element it shouldn't focus by default, should it?
11:51:02 <heycam> NH: our interpretation is that it shouldn't
11:51:08 <heycam> NH: then you wouldn't get the highlight when clicking
11:51:24 <heycam> CM: batik is doing focus on mouseover
11:51:32 <heycam> CM: that send the DOMFocusIn event
11:51:35 <heycam> s/send/sends/
11:52:01 <heycam> ED: still need to send a reply
11:52:16 <heycam> ED: do we agree that we don't change it now, but revisit it for Core2?
11:52:22 <heycam> (yes)
11:53:06 <heycam> DS: could change the behaviour in opera depending on the document version?
11:53:13 <heycam> ED: can't change it for already released 9.5
11:54:22 <heycam> RESOLUTION: we don't make a change to focusHighlight, but we'll revisit it for Core 2.0
11:54:36 <heycam> ACTION: Doug to reply to Chris to state that we won't change focusHighlight
11:54:36 <trackbot> Created ACTION-2226 - Reply to Chris to state that we won't change focusHighlight [on Doug Schepers - due 2008-10-02].
11:54:47 <heycam> ED: the changed focus highlight behaviour should be in opera's 9.6 release
11:55:06 <heycam> DS: didn't we sort of say that it should only be on keyboard?  or is it also on mouse?
11:55:24 <heycam> DS: we could clarify that it is for keyboard navigation and not keyboard navigation
11:55:39 <heycam> AE: that's an interesting change, because i think bitflash does change focus on click, and there's content that relies on that
11:55:47 <heycam> AE: it's ambiguous in the DOM Events spec about focussing on click
11:56:02 <heycam> ED: the default value is 'auto' anyway, so the UA can still choose not to draw highlights
11:56:21 <heycam> DS: we agree that it does need to be clarified in Core
11:56:42 <heycam> AE: and it's unrelated to focusHighlight, it's focus in general
11:57:17 <heycam> ED: he also comments on the focusable attribute
11:57:26 <heycam> ED: since that's not inheritable
11:57:37 <heycam> ED: but inheriting focusable would be strange i think
11:57:37 <heycam> AE: yes
11:57:43 <heycam> AE: it'd be hard to use content
11:57:47 <heycam> DS: why strange?
11:58:29 <heycam> AE: it'd be hard to debug, you get elements focused that you don't expect etc.
11:58:40 <heycam> NH: on group elements you get all of the elements within the group separately focusable
11:58:44 <heycam> NH: which usually isn't what you want
11:59:04 <heycam> NH: 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
11:59:34 <heycam> 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
11:59:56 <heycam> DS: first you'd focus the group as a whole, then you'd go in and focus each individual item
12:00:26 <heycam> 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
12:00:30 <heycam> AE: and you don't want all of those focusable
12:00:39 <heycam> AE: in that use case having all of them inheritable would be wrong
12:00:48 <heycam> AE: you could put another group under that group and say focusable='false' to get around it
12:01:29 <heycam> AE: in typical use cases you don't want to focus each of the child elements
12:01:40 <heycam> ED: i think it's more common to focus as a whole rather than individually
12:02:10 <ed_> It's a more common usecase to want few items focusable, rather than many
12:02:46 <Zakim> -NH
12:02:47 <Zakim> -aemmons
12:02:48 <Zakim> -ed_
12:02:50 <Zakim> -heycam
12:02:51 <Zakim> -Doug_Schepers
12:02:54 <Zakim> -anthony
12:02:56 <Zakim> -NH.a
12:02:58 <Zakim> GA_SVGWG()6:30AM has ended
12:02:59 <Zakim> Attendees were NH, +1.613.445.aaaa, anthony, [IPcaller], heycam, ed_, Doug_Schepers, aemmons
12:03:51 <ed_> probably not
12:04:00 <anthony> Zakim, bye
12:04:00 <Zakim> Zakim has left #svg
12:04:04 <ed_> although mabe thursday?
12:04:31 <anthony> RRSAgent, make minutes
12:04:31 <RRSAgent> I have made the request to generate http://www.w3.org/2008/09/25-svg-minutes.html anthony
12:04:38 <ed_> we did say we'd allocate one day for a WG meeting
12:05:08 <anthony> I might not be able to make Thursday evening next week now
12:05:50 <anthony> I'll be flying up north next thursday
12:05:53 <heycam> RRSAgent, make minutes
12:05:53 <RRSAgent> I have made the request to generate http://www.w3.org/2008/09/25-svg-minutes.html heycam
12:06:08 <anthony> yeah take the link I made
12:06:21 <anthony> doesn't have the conversation that ED and I were having in IRC
12:06:25 <shepazu> we need to change the telcon times soon
12:06:32 <heycam> same link tho, i think it overwrote
12:06:39 <anthony> oh
12:06:52 <anthony> shepazu: Yes I agree
12:06:58 <anthony> that time is already bad for you
12:07:10 <anthony> and once US goes back to regular time
12:07:14 <anthony> it's worse again
12:07:31 <ed_work> oh, right...
12:07:43 <ed_work> time for svgwg/bloodbath again?
12:08:10 <anthony> I guess so
12:08:35 <heycam> when's the tpac?  next week?
12:08:46 <anthony> 18th Oct
12:08:53 <heycam> oh k
12:08:58 <anthony> test fest is next week
12:09:01 <heycam> right
12:09:20 <anthony> heycam is your telcon time selector thing still working?
12:09:27 <heycam> probably
12:09:34 <heycam> shepazu, did the systeam do anything with it?
12:09:34 <ed_work> heycam: could you mail the wg-list with the link for the telcon planner please?
12:09:38 <heycam> ed_work, ok
12:09:49 <heycam> what date are we aiming to choose times for?
12:11:20 <anthony> mmm, not sure
12:11:38 <heycam> shepazu, when does daylight savings end in the US?
12:11:52 <heycam> trackbot, please tell me when daylight savings starts/ends for each of the participants in the WG
12:11:52 <trackbot> Sorry, heycam, I don't understand 'trackbot, please tell me when daylight savings starts/ends for each of the participants in the WG'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
12:11:58 <heycam> :(
12:12:31 <anthony> http://wwp.greenwichmeantime.com/time-zone/rules/usa.htm
12:13:15 <anthony> 2nd Nov is when it ends
12:13:26 <anthony> it's something we could decide at TPAC even
12:13:58 <heycam> i liked the 6:30am starts we aussies used to have (dunno about you anthony)
12:14:06 <heycam> so if that's possible and works for everyone, that'd be nice
12:14:20 <anthony> I prefer those as well
12:14:30 <anthony> I'm usually up by about 6:15 these days anyway
12:14:44 <heycam> anyway we'll be deciding telcon times for northern winter and southern summer
12:14:52 <heycam> regardless of the exact transition times
12:15:10 <anthony> yeah true
12:15:18 <heycam> i'll send it to the member only list
12:16:12 <anthony> anyway I'm off to bed
12:16:16 <heycam> later anthony 
12:16:22 <anthony> later dude
13:42:55 <stakagi> stakagi has joined #svg
13:43:04 <stakagi> stakagi has left #svg