IRC log of svg on 2008-09-25

Timestamps are in UTC.

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