Minutes October 30, 2008 telcon

Minutes in html format:


or as text:


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

                                - DRAFT -

                    SVG Working Group Teleconference

30 Oct 2008



    See also: [3]IRC log

       [3] http://www.w3.org/2008/10/30-svg-irc


           Doug_Schepers, ed, heycam, aemmons, fantasai, NH, anthony




      * [4]Topics
          1. [5]LC comments
          2. [6]ISSUE-2058
          3. [7]ISSUE-2083
          4. [8]ISSUE-2085
          5. [9]ISSUE-2089
          6. [10]ISSUE-2106
          7. [11]ISSUE-2107
          8. [12]ISSUE-2106
          9. [13]Inheritance of display-align
         10. [14]ISSUE-2093
         11. [15]ISSUE-2094
         12. [16]ISSUE-2085
         13. [17]ISSUE-2147
      * [18]Summary of Action Items

    <trackbot> Date: 30 October 2008

    <scribe> Scribe: Cameron

    <scribe> ScribeNick: heycam

LC comments

    ED: doug you made the DoC?

    DS: yes

    ED: we don't have responses from some people, is that a problem?

    DS: it's suboptimal, but i'll communicate with those people and see
    if i can get them to reply



    <trackbot> ISSUE-2058 -- Lack of BIDI 'direction' -- CLOSED

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

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

    ED: fantasai still believes we need to change the spec a bit, and i
    ... we do have a sentence in the spec atm about the direction
    attribute, borrowed from 1.1

    ED reads out the sentence


      [20] http://lists.w3.org/Archives/Public/www-svg/2008Oct/0241.html

    ED: i have some proposed wording in that mail

    DS: do we use the term text chunk?

    ED: yeah
    ... the tspan element never establishes a text chunk because in tiny
    there's no x/y attributes

    DS: i don't think the box model fits with what we're trying to do
    ... it doesn't really matter if we set x/y attributes on the tspan,
    it's still only a tspan

    ED: but it would be a new text chunk, though this problem isn't in
    ... tspan is equivalent to an "inline level element" in the CSS spec

    DS: glancing over the wording it seems ok to me

    ED: i just wanted to avoid having tspan in there as the only
    element, because in full or later spec versions it might be
    ... so i think it's better to talk about text chunks

    EE: you might say the svg tiny 1.2 tspan element, to be clear
    ... did you remove the other paragraph?

    ED: i think cameron removed the other paragraph as part of some
    other action

    CM: glyph-orientation-*?

    ED: yes

    CM: yeah i commented that out

    EE: i suggest to take out the para about glyph orientation
    ... the way it's defined is not precise
    ... if you want to keep in text about glyph orientation you'll need
    to redesign it anyway
    ... so we and i18n group recommend it be removed

    DS: i'm concerned that if we design things for tiny that doesn't
    apply to full it'll cause trouble

    ED: the text i suggested will be workable for full going forward

    <fantasai> not precise and also wrong

    ED: for glyph orientation i agree it's incorrect so it should be

    DS: we need to revisit it for full

    <scribe> ACTION: erik to add the suggested direction property text
    [recorded in

    <trackbot> Created ACTION-2342 - Add the suggested direction
    property text [on Erik Dahlström - due 2008-11-06].



    <trackbot> ISSUE-2083 -- Paced animation and complex types -- RAISED

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

      [22] http://www.w3.org/Graphics/SVG/WG/track/issues/2083

    CM: i made a change to clean up the wording for the paced animation
    ... and olaf replied saying that in the cleanup i shouldn't have
    taken out the wording about vector/scalar
    ... so i replied to him with suggested wording to put it back in
    ... waiting to hear back from him


      [23] http://www.w3.org/mid/20081030011021.GC25338@arc.mcc.id.au



    <trackbot> ISSUE-2085 -- Spec unclear where focus should initially
    go when a document is loaded -- OPEN

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

      [24] http://www.w3.org/Graphics/SVG/WG/track/issues/2085

    <fantasai> ED,

      [25] http://lists.w3.org/Archives/Public/www-svg/2008Oct/0243.html

    NH: i couldn't find a nice way to support both alternatives for
    initial focus
    ... i thought maybe it could be a little unclear
    ... i think we can leave it as it is, actually

    ED: i agree

    DS: can you send a mail saying that



    <trackbot> ISSUE-2089 -- animateTransform and underlying value --

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

      [26] http://www.w3.org/Graphics/SVG/WG/track/issues/2089

    CM: no response yet

    <shepazu> [27]http://dev.w3.org/SVG/profiles/1.2T/doc-svgt12.html

      [27] http://dev.w3.org/SVG/profiles/1.2T/doc-svgt12.html




    <trackbot> ISSUE-2107 -- i18n comment 6: Direction and bidi-override
    attributes -- OPEN

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

      [28] http://www.w3.org/Graphics/SVG/WG/track/issues/2107


      [29] http://lists.w3.org/Archives/Public/www-svg/2008Oct/0213.html

    EE: doug proposed wording and someone else supplied an example

    ED: are the examples necessary for us to continue?

    DS: we could just put it into the test suite

    ED: i think it's more important to do the wording first, and worry
    about the examples later

    DS: i want to add an example of how you use it, a template
    ... let's say i put direction and unicode-bidi on the root, and i
    have some text, and then i want to use some english or french
    ... and i put that in a tspan
    ... with what we've said about a tspan, would that still work?
    ... it wouldn't hurt to be a bit more explicit

    EE: for the tspan you need the embed

    DS: for someone who wants to use arabic in svg, i want to have a
    template for them to do it easily

    EE: you don't need unicode-bidi on the root
    ... you definitely need it on the tspan

    <fantasai> <svg direction="rtl"> ... <text>ARABIC TEXT <tspan
    unicode-bidi="emped">English quote.</tspan> ARABIC

    DS: so i would have a paragraph (a text) within which is a tspan,
    and that tspan has a direction and bidi override
    ... is there a canonical example of something people normally quote?
    ... a hebrew/arabic quote that has some english in it?

    EE: i have mixed arabic/chinese, but not arabic/english
    ... you could ask the guy who gave you the example
    ... for embed, i generally only makes a difference if there's
    punctuation, characters in there that aren't strongly ltr
    ... in the example ori gave, the english is just one word so you
    don't need the properties

    <fantasai> I forgot the direction="ltr" in my example, btw

    <fantasai> don't forget it!



    <trackbot> ISSUE-2106 -- i18n comment 5: Characters and glyphs --

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

      [30] http://www.w3.org/Graphics/SVG/WG/track/issues/2106

    DS: richard should be getting back to us on that

    <shepazu> thanks, fantasai!!

    ED: i think the other 18n comments are just waiting for someone to


      [31] http://lists.w3.org/Archives/Public/www-svg/2008Oct/0231.html

Inheritance of display-align

    ED: the thing with new wording is not very complex
    ... just flipping display-align property to not inherit
    ... of course there are larger implications for implementations


      [32] http://lists.w3.org/Archives/Public/www-svg/2008Oct/0242.html

    ED: so i did some response to this here
    ... currently we do inherit the display-align property
    ... sometimes that's useful if you want to have several textAreas
    inside a group, and the same alignment on all of them
    ... the problem css has with it being inherited is that text blocks
    can nest in css
    ... but we can't nest textAreas in svg tiny so we don't have that
    ... i think that it wouldn't be such a big problem to specify
    display-align on the places that need them
    ... if that helps css and if that makes css able to use the same
    property i think that would be very good

    DS: as an author, how many textAreas am i going to have?
    ... if svg is for precision display, not for bulk document display,
    at least in terms of text

    ED: so far i haven't seen many documents using several textAreas
    like that
    ... at most i've seen 3 or 5 in a document
    ... so it's not like it's a big problem
    ... to specify on each

    DS: i agree

    EE: the related issue is that the name of the properties or the
    values are that intuitive
    ... second, making it not inherit would make it incompatible with

    DS: do we get this from xsl?

    EE: yes

    DS: they have it inherit?

    EE: that's what i recall, but i'll check

    DS: that's more of a problem

    <ed> [33]http://www.w3.org/TR/xsl/#display-align

      [33] http://www.w3.org/TR/xsl/#display-align

    EE: in svg tiny it's an attribute or a property?

    ED: a property

    DS: you're thinking of making something similar?

    EE: yes

    DS: is it possible to keep this as to align with xsl, then for you
    to name yours differently?
    ... and then going forward we'll use your name and values for svg
    ... where svg core is the next version of the language

    EE: would it make sense to restrict this to just be an attribute in

    DS: it wouldn't not make sense, i think it's suboptimal, but since
    svg tiny isn't going to be the core of the language

    EE: that would avoid putting the property into the css parser

    ED: it would affect us, we've put it as a css property currently
    ... there could be alternatives for css, maybe introducing something
    that says you don't use this property unless some other property is
    ... don't know whether introducing a new property block-align or
    something is better

    EE: we do require having an auto value, and we can say
    block-align:auto it means look at svg's display-align

    DS: since it seems significant coordination between the three
    groups, and since css would like to have a different property name,
    i'd prefer to defer this

    ED: i still think this wouldn't affect existing content or future
    tiny 1.2 content, because it would still be possible to fix the
    content even if we decide later not to inherit

    DS: i don't think we would change this one
    ... we can't step on xsl any more than we can step on css
    ... we could deprecate this if we found that the css one makes more
    sense in a larger context
    ... i'll raise an issue on core

    <fantasai> Given that you already have implementations, and given
    the above, I'm ok with deferring it to later.



    <trackbot> ISSUE-2093 -- 16.2.9 by 'identity' -- RAISED

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

      [34] http://www.w3.org/Graphics/SVG/WG/track/issues/2093




      [36] http://www.w3.org/mid/200810291536.31967.Dr.O.Hoffmann@gmx.de


      [37] http://www.w3.org/mid/20081030023403.GE25338@arc.mcc.id.au

    CM: olaf seems unhappy with the text added about zero values
    ... i replied (basically) saying that i think the text is ok

    DS: i say we punt on this and do as he asks (remove the table and

    CM: ok, i think it's better to have it in there, but acceptable to
    remove it

    <scribe> ACTION: Cameron to perform the removal olaf asks and reply
    [recorded in

    <trackbot> Created ACTION-2343 - Perform the removal olaf asks and
    reply [on Cameron McCormack - due 2008-11-06].



    <trackbot> ISSUE-2094 -- accessing rules for traitAccess -- RAISED

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

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


      [40] http://lists.w3.org/Archives/Public/www-svg/2008Oct/0223.html

    ED: last mail in the thread is from andrew

    AE: he said he agreed
    ... but there were two parts to his question after some discussion
    ... then he says, can you just do something about erik's question?
    ... i said we'd discuss it and get back to him
    ... he is talking about whether it's unspecified if we modify an
    xml:id attribute that is the on the target of an animation
    ... he says there's no restriction on modifying xml:id when it's in
    the tree
    ... i kinda agree with that
    ... if we haven't specified it, any implementor would've picked one
    of the three options
    ... but i think he's already satisfied, but it's a courtesy for us
    to make a decision on it

    ED: i think it's partially defined in smil, but i'm not exactly sure
    ... the begin attribute evaluation, it's not really defined when it
    ... adding a section to say that if you change xml:id when
    animations target those elements, the behaviour would be UA
    ... that'd be a simple way to resolve it

    AE: yes that's perfect

    <scribe> ACTION: Cameron to add the sentence ED suggests here in the
    minutes, and reply to Julien [recorded in

    <trackbot> Created ACTION-2344 - Add the sentence ED suggests here
    in the minutes, and reply to Julien [on Cameron McCormack - due

    ACTION-2344: say please respond immediately, or actually it seems
    he's satisfied already so just to let him know

    <trackbot> ACTION-2344 Add the sentence ED suggests here in the
    minutes, and reply to Julien notes added


    <shepazu> Spec unclear where focus should initially go when a
    document is loaded



    <trackbot> ISSUE-2147 -- Section on externally referenced documents
    confusing -- OPEN

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

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

    ED: i'd like to change some of the wording [of cameron's suggested
    ... the current spec/proposed text says if you have an svg document
    fragment, like several fragments inline in an XHTML file
    ... then each of the document fragments are separate primary
    ... that's fine, but the para after mentions that primary documents
    have a map of IRIs to resource documents
    ... if svg fragments cannot share the same resources, it takes more
    ... e.g. if you have 10 svg fragments each <use>ing the same thing,
    would you want that to load 10 different resources?

    DS: this is a conceptual model, right?

    ED: i think it's too much requirements here
    ... i'd prefer a may to be in there

    <NH> After a second review of the wording around initial focus I've
    come to the conclusion that the text could stay as it is currently.
    Since there is different use-cases for Stand alone SVG user agents
    and web browsers the specification the specification cannot be to
    strict on how to handle this.

    CM: i wouldn't

    ED: one option would be to remove the document fragment case, i
    don't think that's a good suggestion, and to define it later
    ... another would be to say the primray document is the document
    ... that would make the enclosing document be the primary document,
    so that resources could be shared between fragments

    <ed> so, change cam's wording "Each primary document maintains a
    dictionary that maps IRIs " to "Each document maintains a dictionary
    that maps IRIs "

    ED: cameron you can incorporate my change and mail out new suggested
    ... i agree with the rest of the rewording
    ... this is an issue on the current spec wording too

    <scribe> ACTION: Cameron to incorporate Erik's suggestion into the
    proposal and add it to the spec [recorded in

    <trackbot> Created ACTION-2345 - Incorporate Erik's suggestion into
    the proposal and add it to the spec [on Cameron McCormack - due

    <ed> DS: tooltip started as tooltip, but morphed to a popup

    <ed> ...the word tooltip has come to mean a little popup

    <ed> ...and it's used in that sense

    <ed> ...not in the sense of a contexthelp

    <ed> ...there's nothing in ARIA that is equivalent

    <ed> ...the vlaue of contexthelp in role, as proposed, has nothing
    to do with behaviour

    <ed> ...it only maps it to being contexthelp

    <ed> CM: i agree with that, but that's not what the spec says

    <ed> ...shouldn't force the UA to act on this role

    <ed> ...for role="tooltip" in HTML, you might make some divs with
    yellow background and then display, and then say that yes this is
    used as a tooltip

    <ed> DS: yes, and you'd use script or something to hide or show it

    <ed> CM: right, but for contexthelp [sorry missed stuff here]

    <ed> DS: ARIA doesn't add automatic behavior, only adds semantics

    <ed> ...you don't have to use contexthelp like described in the spec

    <ed> ...we're going to run into this problem anyway

    <ed> ...people are going to start using role to add behavior

    <ed> CM: if your language doesn't have something the AT can
    understand, you can fake it by using role

    <ed> ...and do some graphical thing

    <ed> DS: getting people to use aria is that they get some reward

    <ed> CM: right, yes, you get some benefit plus the accessibility

    <ed> ...but I think there should be a contexthelp element instead

    <ed> ...so you don't have to annotate it

    <ed> DS: i think it's just a matter of where the semantics lie, on
    the element level or if they can be derived from role

    <ed> ...i think they should be derivable from role

    <ed> CM: my ideal solution would be to have a contexthelp element,
    and have a role to map that

    <ed> DS: i think that's overkill

    <ed> ...whether it's an element or a role that has the behavior

    <ed> CM: no other role has that trait

    <ed> DS: at the moment role doesn't add behaviors in other aria

    <ed> ...but it's going to happen

    <ed> CM: ok, if that's going to happen

    <ed> DS: we can't add a contexthelp element at this point

    <ed> CM: right

    <ed> ...that's how I feel about contexthelp too

    <ed> DS: more comfortable if it was a recommendation?

    <ed> CM: not sure if that's enough

    <NH> Sorry, I have to quit, bye

    <ed> DS: isn't this similar to tooltips?

    <ed> ...I think adding behavior based on role helps accessibility

    <ed> ...ppl will use it when they wouldn't before

    <ed> CM: agreed, but I think it's problematic because it's adding

    <ed> DS: the accessibility ppl seemed to like this

    <ed> ...talked to Al Gilman

    <ed> ...he agreed that it'd be better if it was an element, but he
    was ok with it being a role

    <ed> ...aaron leventhal raised the same objection as CM

    <ed> ...everyone else thought it was good to promote the use of aria

    <ed> CM: ok, so if accessibility ppl are ok with it, what do we do
    with UA:s that don't implement the behavior

    <anthony> Zakime, bye

Summary of Action Items

    [NEW] ACTION: Cameron to add the sentence ED suggests here in the
    minutes, and reply to Julien [recorded in
    [NEW] ACTION: Cameron to incorporate Erik's suggestion into the
    proposal and add it to the spec [recorded in
    [NEW] ACTION: Cameron to perform the removal olaf asks and reply
    [recorded in
    [NEW] ACTION: erik to add the suggested direction property text
    [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [48]scribe.perl version 1.133
     ([49]CVS log)
     $Date: 2008/10/30 12:14:22 $

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

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/chung/chunk/
Succeeded: s/work/one word/
Succeeded: s/responsd/respond/
Succeeded: s/hte/the/
Found Scribe: Cameron
Found ScribeNick: heycam
Default Present: Doug_Schepers, ed, heycam, aemmons, fantasai, NH, anth
Present: Doug_Schepers ed heycam aemmons fantasai NH anthony
Agenda: [51]http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDe


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

Found Date: 30 Oct 2008
Guessing minutes URL: [52]http://www.w3.org/2008/10/30-svg-minutes.html
People with action items: cameron erik

      [52] http://www.w3.org/2008/10/30-svg-minutes.html

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

    End of [53]scribe.perl diagnostic output]

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

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Thursday, 30 October 2008 12:16:38 UTC