10:29:31 <RRSAgent> RRSAgent has joined #svg
10:29:31 <RRSAgent> logging to http://www.w3.org/2008/10/30-svg-irc
10:29:33 <trackbot> RRSAgent, make logs public
10:29:33 <Zakim> Zakim has joined #svg
10:29:35 <trackbot> Zakim, this will be GA_SVGWG
10:29:35 <Zakim> ok, trackbot, I see GA_SVGWG()6:30AM already started
10:29:36 <trackbot> Meeting: SVG Working Group Teleconference
10:29:36 <trackbot> Date: 30 October 2008
10:30:02 <Zakim> +[IPcaller]
10:30:11 <Zakim> +??P2
10:30:14 <ed> Zakim, [IP is me
10:30:14 <Zakim> +ed; got it
10:30:16 <Zakim> +[IPcaller]
10:30:20 <heycam> Zakim, ??P2 is me
10:30:20 <Zakim> +heycam; got it
10:30:26 <aemmons> zakim, [IPCaller] is me
10:30:26 <Zakim> +aemmons; got it
10:32:03 <heycam> Scribe: Cameron
10:32:06 <heycam> ScribeNick: heycam
10:32:07 <ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0313.html
10:32:48 <heycam> Topic: LC comments
10:32:53 <heycam> ED: doug you made the DoC?
10:32:54 <heycam> DS: yes
10:33:00 <heycam> ED: we don't have responses from some people, is that a problem?
10:33:01 <Zakim> +??P4
10:33:14 <fantasai> Zakim, ??P4 is fantasai
10:33:14 <Zakim> +fantasai; got it
10:33:16 <heycam> DS: it's suboptimal, but i'll communicate with those people and see if i can get them to reply
10:33:51 <heycam> Topic: ISSUE-2058
10:33:53 <heycam> ISSUE-2058?
10:33:54 <trackbot> ISSUE-2058 -- Lack of BIDI 'direction' -- CLOSED
10:33:54 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2058
10:34:17 <heycam> ED: fantasai still believes we need to change the spec a bit, and i agree
10:34:41 <heycam> ED: we do have a sentence in the spec atm about the direction attribute, borrowed from 1.1
10:34:47 <heycam> ED reads out the sentence
10:34:48 <ed> http://lists.w3.org/Archives/Public/www-svg/2008Oct/0241.html
10:34:51 <heycam> ED: i have some proposed wording in that mail
10:35:55 <heycam> DS: do we use the term text chunk?
10:35:57 <heycam> ED: yeah
10:36:12 <heycam> ED: the tspan element never establishes a text chung because in tiny there's no x/y attributes
10:36:20 <heycam> s/chung/chunk/
10:36:32 <heycam> DS: i don't think the box model fits with what we're trying to do here
10:36:55 <heycam> DS: it doesn't really matter if we set x/y attributes on the tspan, it's still only a tspan
10:37:09 <Zakim> +NH
10:37:10 <heycam> ED: but it would be a new text chunk, though this problem isn't in tiny
10:37:20 <heycam> ED: tspan is equivalent to an "inline level element" in the CSS spec
10:37:25 <heycam> DS: glancing over the wording it seems ok to me
10:37:42 <heycam> ED: i just wanted to avoid having tspan in there as the only element, because in full or later spec versions it might be different
10:37:47 <heycam> ED: so i think it's better to talk about text chunks
10:38:10 <heycam> EE: you might say the svg tiny 1.2 tspan element, to be clear
10:38:14 <heycam> EE: did you remove the other paragraph?
10:38:21 <heycam> ED: i think cameron removed the other paragraph as part of some other action
10:38:35 <heycam> CM: glyph-orientation-*?
10:38:37 <heycam> ED: yes
10:38:40 <heycam> CM: yeah i commented that out
10:39:04 <heycam> EE: i suggest to take out the para about glyph orientation
10:39:13 <heycam> EE: the way it's defined is not precise
10:39:29 <heycam> EE: if you want to keep in text about glyph orientation you'll need to redesign it anyway
10:39:38 <heycam> EE: so we and i18n group recommend it be removed
10:39:58 <heycam> DS: i'm concerned that if we design things for tiny that doesn't apply to full it'll cause trouble
10:40:06 <heycam> ED: the text i suggested will be workable for full going forward
10:40:12 <fantasai> not precise and also wrong
10:40:20 <heycam> ED: for glyph orientation i agree it's incorrect so it should be removed
10:40:24 <heycam> DS: we need to revisit it for full
10:40:43 <heycam> ACTION: erik to add the suggested direction property text
10:40:44 <trackbot> Created ACTION-2342 - Add the suggested direction property text [on Erik Dahlström - due 2008-11-06].
10:40:57 <Zakim> +??P6
10:41:41 <anthony> Zakim, ??P6 is me
10:41:41 <Zakim> +anthony; got it
10:41:44 <heycam> Topic: ISSUE-2083
10:41:46 <heycam> ISSUE-2083?
10:41:46 <trackbot> ISSUE-2083 -- Paced animation and complex types -- RAISED
10:41:46 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2083
10:43:38 <heycam> CM: i made a change to clean up the wording for the paced animation stuff
10:44:05 <heycam> CM: and olaf replied saying that in the cleanup i shouldn't have taken out the wording about vector/scalar
10:44:18 <heycam> CM: so i replied to him with suggested wording to put it back in (reworded)
10:44:21 <heycam> CM: waiting to hear back from him
10:44:34 <heycam> http://www.w3.org/mid/20081030011021.GC25338@arc.mcc.id.au
10:47:59 <heycam> Topic: ISSUE-2085
10:48:02 <heycam> ISSUE-2085?
10:48:02 <trackbot> ISSUE-2085 -- Spec unclear where focus should initially go when a document is loaded -- OPEN
10:48:02 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2085
10:48:10 <fantasai> ED, http://lists.w3.org/Archives/Public/www-svg/2008Oct/0243.html
10:48:27 <heycam> NH: i couldn't find a nice way to support both alternatives for initial focus
10:48:33 <heycam> NH: i thought maybe it could be a little unclear
10:48:58 <heycam> NH: i think we can leave it as it is, actually
10:49:00 <heycam> ED: i agree
10:49:14 <heycam> DS: can you send a mail saying that
10:49:40 <heycam> Topic: ISSUE-2089
10:49:45 <heycam> ISSUE-2089?
10:49:45 <trackbot> ISSUE-2089 -- animateTransform and underlying value -- RAISED
10:49:45 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2089
10:51:24 <heycam> CM: no response yet
10:51:34 <shepazu> http://dev.w3.org/SVG/profiles/1.2T/doc-svgt12.html
10:52:03 <heycam> Topic: ISSUE-2106
10:52:05 <heycam> Topic: ISSUE-2107
10:53:18 <heycam> ISSUE-2107?
10:53:18 <trackbot> ISSUE-2107 -- i18n comment 6: Direction and bidi-override attributes -- OPEN
10:53:18 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2107
10:54:07 <ed> http://lists.w3.org/Archives/Public/www-svg/2008Oct/0213.html
10:54:10 <heycam> EE: doug proposed wording and someone else supplied an example
10:54:41 <heycam> ED: are the examples necessary for us to continue?
10:54:52 <heycam> DS: we could just put it into the test suite
10:55:04 <heycam> ED: i think it's more important to do the wording first, and worry about the examples later
10:55:12 <heycam> DS: i want to add an example of how you use it, a template
10:55:47 <heycam> DS: 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
10:55:53 <heycam> DS: and i put that in a tspan
10:56:00 <heycam> DS: with what we've said about a tspan, would that still work?
10:57:22 <heycam> DS: it wouldn't hurt to be a bit more explicit
10:57:27 <heycam> EE: for the tspan you need the embed
10:57:43 <heycam> DS: for someone who wants to use arabic in svg, i want to have a template for them to do it easily
10:58:04 <heycam> EE: you don't need unicode-bidi on the root
10:58:08 <heycam> EE: you definitely need it on the tspan
10:58:40 <fantasai> <svg direction="rtl"> ... <text>ARABIC TEXT <tspan unicode-bidi="emped">English quote.</tspan> ARABIC TEXT.</text></svg>
10:58:44 <heycam> DS: so i would have a paragraph (a text) within which is a tspan, and that tspan has a direction and bidi override
10:59:04 <heycam> DS: is there a canonical example of something people normally quote?
10:59:15 <heycam> DS: a hebrew/arabic quote that has some english in it?
10:59:55 <heycam> EE: i have mixed arabic/chinese, but not arabic/english
11:00:04 <heycam> EE: you could ask the guy who gave you the example
11:01:18 <heycam> EE: for embed, i generally only makes a difference if there's punctuation, characters in there that aren't strongly ltr
11:01:30 <heycam> EE: in the example ori gave, the english is just work so you don't need the properties
11:01:36 <fantasai> I forgot the direction="ltr" in my example, btw
11:01:38 <fantasai> don't forget it!
11:01:41 <heycam> s/work/one word/
11:03:12 <heycam> Topic: ISSUE-2106
11:03:14 <heycam> ISSUE-2106?
11:03:15 <trackbot> ISSUE-2106 -- i18n comment 5: Characters and glyphs -- RAISED
11:03:15 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2106
11:03:50 <heycam> DS: richard should be getting back to us on that
11:04:36 <Zakim> -fantasai
11:05:05 <shepazu> thanks, fantasai!!
11:05:35 <heycam> ED: i think the other 18n comments are just waiting for someone to responsd
11:05:37 <heycam> s/responsd/respond/
11:05:39 <Zakim> +??P4
11:06:30 <anthony> Zakim, ??P4 is fantasai
11:06:30 <Zakim> +fantasai; got it
11:06:31 <ed> http://lists.w3.org/Archives/Public/www-svg/2008Oct/0231.html
11:06:53 <heycam> Topic: Inheritance of display-align
11:07:32 <heycam> ED: the thing with new wording is not very complex
11:07:40 <heycam> ED: just flipping display-align property to not inherit
11:07:45 <heycam> ED: of course there are larger implications for implementations
11:07:53 <ed> http://lists.w3.org/Archives/Public/www-svg/2008Oct/0242.html
11:07:56 <heycam> ED: so i did some response to this here
11:08:08 <heycam> ED: currently we do inherit the display-align property
11:08:20 <heycam> ED: sometimes that's useful if you want to have several textAreas inside a group, and the same alignment on all of them
11:08:37 <heycam> ED: the problem css has with it being inherited is that text blocks can nest in css
11:08:46 <heycam> ED: but we can't nest textAreas in svg tiny so we don't have that problem
11:08:54 <heycam> ED: i think that it wouldn't be such a big problem to specify display-align on the places that need them
11:09:05 <heycam> ED: if that helps css and if that makes css able to use the same property i think that would be very good
11:09:21 <heycam> DS: as an author, how many textAreas am i going to have?
11:09:35 <heycam> DS: if svg is for precision display, not for bulk document display, at least in terms of text
11:09:43 <heycam> ED: so far i haven't seen many documents using several textAreas like that
11:09:49 <heycam> ED: at most i've seen 3 or 5 in a document
11:09:53 <heycam> ED: so it's not like it's a big problem
11:09:57 <heycam> ED: to specify on each
11:10:01 <heycam> DS: i agree
11:10:30 <heycam> EE: the related issue is that the name of the properties or the values are that intuitive
11:10:36 <heycam> EE: second, making it not inherit would make it incompatible with XSL
11:10:47 <heycam> DS: do we get this from xsl?
11:10:48 <heycam> EE: yes
11:10:56 <heycam> DS: they have it inherit?
11:11:00 <heycam> EE: that's what i recall, but i'll check
11:11:25 <heycam> DS: that's more of a problem
11:11:31 <ed> http://www.w3.org/TR/xsl/#display-align
11:11:44 <heycam> EE: in svg tiny it's an attribute or a property?
11:11:45 <heycam> ED: a property
11:11:58 <heycam> DS: you're thinking of making something similar?
11:11:58 <heycam> EE: yes
11:12:15 <heycam> DS: is it possible to keep this as to align with xsl, then for you to name yours differently?
11:12:25 <heycam> DS: and then going forward we'll use your name and values for svg core?
11:12:38 <heycam> DS: where svg core is the next version of the language
11:12:45 <heycam> EE: would it make sense to restrict this to just be an attribute in tiny?
11:13:07 <heycam> 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
11:13:15 <heycam> EE: that would avoid putting the property into the css parser
11:13:30 <heycam> ED: it would affect us, we've put it as a css property currently
11:13:53 <heycam> ED: there could be alternatives for css, maybe introducing something that says you don't use this property unless some other property is set
11:14:02 <heycam> ED: don't know whether introducing a new property block-align or something is better
11:14:57 <heycam> EE: we do require having an auto value, and we can say block-align:auto it means look at svg's display-align
11:15:44 <heycam> 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
11:16:03 <heycam> 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
11:16:10 <heycam> DS: i don't think we would change this one
11:16:17 <heycam> DS: we can't step on xsl any more than we can step on css
11:16:29 <heycam> DS: we could deprecate this if we found that the css one makes more sense in a larger context
11:16:35 <heycam> DS: i'll raise an issue on core
11:17:50 <fantasai> Given that you already have implementations, and given the above, I'm ok with deferring it to later.
11:25:29 <heycam> Topic: ISSUE-2093
11:25:32 <heycam> ISSUE-2093?
11:25:33 <trackbot> ISSUE-2093 -- 16.2.9 by 'identity' -- RAISED
11:25:33 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2093
11:26:02 <heycam> http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0118.html
11:28:29 <heycam> http://www.w3.org/mid/200810291536.31967.Dr.O.Hoffmann@gmx.de
11:28:47 <heycam> http://www.w3.org/mid/20081030023403.GE25338@arc.mcc.id.au
11:29:15 <heycam> CM: olaf seems unhappy with the text added about zero values
11:29:26 <heycam> CM: i replied (basically) saying that i think the text is ok
11:32:35 <heycam> DS: i say we punt on this and do as he asks (remove the table and sentence)
11:33:40 <heycam> CM: ok, i think it's better to have it in there, but acceptable to remove it
11:33:56 <heycam> ACTION: Cameron to perform the removal olaf asks and reply
11:33:56 <trackbot> Created ACTION-2343 - Perform the removal olaf asks and reply [on Cameron McCormack - due 2008-11-06].
11:34:02 <heycam> Topic: ISSUE-2094
11:34:08 <heycam> ISSUE-2094?
11:34:09 <trackbot> ISSUE-2094 -- accessing rules for traitAccess -- RAISED
11:34:09 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2094
11:35:01 <ed> http://lists.w3.org/Archives/Public/www-svg/2008Oct/0223.html
11:35:10 <heycam> ED: last mail in the thread is from andrew
11:35:17 <heycam> AE: he said he agreed
11:35:29 <heycam> AE: but there were two parts to his question after some discussion
11:35:43 <heycam> AE: then he says, can you just do something about erik's question?
11:35:48 <heycam> AE: i said we'd discuss it and get back to him
11:36:07 <heycam> AE: he is talking about whether it's unspecified if we modify an xml:id attribute that is the on the target of an animation
11:36:30 <heycam> AE: he says there's no restriction on modifying xml:id when it's in the tree
11:36:33 <heycam> AE: i kinda agree with that
11:36:44 <heycam> AE: if we haven't specified it, any implementor would've picked one of the three options
11:37:00 <heycam> AE: but i think he's already satisfied, but it's a courtesy for us to make a decision on it
11:37:26 <heycam> ED: i think it's partially defined in smil, but i'm not exactly sure
11:37:35 <heycam> ED: hte begin attribute evaluation, it's not really defined when it happens
11:37:37 <heycam> s/hte/the/
11:37:50 <heycam> ED: adding a section to say that if you change xml:id when animations target those elements, the behaviour would be UA dependent
11:37:54 <heycam> ED: that'd be a simple way to resolve it
11:37:55 <Zakim> -fantasai
11:37:58 <heycam> AE: yes that's perfect
11:39:57 <fantasai> fantasai has left #svg
11:40:20 <heycam> ACTION: Cameron to add the sentence ED suggests here in the minutes, and reply to Julien
11:40:20 <trackbot> Created ACTION-2344 - Add the sentence ED suggests here in the minutes, and reply to Julien [on Cameron McCormack - due 2008-11-06].
11:40:59 <heycam> ACTION-2344: say please respond immediately, or actually it seems he's satisfied already so just to let him know
11:40:59 <trackbot> ACTION-2344 Add the sentence ED suggests here in the minutes, and reply to Julien notes added
11:42:39 <shepazu> Topic: ISSUE-2085 
11:42:55 <shepazu> Spec unclear where focus should initially go when a document is loaded
11:44:37 <heycam> Topic: ISSUE-2147
11:44:40 <heycam> ISSUE-2147?
11:44:40 <trackbot> ISSUE-2147 -- Section on externally referenced documents confusing -- OPEN
11:44:40 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2147
11:44:51 <heycam> ED: i'd like to change some of the wording [of cameron's suggested text]
11:45:19 <heycam> ED: the current spec/proposed text says if you have an svg document fragment, like several fragments inline in an XHTML file
11:45:26 <heycam> ED: then each of the document fragments are separate primary documents
11:45:40 <heycam> ED: that's fine, but the para after mentions that primary documents have a map of IRIs to resource documents
11:45:54 <heycam> ED: if svg fragments cannot share the same resources, it takes more processing
11:46:10 <heycam> ED: e.g. if you have 10 svg fragments each <use>ing the same thing, would you want that to load 10 different resources?
11:46:16 <heycam> DS: this is a conceptual model, right?
11:46:23 <heycam> ED: i think it's too much requirements here
11:46:39 <heycam> ED: i'd prefer a may to be in there
11:46:42 <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.
11:46:44 <heycam> CM: i wouldn't
11:46:58 <heycam> 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
11:47:05 <heycam> ED: another would be to say the primray document is the document itself
11:47:24 <heycam> ED: that would make the enclosing document be the primary document, so that resources could be shared between fragments
11:49:05 <ed> so, change cam's wording "Each primary document maintains a dictionary that maps IRIs " to "Each document maintains a dictionary that maps IRIs "
11:49:58 <heycam> ED: cameron you can incorporate my change and mail out new suggested wording
11:50:03 <heycam> ED: i agree with the rest of the rewording
11:50:08 <heycam> ED: this is an issue on the current spec wording too
11:51:16 <heycam> ACTION: Cameron to incorporate Erik's suggestion into the proposal and add it to the spec
11:51:17 <trackbot> Created ACTION-2345 - Incorporate Erik's suggestion into the proposal and add it to the spec [on Cameron McCormack - due 2008-11-06].
11:54:49 <ed> DS: tooltip started as tooltip, but morphed to a popup
11:55:01 <ed> ...the word tooltip has come to mean a little popup
11:55:10 <ed> ...and it's used in that sense
11:55:23 <ed> ...not in the sense of a contexthelp
11:55:31 <ed> ...there's nothing in ARIA that is equivalent
11:55:48 <ed> ...the vlaue of contexthelp in role, as proposed, has nothing to do with behaviour
11:55:58 <ed> ...it only maps it to being contexthelp
11:56:12 <ed> CM: i agree with that, but that's not what the spec says
11:56:24 <ed> ...shouldn't force the UA to act on this role
11:57:06 <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
11:57:17 <ed> DS: yes, and you'd use script or something to hide or show it
11:57:38 <ed> CM: right, but for contexthelp [sorry missed stuff here]
11:58:13 <ed> DS: ARIA doesn't add automatic behavior, only adds semantics
11:58:34 <ed> ...you don't have to use contexthelp like described in the spec
11:58:50 <ed> ...we're going to run into this problem anyway
11:59:00 <ed> ...people are going to start using role to add behavior
11:59:23 <ed> CM: if your language doesn't have something the AT can understand, you can fake it by using role
11:59:32 <ed> ...and do some graphical thing
12:00:04 <ed> DS: getting people to use aria is that they get some reward
12:00:22 <ed> CM: right, yes, you get some benefit plus the accessibility
12:00:32 <ed> ...but I think there should be a contexthelp element instead
12:00:43 <ed> ...so you don't have to annotate it
12:01:22 <Zakim> -aemmons
12:01:29 <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
12:01:39 <ed> ...i think they should be derivable from role
12:02:25 <ed> CM: my ideal solution would be to have a contexthelp element, and have a role to map that
12:02:31 <ed> DS: i think that's overkill
12:02:49 <ed> ...whether it's an element or a role that has the behavior
12:02:57 <ed> CM: no other role has that trait
12:03:38 <ed> DS: at the moment role doesn't add behaviors in other aria specs 
12:03:43 <ed> ...but it's going to happen
12:03:54 <ed> CM: ok, if that's going to happen
12:04:07 <ed> DS: we can't add a contexthelp element at this point
12:04:12 <ed> CM: right
12:04:23 <ed> ...that's how I feel about contexthelp too
12:04:36 <ed> DS: more comfortable if it was a recommendation?
12:04:48 <ed> CM: not sure if that's enough
12:05:03 <NH> Sorry, I have to quit, bye
12:05:13 <Zakim> -NH
12:05:28 <ed> DS: isn't this similar to tooltips?
12:05:40 <ed> ...I think adding behavior based on role helps accessibility
12:05:47 <ed> ...ppl will use it when they wouldn't before
12:06:35 <ed> CM: agreed, but I think it's problematic because it's adding behavior
12:06:49 <ed> DS: the accessibility ppl seemed to like this
12:07:09 <ed> ...talked to Al Gilman
12:07:30 <ed> ...he agreed that it'd be better if it was an element, but he was ok with it being a role
12:07:49 <ed> ...aaron leventhal raised the same objection as CM
12:08:03 <ed> ...everyone else thought it was good to promote the use of aria
12:08:32 <ed> CM: ok, so if accessibility ppl are ok with it, what do we do with UA:s that don't implement the behavior
12:11:23 <ed> Zakim, who's here?
12:11:23 <Zakim> On the phone I see Doug_Schepers, ed, heycam, anthony
12:11:26 <Zakim> On IRC I see RRSAgent, ed, heycam, shepazu, anthony, ed_work, NH, trackbot
12:13:08 <Zakim> -ed
12:13:11 <Zakim> -heycam
12:13:13 <Zakim> -Doug_Schepers
12:13:14 <Zakim> -anthony
12:13:15 <Zakim> GA_SVGWG()6:30AM has ended
12:13:17 <Zakim> Attendees were Doug_Schepers, ed, heycam, aemmons, fantasai, NH, anthony
12:13:47 <anthony> Zakime, bye
12:13:55 <anthony> Zakim, bye
12:13:55 <Zakim> Zakim has left #svg
12:14:16 <ed> rrsagent, make minutes
12:14:16 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/30-svg-minutes.html ed
13:46:23 <ed> ed has joined #svg
13:50:43 <ed_work> trackbot, close ACTION-2342
13:50:43 <trackbot> ACTION-2342 Add the suggested direction property text closed
13:53:40 <shepazu> shepazu has joined #svg
15:24:20 <ed_work> shepazu: if you want you can update the DoC (ISSUE-2058), since I completed ACTION-2342