SVG Working Group Teleconference -- 25 Sep 2008

<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

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].

review of some proposed changes

<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

Test suite comments

<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)

last call comments

<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

- DRAFT -

SVG Working Group Teleconference

25 Sep 2008

Attendees

Contents

Scope chain modification for <handler>s

review of some proposed changes

Test suite comments

last call comments

Summary of Action Items

Scribe.perl diagnostic output