- From: Erik Dahlstrom <ed@opera.com>
- Date: Thu, 30 Oct 2008 13:15:43 +0200
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Minutes in html format:
http://www.w3.org/2008/10/30-svg-minutes.html
or as text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
30 Oct 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0313.html
See also: [3]IRC log
[3] http://www.w3.org/2008/10/30-svg-irc
Attendees
Present
Doug_Schepers, ed, heycam, aemmons, fantasai, NH, anthony
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Cameron
Contents
* [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
ISSUE-2058
ISSUE-2058?
<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
agree
... we do have a sentence in the spec atm about the direction
attribute, borrowed from 1.1
ED reads out the sentence
<ed>
[20]http://lists.w3.org/Archives/Public/www-svg/2008Oct/0241.html
[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
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
[21]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> [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
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
[23]http://www.w3.org/mid/20081030011021.GC25338@arc.mcc.id.au
[23] 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> [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
[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
ISSUE-2089
ISSUE-2089?
<trackbot> ISSUE-2089 -- animateTransform and underlying value --
RAISED
<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
ISSUE-2106
ISSUE-2107
ISSUE-2107?
<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
<ed>
[29]http://lists.w3.org/Archives/Public/www-svg/2008Oct/0213.html
[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
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> [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
respond
<ed>
[31]http://lists.w3.org/Archives/Public/www-svg/2008Oct/0231.html
[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
<ed>
[32]http://lists.w3.org/Archives/Public/www-svg/2008Oct/0242.html
[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
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> [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
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> [34]http://www.w3.org/Graphics/SVG/WG/track/issues/2093
[34] http://www.w3.org/Graphics/SVG/WG/track/issues/2093
[35]http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/011
8.html
[35]
http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0118.html
[36]http://www.w3.org/mid/200810291536.31967.Dr.O.Hoffmann@gmx.de
[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
[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
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
[38]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> [39]http://www.w3.org/Graphics/SVG/WG/track/issues/2094
[39] http://www.w3.org/Graphics/SVG/WG/track/issues/2094
<ed>
[40]http://lists.w3.org/Archives/Public/www-svg/2008Oct/0223.html
[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
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
[41]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> [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
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
[43]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
Summary of Action Items
[NEW] ACTION: Cameron to add the sentence ED suggests here in the
minutes, and reply to Julien [recorded in
[44]http://www.w3.org/2008/10/30-svg-minutes.html#action03]
[NEW] ACTION: Cameron to incorporate Erik's suggestion into the
proposal and add it to the spec [recorded in
[45]http://www.w3.org/2008/10/30-svg-minutes.html#action04]
[NEW] ACTION: Cameron to perform the removal olaf asks and reply
[recorded in
[46]http://www.w3.org/2008/10/30-svg-minutes.html#action02]
[NEW] ACTION: erik to add the suggested direction property text
[recorded in
[47]http://www.w3.org/2008/10/30-svg-minutes.html#action01]
[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
/scribe/
[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
ony
Present: Doug_Schepers ed heycam aemmons fantasai NH anthony
Agenda: [51]http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDe
c/0313.html
[51]
http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0313.html
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