SVG Working Group Teleconference -- 30 Oct 2008

<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

ISSUE-2058

ISSUE-2058?

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

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

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

ED reads out the sentence

<ed> 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 here
... 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 tiny
... 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 different
... 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 removed

DS: we need to revisit it for full

<scribe> ACTION: erik to add the suggested direction property text [recorded in http://www.w3.org/2008/10/30-svg-minutes.html#action01]

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

ISSUE-2083

ISSUE-2083?

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

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

CM: i made a change to clean up the wording for the paced animation stuff
... 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 (reworded)
... waiting to hear back from him

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

ISSUE-2085

ISSUE-2085?

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

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

<fantasai> ED, 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

ISSUE-2089

ISSUE-2089?

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

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

CM: no response yet

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

ISSUE-2106

ISSUE-2107

ISSUE-2107?

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

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

<ed> 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 TEXT.</text></svg>

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!

ISSUE-2106

ISSUE-2106?

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

<trackbot> 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 respond

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

<ed> 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 problem
... 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 XSL

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> 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 core?
... where svg core is the next version of the language

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

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 set
... 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.

ISSUE-2093

ISSUE-2093?

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

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

http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0118.html

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

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 sentence)

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 http://www.w3.org/2008/10/30-svg-minutes.html#action02]

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

ISSUE-2094

ISSUE-2094?

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

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

<ed> 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 happens
... adding a section to say that if you change xml:id when animations target those elements, the behaviour would be UA dependent
... 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 http://www.w3.org/2008/10/30-svg-minutes.html#action03]

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

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

ISSUE-2085

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

ISSUE-2147

ISSUE-2147?

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

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

ED: i'd like to change some of the wording [of cameron's suggested text]
... 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 documents
... 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 processing
... 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 itself
... 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 wording
... 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 http://www.w3.org/2008/10/30-svg-minutes.html#action04]

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

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

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

<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

- DRAFT -

SVG Working Group Teleconference

30 Oct 2008

Attendees

Contents

LC comments

ISSUE-2058

ISSUE-2083

ISSUE-2085

ISSUE-2089

ISSUE-2106

ISSUE-2107

ISSUE-2106

Inheritance of display-align

ISSUE-2093

ISSUE-2094

ISSUE-2085

ISSUE-2147

Summary of Action Items

Scribe.perl diagnostic output