W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2008

Minutes, September 25, 2008 telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 25 Sep 2008 22:09:23 +1000
To: public-svg-wg@w3.org
Message-ID: <20080925120922.GA24241@arc.mcc.id.au>



      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

25 Sep 2008


      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0353.html

   See also: [3]IRC log

      [3] http://www.w3.org/2008/09/25-svg-irc


          NH, +1.613.445.aaaa, anthony, [IPcaller], heycam, ed_,
          Doug_Schepers, aemmons




     * [4]Topics
         1. [5]Scope chain modification for <handler>s
         2. [6]review of some proposed changes
         3. [7]Test suite comments
         4. [8]last call comments
     * [9]Summary of Action Items

   <trackbot> Date: 25 September 2008

   <scribe> Scribe: Cameron

   <scribe> ScribeNick: heycam

Scope chain modification for <handler>s

   CM: none of the implementations i tested put the event target in the
   scope chain

   ED: there was a reply on the public list


     [10] http://lists.w3.org/Archives/Public/www-svg/2008Sep/0111.html

   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?


   RESOLUTION: Remove the scope chain wording from the spec

   <scribe> ACTION: Cameron remove the scope chain wording from the
   <handler> section [recorded in

   <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


     [12] http://dev.w3.org/SVG/profiles/1.2T/master/intro.html#TermRenderingTree


     [13] http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/intro.html.diff?r1=1.122&r2=1.123&f=h

   AG: the addition is in the last sentence of that definition
   ... i put that in so that it implies <audio> also sits in the
   rendering tree
   ... it was a clarification, not changing conformance
   ... the other change was in the painting chapter


     [14] http://dev.w3.org/SVG/profiles/1.2T/master/painting.html#DisplayProperty


     [15] http://dev.w3.org/cvsweb/SVG/profiles/1.2T/master/painting.html.diff?r1=1.118&r2=1.119&f=h

   AG: I added in the media elements to the list of elements the
   property applies to
   ... and that pulls in graphics elements and the <audio> element
   ... also enhanced the wording to talk about the audibility of the
   <audio> element, and what each value does to it

   ED: what was the action?

   <anthony> ACTION-2207?

   <trackbot> ACTION-2207 -- Anthony Grasso to review the wording of
   visibility relating to audio -- due 2008-09-30 -- PENDINGREVIEW

   <trackbot> [16]http://www.w3.org/Graphics/SVG/WG/track/actions/2207

     [16] http://www.w3.org/Graphics/SVG/WG/track/actions/2207

   CM: the paragraph starting "Depending on the value of property
   'pointer-events'" doesn't really apply to <audio>
   ... are <video> and <animation> media elements?

   ED: yes

   AG: i'll remove mention of media elements from that sentence

   <ed_> <video> and <animation> are also graphics elements

   <ed_> as well as being media elements

   ED: pending that last change i'd be ok with closing the action

   AG: i raised an issue on Core 2.0 on this issue too, since we should
   be able to control audio separately from video

Test suite comments


     [17] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0326.html

   NH: starting from interact-focus-208


     [18] http://dev.w3.org/SVG/profiles/1.2T/test/svg/interact-focus-208-t.svg

   NH: the test description is wrong i think
   ... the test also says that "jumped" should be focussed at the same
   time as "frogs" and "in"

   ED: I agree it's not fully clear
   ... for the first paragraph i agree with you that it should say
   something like you say (about "frogs" and "in" before "jumped")
   ... i agree "in" is not focusable by itself
   ... "frogs" "in" is in one <tspan>, so they must be focussed

   NH: and when after frogs you get jumped
   ... the test says when jumped is focussed, frogs and in should be

   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

   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

   <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


     [20] http://dev.w3.org/SVG/profiles/1.2T/test/svg/udom-svg-228-t.svg

   NH: i think it should have "url()" around it

   ED: i agree

   <ed_> [21]http://www.w3.org/TR/SVGMobile12/interact.html#navigation

     [21] http://www.w3.org/TR/SVGMobile12/interact.html#navigation

   NH: i'll change it

   <scribe> ACTION: Niklas to fix udom-svg-228-t.svg [recorded in

   <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

   <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


     [24] http://dev.w3.org/SVG/profiles/1.2T/test/svg/udom-svg-220-t.svg

   CM: I probably meant to put a .split(' ') on the end of that string
   ... to make it a list

   <scribe> ACTION: Cameron to fix the set() call in udom-svg-220-t
   [recorded in

   <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


     [26] http://dev.w3.org/SVG/profiles/1.2T/test/svg/coords-constr-202-t.svg

   NH: on row 58

   ED: yes i agree
   ... either put an xlink:href to the root element, or move it

   NH: can we move it outside the test-body-content?

   ED: i think it's ok, some of the tests have content outside that
   ... 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

   <trackbot> Created ACTION-2219 - Add an xlink:href to the animate
   element in coords-constr-202-t [on Niklas Hagelroth - due

   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

   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

   <trackbot> Created ACTION-2220 - Remove the nav-index in
   interact-event-201-t [on Niklas Hagelroth - due 2008-10-02].


     [29] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0346.html

   ED: i sent some comments as well, we could go through some of the
   important ones
   ... text-area-206


     [30] http://dev.w3.org/SVG/profiles/1.2T/test/svg/text-area-206-t.svg

   ED: does ikivo put the textArea contents on the blue lines?

   NH: no not on the lines

   ED: slightly overlapping?

   NH: yes

   ED: i think the problem with the test is that the font was changed
   but the test wasn't updated
   ... should have a smaller font size for the textArea
   ... how about bitflash?

   LM: currently the text is on the blue lines in all cases
   ... how far off is it in other implementations?

   ED: quite far, half the line

   NH: i don't think you can count on our interpretation, since we
   don't use the right font

   ED: could we move it back to review, and i'll give a proposal for
   what i think is a good change?

   AG: it looks like the font size hasn't changed in the test
   ... so maybe just move it back to review

   ED: i can come up with a fix that i think would be ok, and we can
   discuss it

   <scribe> ACTION: Erik to send comments about text-area-206 to the
   list for review [recorded in

   <trackbot> Created ACTION-2221 - Send comments about text-area-206
   to the list for review [on Erik Dahlström - due 2008-10-02].


     [32] http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-svg-204-t.svg

   ED: next is struct-svg-204-t.svg
   ... the problem with this test is that it's testing a negative value
   for width/height on the svg element
   ... shouldn't render anything. opera doesn't if it's standalone, but
   if you use it in an <object> like in the harness, it overrides those
   and actually renders it.
   ... this is supported by the spec. maybe we could tweak the pass
   ... e.g. by saying you should open it standalone
   ... i'd be happy to take an action to add some pass criteria for the

   <scribe> ACTION: Erik to propose some pass criteria for
   struct-svg-204-t [recorded in

   <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


     [34] http://dev.w3.org/SVG/profiles/1.2T/test/svg/linking-refs-203-t.svg

   ED: here the test is requiring the alphabet a-j in a textarea should
   be broken into two lines
   ... but we don't mandate breaking of words in the spec
   ... so it'd be good if that was split into two words

   AG: put it in the content so it does break?

   ED: yes
   ... the second thing about the test is that the bottom right-most
   subtest is assuming that <use> renders if there was a circular
   ... 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

   <trackbot> Created ACTION-2223 - Remove that bottomright subtest
   from linking-refs-203 [on Erik Dahlström - due 2008-10-02].


     [36] http://dev.w3.org/SVG/profiles/1.2T/test/svg/interact-event-201-t.svg

   ED: interact-event-201, i believe it's listening for the wrong event
   ... the test is adding listeners for "focusin" and "focusout", but
   the events are named "DOMFocusIn" and "DOMFocusOut"
   ... it's only in the animation begin/end attributes that you can use
   those former names

   CM: so focusin/focusout are special keywords in timing specifiers?

   <ed_> [37]http://www.w3.org/TR/SVGMobile12/interact.html#SVGEvents

     [37] http://www.w3.org/TR/SVGMobile12/interact.html#SVGEvents

   ED: the events table gives both the event type and the animation
   event name, which is different

   CM: why do we use a different name?

   ED: good question
   ... i would guess historical reasons, it was in 1.1

   AG: the change to the test isn't that drastic

   (anthony fixes it now)

   ED: udom-glob-201, i think we should remove it
   ... this tests the GlobalException interface that was removed with
   the last publication

   NH: i agree

   (anthony removes udom-glob-201)

last call comments

   <ed_> [38]http://www.w3.org/Graphics/SVG/WG/track/products/11

     [38] http://www.w3.org/Graphics/SVG/WG/track/products/11

   ED: any that we can close?

   (doesn't seem to be)


   <trackbot> ISSUE-2065 -- Text selection - but what about Find Text ?
   -- RAISED

   <trackbot> [39]http://www.w3.org/Graphics/SVG/WG/track/issues/2065

     [39] http://www.w3.org/Graphics/SVG/WG/track/issues/2065

   ED: jeff suggests that the spec recommends that browser that support
   searching for text in the page that it searches through svg text
   ... would just be a suggestion

   DS: commented a bit in a mozilla bug a while ago

   <scribe> ACTION: Doug to propose some wording to suggest that
   searching for text should search through SVG text elements [recorded
   in [40]http://www.w3.org/2008/09/25-svg-minutes.html#action11]

   <trackbot> Created ACTION-2224 - Propose some wording to suggest
   that searching for text should search through SVG text elements [on
   Doug Schepers - due 2008-10-02].

   DS: should look for text that is embedded or inline, and it should
   scroll/pan the viewport such that it shows and highlights the text
   that is found
   ... kinda works in safai for examples that are embedded, but not as
   well for those that are standalone svg

   ED: so even if you have some text outside the viewport does safari
   pan the viewport?

   DS: no it doesn't
   ... i'd only make it a recommendation

   ED: there might be differences in UAs, so wouldn't be good to
   mandate, but suggestion is good
   ... it'd be useful to pan to the text, but exactly where it would
   position it i'm not sure we should say

   DS: as long as it's visible
   ... maybe the entire text run should be centered
   ... it should probably operate on the element level, so the whole
   element is centered
   ... i'll work something up


   <trackbot> ISSUE-2066 -- datatype (5.10.1) -- RAISED

   <trackbot> [41]http://www.w3.org/Graphics/SVG/WG/track/issues/2066

     [41] http://www.w3.org/Graphics/SVG/WG/track/issues/2066

   CM: you already replied and added some clarifications, yes?

   DS: i did put some prose in yes

   <scribe> ACTION: Doug Clarify the metadata attributes [recorded in

   <trackbot> Created ACTION-2225 - Clarify the metadata attributes [on
   Doug Schepers - due 2008-10-02].


     [43] http://dev.w3.org/SVG/profiles/1.2T/publish/struct.html#DatatypeAttribute

   ED: there's some new wording in cvs i see


   <trackbot> ISSUE-2068 -- focusHighlight must be inheritable --

   <trackbot> [44]http://www.w3.org/Graphics/SVG/WG/track/issues/2068

     [44] http://www.w3.org/Graphics/SVG/WG/track/issues/2068

   ED: so focusHighlight is an attribute, not a property

   DS: and attributes don't inherit?

   ED: some of them do, but it's different

   DS: how can i tell if it's inheritable? in the attribute table?

   AE: it's usually in the definition of each attribute/property

   CM: it does have it in the definition for properties, but i'm not
   sure for attributes


     [45] http://dev.w3.org/SVG/profiles/1.2T/publish/interact.html#FocusHighlight

   DS: doesn't say if it's inherited, just animatable
   ... it would be better as a property rather than attribute

   ED: i'm wondering if there's something in CSS already that does the
   ... 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
   ... 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


   DS: could change the behaviour in opera depending on the document

   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

   <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

   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

   ED: i think it's more common to focus as a whole rather than

   <ed_> It's a more common usecase to want few items focusable, rather
   than many

   <ed_> probably not

   <ed_> although mabe thursday?

   <ed_> we did say we'd allocate one day for a WG meeting

   <anthony> I might not be able to make Thursday evening next week now

   <anthony> I'll be flying up north next thursday

Summary of Action Items

   [NEW] ACTION: Cameron remove the scope chain wording from the
   <handler> section [recorded in
   [NEW] ACTION: Cameron to fix the set() call in udom-svg-220-t
   [recorded in
   [NEW] ACTION: Doug Clarify the metadata attributes [recorded in
   [NEW] ACTION: Doug to propose some wording to suggest that searching
   for text should search through SVG text elements [recorded in
   [NEW] ACTION: Doug to reply to Chris to state that we won't change
   focusHighlight [recorded in
   [NEW] ACTION: Erik to propose some pass criteria for
   struct-svg-204-t [recorded in
   [NEW] ACTION: Erik to remove that bottomright subtest from
   linking-refs-203 [recorded in
   [NEW] ACTION: Erik to send comments about text-area-206 to the list
   for review [recorded in
   [NEW] ACTION: Niklas to add an xlink:href to the animate element in
   coords-constr-202-t [recorded in
   [NEW] ACTION: Niklas to change ghostwhite to white in
   test/images/svgRef13.svg [recorded in
   [NEW] ACTION: Niklas to fix udom-svg-228-t.svg [recorded in
   [NEW] ACTION: Niklas to remove the nav-index in interact-event-201-t
   [recorded in
   [NEW] ACTION: Niklas to send more information with links to SMIL
   spec supporting the fact that it should be blue [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [60]scribe.perl version 1.133
    ([61]CVS log)
    $Date: 2008/09/25 12:05:58 $

     [60] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [61] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51
Check for newer version at [62]http://dev.w3.org/cvsweb/~checkout~/2002

     [62] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/issues/issue/
Succeeded: s/changing/closing/
Succeeded: s/defintion/definition/
Succeeded: s/send/sends/
Found Scribe: Cameron
Found ScribeNick: heycam
Default Present: NH, +1.613.445.aaaa, anthony, [IPcaller], heycam, ed_,
 Doug_Schepers, aemmons
Present: NH +1.613.445.aaaa anthony [IPcaller] heycam ed_ Doug_Schepers
Agenda: [63]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSe

     [63] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0353.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 25 Sep 2008
Guessing minutes URL: [64]http://www.w3.org/2008/09/25-svg-minutes.html
People with action items: cameron doug erik niklas

     [64] http://www.w3.org/2008/09/25-svg-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

   End of [65]scribe.perl diagnostic output]

     [65] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 25 September 2008 12:10:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:09 UTC