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

Minutes, SVG telcon Tuesday 23 September 2008

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Tue, 23 Sep 2008 22:09:12 +1000
Message-ID: <48D8DC68.3030509@cisra.canon.com.au>
To: W3C SVG Public Working Group <public-svg-wg@w3.org>

    [1]W3C

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

                                - DRAFT -

                    SVG Working Group Teleconference

23 Sep 2008

    [2]Agenda

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

    See also: [3]IRC log

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

Attendees

    Present
           Andrew_Emmons, anthony, Doug_Schepers, lmartine, NH, ed

    Regrets
    Chair
           Andrew Emmons

    Scribe
           , anthony

Contents

      * [4]Topics
          1. [5]Overflow issue with CSS and SVG specs
          2. [6]Test Suite Comments
          3. [7]Last Call Comments
      * [8]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 23 September 2008

    <aemmons> trackbot, who is here?

    <trackbot> Sorry, aemmons, I don't understand 'trackbot, who is
    here?'. Please refer to [9]http://www.w3.org/2005/06/tracker/irc for
    help

       [9] http://www.w3.org/2005/06/tracker/irc

    <aemmons> tzakim, ??p1 is lmartine

    <anthony> Scribe:

    <anthony> Scribe: anthony

Overflow issue with CSS and SVG specs

    DS: Summary of issue
    ... Reason for this is there is a lot of content out there is bigger
    than the view port
    ... which is reasonable
    ... there is an expectation from users that it should be panned
    ... but instead scroll bars appear
    ... I guess the question for me is what does most content need?
    ... panning or scrolling
    ... FF essentially does it the way Apple wants it to

    ED: I sent a reply to this thread
    ... I was reading a webkit bug tracker
    ... seems they have a similar way of solving the problem
    ... as we

    <ed>
    [10]http://lists.w3.org/Archives/Member/w3c-svg-wg/2008JulSep/0025.h
    tml

      [10] http://lists.w3.org/Archives/Member/w3c-svg-wg/2008JulSep/0025.html

    AE: It's not just something that user agent dependent?
    ... they can choose to do whatever they want?

    DS: Apparently browser based UAs do it different to the way it's
    specified

    NH: Not sure if this does affect us

    LM: For us the panning is controlled by the application on top of
    the SVG Engine
    ... up to the application
    ... which makes sens in a browser environment

    DS: I've only heard from one person in the public
    ... and that was David who agrees with me in general
    ... I haven't heard from anybody who thinks that it would break
    their content
    ... given that there is a work around and given that the browsers do
    this already
    ... let's go ahead and make the change

    AE: And this would be an errata right?
    ... because there's no overflow in Tiny 1.2?

    DS: Yeah it probably would be an errata

    AE: Not sure how you would word it
    ... if we don't have it in Tiny we don't have to mention it
    ... it is up to the higher level application

    DS: Hearing no objections

    ED: I agree

    NH: I agree

    RESOLUTION: Make an errata for 1.1 regarding the initial value for
    the root overflow property will be visible rather than hidden

    ED: Visible is the value in CSS

    <scribe> ACTION: Doug to Add to the 1.1 Full errata that the initial
    value for the root overflow property is scroll rather than hidden
    [recorded in
    [11]http://www.w3.org/2008/09/23-svg-minutes.html#action01]

    <trackbot> Created ACTION-2203 - Add to the 1.1 Full errata that the
    initial value for the root overflow property is scroll rather than
    hidden [on Doug Schepers - due 2008-09-30].

    <aemmons>
    [12]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/032
    6.html

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

Test Suite Comments

    AE: We could try to get through most of these

    animate-elem-86-t.svg

    <ed>
    [13]http://dev.w3.org/SVG/profiles/1.2T/test/svg/animate-elem-86-t.s
    vg

      [13] http://dev.w3.org/SVG/profiles/1.2T/test/svg/animate-elem-86-t.svg

    ED: So with this test what does Bitflash do?
    ... I know Opera behaves as the test case assumes

    LM: With the never box it's checked which is what the test is
    testing for
    ... still discussing how the spec should be interpreted

    AE: If this is a test that doesn't contribute to the coverage
    ... we should probably drop it back to draft
    ... and move on

    AG: I agree with that

    ED: I'd like to review the sections there to make sure

    <scribe> ACTION: Erik to Review animate-elem-86-t test [recorded in
    [14]http://www.w3.org/2008/09/23-svg-minutes.html#action02]

    <trackbot> Created ACTION-2204 - Review animate-elem-86-t test [on
    Erik Dahlström - due 2008-09-30].

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

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

    <ed>
    [16]http://dev.w3.org/SVG/profiles/1.2T/test/svg/udom-svg-205-t.svg
    (already fixed)

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

    AE: I need some clarification on this
    ... I think the test is testing the fact that top level SVG can have
    a Nav_next to tell it which element has focused

    NH: When the element comes up shouldn't the document have focus?

    AE: You guys have UA focus right?

    NH: Yes
    ... we default focus to the document element always

    AE: And once you go through your focus ring you go to the text

    LM: We were wondering what it means by the focus should be "offered"

    DS: That's bad text
    ... it's a term that's not defined
    ... I think we got an LC comment last time
    ... I think we should find a better term

    LM: Makes it ambiguous

    DS: I think that could use some rewording

    NH: What would the new wording be?

    AE: And that's related to that particular test is that the problem?

    NH: No that's not the problem here

    LM: In our case we don't give the document the initial focus

    NH: Then you focus backwards?

    LM: Yes

    AE: I think both interpretations of the spec are correct
    ... but it seems like we should tighten the spec

    NH: But this test as another problem
    ... [Reads test description]

    AE: I'd suggest not un-approving this test
    ... because it's a key 1.2 T feature
    ... something we could figure out this week or at the test fest

    <scribe> ACTION: Nicolas to propose new wording and a change in the
    test interact-focus-201-t.svg regarding initial focus [recorded in
    [17]http://www.w3.org/2008/09/23-svg-minutes.html#action03]

    <trackbot> Sorry, couldn't find user - Nicolas

    <scribe> ACTION: Niklas to propose new wording and a change in the
    test interact-focus-201-t.svg regarding initial focus [recorded in
    [18]http://www.w3.org/2008/09/23-svg-minutes.html#action04]

    <trackbot> Created ACTION-2205 - Propose new wording and a change in
    the test interact-focus-201-t.svg regarding initial focus [on Niklas
    Hagelroth - due 2008-09-30].

    AE: So the next one media-anim-201-t.svg seems to be a similar issue
    ... can you take a look at that one when you do your action?

    NH: Ok

    [19]http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-class-201-t.
    svg

      [19] http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-class-201-t.svg

    AE: I think it's a quick fix
    ... it's just making it uDOM friendly

    <ed> outputEl.firstChild.nodeValue = classVal; should be perhaps
    outputEl.textContent = classVal?

    DS: Making it uDOM friendly is fine with me

    <scribe> ACTION: Nkilas to Make struct-class-201-t uDOM friendly
    [recorded in
    [20]http://www.w3.org/2008/09/23-svg-minutes.html#action05]

    <trackbot> Sorry, couldn't find user - Nkilas

    <scribe> ACTION: Niklas to Make struct-class-201-t uDOM friendly
    [recorded in
    [21]http://www.w3.org/2008/09/23-svg-minutes.html#action06]

    <trackbot> Created ACTION-2206 - Make struct-class-201-t uDOM
    friendly [on Niklas Hagelroth - due 2008-09-30].

    [22]http://dev.w3.org/SVG/profiles/1.2T/test/svg/media-audio-212-t.s
    vg

      [22] http://dev.w3.org/SVG/profiles/1.2T/test/svg/media-audio-212-t.svg

    NH: This one is a bit tricky
    ... do you pass this test?

    LM: The spec seems a bit ambiguous for the display and visibility
    for audio attributes
    ... display property part disagrees with the table of values
    ... so it's not clear whether visibility affects audio

    <ed> [23]http://www.w3.org/TR/SVGMobile12/intro.html

      [23] http://www.w3.org/TR/SVGMobile12/intro.html

    ED: I haven't had time to look at this particular test
    ... in the intro if you have display none then visual and audio
    elements shouldn't be rendered

    LM: They work in the Bitflash implementation

    <ed> definition for "rendering tree"

    ED: It is possible it could be made more clear

    NH: When you read about the visibility property it says it only
    applies to visual elements

    <ed>
    [24]http://www.w3.org/TR/SVGMobile12/painting.html#DisplayProperty

      [24] http://www.w3.org/TR/SVGMobile12/painting.html#DisplayProperty

    DS: This should be clarified in the spec
    ... I'm pretty sure I recall us having long discussions about this
    ... and getting LC comments on it
    ... I think we should clarify the spec
    ... it is true that the word visibility is bad wording

    NH: It just it doesn't make much sense to me

    AE: What do you do guys do for video?

    NH: Assume it's a graphical element and assume it's muted
    ... audio should still be heard

    ED: I think that the audio should not be heard

    <scribe> ACTION: Anthony to review the wording of visibility
    relating to audio [recorded in
    [25]http://www.w3.org/2008/09/23-svg-minutes.html#action07]

    <trackbot> Created ACTION-2207 - Review the wording of visibility
    relating to audio [on Anthony Grasso - due 2008-09-30].

    [26]http://dev.w3.org/SVG/profiles/1.2T/test/svgstruct-frag-02-t.svg

      [26] http://dev.w3.org/SVG/profiles/1.2T/test/svgstruct-frag-02-t.svg

    <ed>
    [27]http://dev.w3.org/cvsweb/SVG/profiles/1.2T/test/svg/struct-frag-
    02-t.svg

      [27] http://dev.w3.org/cvsweb/SVG/profiles/1.2T/test/svg/struct-frag-02-t.svg

    ED: The last change to the test is changing the viewBox on the svg
    root element

    <ed>
    [28]http://dev.w3.org/cvsweb/SVG/profiles/1.2T/test/svg/struct-frag-
    02-t.svg.diff?r1=1.5&r2=1.6&f=h

      [28] 
http://dev.w3.org/cvsweb/SVG/profiles/1.2T/test/svg/struct-frag-02-t.svg.diff?r1=1.5&r2=1.6&f=h

    <scribe> ACTION: Anthony to fix struct-frag-02-t and 03-t such that
    the viewBox is added back in [recorded in
    [29]http://www.w3.org/2008/09/23-svg-minutes.html#action08]

    <trackbot> Created ACTION-2208 - Fix struct-frag-02-t and 03-t such
    that the viewBox is added back in [on Anthony Grasso - due
    2008-09-30].

    [30]http://dev.w3.org/cvsweb/SVG/profiles/1.2T/test/svg/interact-eve
    nt-204-t.svg

      [30] 
http://dev.w3.org/cvsweb/SVG/profiles/1.2T/test/svg/interact-event-204-t.svg

    ED: I agree we shouldn't be using SVG sub elements here
    ... we could use animation elements perhaps
    ... or get rid of the sub case

    AE: Remove the subcase for now

    <scribe> ACTION: Emmons to remove the subtest from
    interact-event-204-t [recorded in
    [31]http://www.w3.org/2008/09/23-svg-minutes.html#action09]

    <trackbot> Created ACTION-2209 - Remove the subtest from
    interact-event-204-t [on Andrew Emmons - due 2008-09-30].

Last Call Comments

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

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

    ED: I responded to Dr Olaf regarding ISSUE-2059
    ... we can close that

    <aemmons> [33]http://www.w3.org/Graphics/SVG/WG/track/issues/2060

      [33] http://www.w3.org/Graphics/SVG/WG/track/issues/2060

    trackbot, ISSUE-2060

    <trackbot> Sorry, anthony, I don't understand 'trackbot,
    ISSUE-2060'. Please refer to
    [34]http://www.w3.org/2005/06/tracker/irc for help

      [34] http://www.w3.org/2005/06/tracker/irc

    ISSUE-2060

    DS: I introduced a few mistakes in an example
    ... one I used id instead of xml:id
    ... since that's allowed I'd like to leave it as is
    ... he says more examples needed
    ... and he's right
    ... if we have time we'll do it
    ... should we change all the examples in the spec to have titles

    AE: I think time is the issue and we should revamp them for the next
    spec

    AG: I agree

    RESOLUTION: We are not going to change the examples but we will
    revamp then in the next version of the spec

    <scribe> ACTION: Doug to Respond to Dr Olaf regarding the LC comment
    on the specification examples [recorded in
    [35]http://www.w3.org/2008/09/23-svg-minutes.html#action10]

    <trackbot> Created ACTION-2210 - Respond to Dr Olaf regarding the LC
    comment on the specification examples [on Doug Schepers - due
    2008-09-30].

    <aemmons> [36]http://www.w3.org/Graphics/SVG/WG/track/issues/2061

      [36] http://www.w3.org/Graphics/SVG/WG/track/issues/2061

    <aemmons> [37]http://www.w3.org/Graphics/SVG/WG/track/issues/2057

      [37] http://www.w3.org/Graphics/SVG/WG/track/issues/2057

    ISSUE-2057

    DS: I made the agreed wording but she did not agree to that
    ... I think the best resolution would to say that we don't specify
    what happens if there is another value
    ... the content would be non-conforming if it uses another value
    ... but user agents that support CSS are allowed to have other
    values
    ... and I propose we put a section in the spec that says for UA that
    support CSS we can say that content can be made
    ... that is non-conforming but UAs are allowed to behave according
    to CSS

    ED: As long as it's inline with SVG Full 1.1
    ... not sure if make any overrides because of CSS properties

    DS: What would mean for a text element to be a block element?
    ... would it wrap at that point

    ED: The way I see it SVG doesn't even use block element

    DS: What if we had display = block
    ... are there any objects with the content being non-conforming but
    the UA be conforming

    <scribe> ACTION: Doug to propose wording regarding ISSUE-2057
    [recorded in
    [38]http://www.w3.org/2008/09/23-svg-minutes.html#action11]

    <trackbot> Created ACTION-2211 - Propose wording regarding
    ISSUE-2057 [on Doug Schepers - due 2008-09-30].

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

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

    ISSUE-2058

    AE: [explains issue]

    DS: Are the circumstances where the there is no control of the
    initial direction?

    LM: I see that that as an issue
    ... if the underlaying implementation doesn't allow this to be
    specified

    ED: This means that content may look different between a Tiny and a
    Full agent when dealing with BiDi Text

    DS: Can we hold off until Thur

    <aemmons> [40]http://www.w3.org/Graphics/SVG/WG/track/issues/2061

      [40] http://www.w3.org/Graphics/SVG/WG/track/issues/2061

    ISSUE-2061

    DS: There are two different timing interfaces

    ED: SVG has inherited SMIL DOM methods
    ... and HTML5 don't use SMIL

    DS: No I mean we have two different interfaces, one has start and
    stop
    ... and the other has pause and unpause
    ... if you look at the uDOM and you look at where pause is
    ... it has its own interface

    AE: It's simply because we're inheriting SMIL
    ... this is carry over from 1.1
    ... we've had this for a long time
    ... this is simply because of the legacy of supporting SMIL
    ... the element time control is beyond our control

    DS: Couldn't we add methods to that

    AE: Too late to do that

    <scribe> ACTION: Emmons to Give a reply on ISSUE-2061 explaining why
    the methods are the way they are [recorded in
    [41]http://www.w3.org/2008/09/23-svg-minutes.html#action12]

    <trackbot> Created ACTION-2212 - Give a reply on ISSUE-2061
    explaining why the methods are the way they are [on Andrew Emmons -
    due 2008-09-30].

    <aemmons> [42]http://www.w3.org/Graphics/SVG/WG/track/issues/2062

      [42] http://www.w3.org/Graphics/SVG/WG/track/issues/2062

    ISSUE-2062

    DS: This may take a bit of time

    <aemmons> [43]http://www.w3.org/Graphics/SVG/WG/track/issues/2064

      [43] http://www.w3.org/Graphics/SVG/WG/track/issues/2064

    ISSUE-2064

    DS: One of the attributes I introduced
    ... that's meant for metadata
    ... I'll talk to the RDFA people and find out how to better specify
    this
    ... my definition was stricter then theirs but could do with more
    tightening
    ... he says xlink:href can be animate but the type can not be
    animated
    ... so if I had a video and I changed the source I couldn't change
    the type
    ... e.g. changing OGG file to AVI and not changing the type
    ... so the question is why type cannot be animated

    ED: I personally don't see a reason why it shouldn't be animated

    NH: I agree type should be animated

    DS: So if we agree should we say something along the lines of we
    should only change the type if the xlink:href changes
    ... you don't want to randomly changing the type

    ED: Well if you had a UA that animated the type for pre-loading

    DS: Are you sure there is no reason to have it not animatable

    ED: We should say that the content be re-evaluated if the type is
    changed

    DS: It should be animatable where it makes sense

    <ed> that is: probably not the script element since xlink:href isn't
    animatable there

    <scribe> ACTION: Erik to Make the type attribute animatable for
    types [recorded in
    [44]http://www.w3.org/2008/09/23-svg-minutes.html#action13]

    <trackbot> Created ACTION-2213 - Make the type attribute animatable
    for types [on Erik Dahlström - due 2008-09-30].

    DS: Do you want me to reply after the change?

    ED: Yes, that would be good

Summary of Action Items

    [NEW] ACTION: Anthony to fix struct-frag-02-t and 03-t such that the
    viewBox is added back in [recorded in
    [45]http://www.w3.org/2008/09/23-svg-minutes.html#action08]
    [NEW] ACTION: Anthony to review the wording of visibility relating
    to audio [recorded in
    [46]http://www.w3.org/2008/09/23-svg-minutes.html#action07]
    [NEW] ACTION: Doug to Add to the 1.1 Full errata that the initial
    value for the root overflow property is scroll rather than hidden
    [recorded in
    [47]http://www.w3.org/2008/09/23-svg-minutes.html#action01]
    [NEW] ACTION: Doug to propose wording regarding ISSUE-2057 [recorded
    in [48]http://www.w3.org/2008/09/23-svg-minutes.html#action11]
    [NEW] ACTION: Doug to Respond to Dr Olaf regarding the LC comment on
    the specification examples [recorded in
    [49]http://www.w3.org/2008/09/23-svg-minutes.html#action10]
    [NEW] ACTION: Emmons to Give a reply on ISSUE-2061 explaining why
    the methods are the way they are [recorded in
    [50]http://www.w3.org/2008/09/23-svg-minutes.html#action12]
    [NEW] ACTION: Emmons to remove the subtest from interact-event-204-t
    [recorded in
    [51]http://www.w3.org/2008/09/23-svg-minutes.html#action09]
    [NEW] ACTION: Erik to Make the type attribute animatable for types
    [recorded in
    [52]http://www.w3.org/2008/09/23-svg-minutes.html#action13]
    [NEW] ACTION: Erik to Review animate-elem-86-t test [recorded in
    [53]http://www.w3.org/2008/09/23-svg-minutes.html#action02]
    [NEW] ACTION: Nicolas to propose new wording and a change in the
    test interact-focus-201-t.svg regarding initial focus [recorded in
    [54]http://www.w3.org/2008/09/23-svg-minutes.html#action03]
    [NEW] ACTION: Niklas to Make struct-class-201-t uDOM friendly
    [recorded in
    [55]http://www.w3.org/2008/09/23-svg-minutes.html#action06]
    [NEW] ACTION: Niklas to propose new wording and a change in the test
    interact-focus-201-t.svg regarding initial focus [recorded in
    [56]http://www.w3.org/2008/09/23-svg-minutes.html#action04]
    [NEW] ACTION: Nkilas to Make struct-class-201-t uDOM friendly
    [recorded in
    [57]http://www.w3.org/2008/09/23-svg-minutes.html#action05]

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [58]scribe.perl version 1.133
     ([59]CVS log)
     $Date: 2008/09/23 12:05:40 $
      _________________________________________________________

      [58] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [59] 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 [60]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/scroll/visible/
Succeeded: s/on the element/on the svg root element/
Succeeded: s/it's got it's/it has its/
Found Scribe:
Found Scribe: anthony
Inferring ScribeNick: anthony
Scribes: , anthony
Default Present: Andrew_Emmons, anthony, Doug_Schepers, lmartine, NH, e
d
Present: Andrew_Emmons anthony Doug_Schepers lmartine NH ed
Agenda: [61]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSe
p/0340.html
Found Date: 23 Sep 2008
Guessing minutes URL: [62]http://www.w3.org/2008/09/23-svg-minutes.html
People with action items: anthony doug emmons erik nicolas niklas nkila
s

      [61] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0340.html
      [62] http://www.w3.org/2008/09/23-svg-minutes.html

    End of [63]scribe.perl diagnostic output]

      [63] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Tuesday, 23 September 2008 12:09:56 UTC

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