IRC log of svg on 2008-10-30

Timestamps are in UTC.

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