- From: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>
- Date: Fri, 11 Jan 2013 09:48:45 +1100
- To: <www-svg@w3.org>
http://www.w3.org/2013/01/10-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
10 Jan 2013
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2013JanMar/0001.html
See also: [3]IRC log
[3] http://www.w3.org/2013/01/10-svg-irc
Attendees
Present
Regrets
Chair
ed
Scribe
nikos
Contents
* [4]Topics
1. [5]SVGDefinitionElement
2. [6]animateMotion on shapes
3. [7]xml{base,lang,space} IDL attributes
4. [8]ARIA markup
* [9]Summary of Action Items
__________________________________________________________
<trackbot> Date: 10 January 2013
<krit> "G'day"
<scribe> scribenick: nikos
SVGDefinitionElement
<ed>
[10]http://lists.w3.org/Archives/Public/www-svg/2012Dec/0097.ht
ml
[10] http://lists.w3.org/Archives/Public/www-svg/2012Dec/0097.html
heycam: When I was converting interfaces to WebIDL, I added
SVGDefinitionElement for all the elements which are like
definitions
... the only benefit it provides is it's a single place that
the SVGTest interface can go off
... SVGTest has the DOM properties for systemLanguage, etc
... it was pointed out to me that the clip_path element doesn't
have those attributes on it
... if that's the case, maybe it's not worth having it in the
first place
... maybe it's better implementing SVGTests directly on
elements that need it
ed: I think that makes sense
heycam: it does bring up the question of clippath not having
these conditional processing attributes
... do we want to change that?
krit: for pattern, mask, etc. We have to distinguish between
pattern units, etc, we don't have to do that for clippath. I
think it's hard to align clippath with the other elements
anyway.
<heycam>
[11]https://svgwg.org/svg2-draft/struct.html#ConditionalProcess
ingOverview
[11] https://svgwg.org/svg2-draft/struct.html#ConditionalProcessingOverview
heycam: the spec currently says conditional processing
attributes have no effect on clippath and a variety of other
elements
... There are others that aren't mentioned, i.e. filter
... I just wanted to confirm that these kinds of elements would
remain not being affected by conditional processing attributes
ed: have you tested to see what implementations do with these?
... I wouldn't be surprised if it just happened to work because
of the way things are implemented, but I haven't tested
heycam: Opera seems to do the right thing, Mozilla does the
wrong thing
ed: I would think that if if you used conditional processing
attributes on patterns I would think it might work, as in such
attributes used inside the pattern, but perhaps not when used
on the <pattern> element itself
<heycam>
[12]http://lists.w3.org/Archives/Public/www-svg/2012Dec/0102.ht
ml
[12] http://lists.w3.org/Archives/Public/www-svg/2012Dec/0102.html
heycam: I think the current behaviour in the spec is fine, just
wanted to confirm
krit: is chrome following the spec?
heycam: it is for half the elements, but not the other half
... the ones that are explicitly mentioned in the spec, it's
doing the wrong thing for. For the ones that aren't mentioned
it's doing the right thing
resolution: Elements that conditional processing attributes
shall remain as is in the spec, we will clarify that gradient
and filter are also not affected.
animateMotion on shapes
<ed>
[13]http://lists.w3.org/Archives/Public/www-svg/2012Dec/0101.ht
ml
[13] http://lists.w3.org/Archives/Public/www-svg/2012Dec/0101.html
heycam: There is a thread on the list talking about
animateMotion applying to shapes other than path
... there didn't seem to be anyone who is against the idea and
I think it's reasonable simple.
<shepazu> +1
birtles: Cam, you just mentioned that supporting use might be
problematic but the others are fine
ed: I agree, use is more complex
... it would potentially be the same as allowing groups
shepazu: could we define it as well for groups?
... there's the document order for the group, effectively it's
the same as defining it for a path that has multiple 'm's
... I don't know how hard it would be to implement, but
defining is ok
ed: animating each of the sub elements would be fun
shepazu: that brings up another question, what happens if the
path is animating?
krit: it was demonstrated a couple of years ago at SVG Open -
it works
shepazu: if it was pointing at itself, what happens?
heycam: the thing pointing is mpath
... if you had it pointing to a group, the thing that is being
animated could be within that group as well
... the motion animation doesn't affect the link to the path
... it would affect the position
... lets do the simple features
ed: I agree, it might be nice to have more complex elements in
future, but we would need to think about it more
shepazu: I think the easiest for us is to not allow use, and we
can re-visit in future if there's a need
... shouldn't work for 'g' either, should only work on a single
shape
... doesn't address the problem of pointing to itself
... where the path being animated is the path being followed
heycam: I think we should check the spec to make sure we are
defining what happens in that situation
resolution: simple shapes such as circle, rect, etc, will be
supported by animateMotion. use and groups will not be
supported.
shepazu: I want to make sure, with the recursion question, that
pointing to paths or mutiple elements isn't any more of a
problem than with simple shapes
<richardschwerdtfeger> zakim +[IPCaller is Rich
<richardschwerdtfeger> zakim [IPCaller is Rich
ed: I don't think its harder to deal with recursion, we already
have loop detection algorithms that can be tweaked.
Implementation wise, tracking multiple elements is a bit more
work, so there is a cost.
<heycam> [14]http://mcc.id.au/temp/motion.svg
[14] http://mcc.id.au/temp/motion.svg
heycam: I think, looking at that, the animateMotion is only
looking at the base path
shepazu: did we decide whether the animation should be taken
into account when recursion is used?
heycam: I think it can't
note for the minutes: cam's file changed from animating along a
linear path to animating around a circular path
krit: maybe we could copy what clip path is defining in regards
to a set of objects
resolution: The element that mpath references should not look
at the motion animation of that element
<scribe> ACTION: Brian to ensure the specification explicitly
disallows the element that mpath references from looking at the
motion animation of that element [recorded in
[15]http://www.w3.org/2013/01/10-svg-minutes.html#action01]
<trackbot> Created ACTION-3408 - Ensure the specification
explicitly disallows the element that mpath references from
looking at the motion animation of that element [on Brian
Birtles - due 2013-01-17].
<scribe> ACTION: Brian to update SVG 2 specification to allow
simple shapes to be referenced by animateMotion [recorded in
[16]http://www.w3.org/2013/01/10-svg-minutes.html#action02]
<trackbot> Created ACTION-3409 - Update SVG 2 specification to
allow simple shapes to be referenced by animateMotion [on Brian
Birtles - due 2013-01-17].
xml{base,lang,space} IDL attributes
<ed>
[17]http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDe
c/0077.html
[17] http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDec/0077.html
heycam: FireFox currently doesn't implement the DOM properties
for these attributes
... somebody wrote a patch to implement them
... this made me wonder if we should implement all, or some,
because we are trying t move away from xml:space
... I think we want to keep the xml :space behaviour, but using
a white space property instead
shepazu: I don't agree that we should keep around xml: space
... I think we should deprecate the attribute
ed: we already agreed on that
heycam: but we keep the behaviour
... are you suggesting we removing processing the attribute
even if you do use it?
shepazu: why do we need to keep it?
heycam: a lot of people use it
shepazu: are we making SVG 2 into HTML5 where the behaviour of
SVG is the same. i.e. where SVG 2 is to SVG 1.1 what HTML 5 is
to HTML 4.
... I think the changes in SVG 2 are so profound (some change
existing SVG behaviour), and the effect of xml: space are
actually fairly rare. People use it, but the only thing it
means is don't get rid of the spaces
... I think the only place it has an effect is when you put in
multiple spaces and you want those kept in the content - not
collapsed
... so the only side effect of not supporting it is that white
space which before kept multiple spaces between letters will
now collapse down to a single space
... I don't think that's enough of a reason to keep it
krit: I'm fine with deprecating it, but not sure about removing
it. A lot of implementations support it
heycam: my suggestion was to handle xml space as a user style
sheet rule, so it gets mapped to an appropriate property value
... that would remove the need for special implementation for
it
... but would allow it to be used in content
shepazu: I would like to obsolete it and say user agents are
not required to do anything with it. If UAs want to behave like
SVG 1.1 they could
... but I don't think its that important
... we should at least deprecate it, which means we will still
define behaviour for it and authoring tools should still
implement it but authors shouldn't use it.
<scribe> ACTION: Cameron to investigate xml base, and other xml
attributes in the IDL and whether they're implemented [recorded
in [18]http://www.w3.org/2013/01/10-svg-minutes.html#action03]
<trackbot> Created ACTION-3410 - Investigate xml base, and
other xml attributes in the IDL and whether they're implemented
[on Cameron McCormack - due 2013-01-17].
ARIA markup
ARIA markup
<ed>
[19]http://lists.w3.org/Archives/Public/public-svg-wg/2013JanMa
r/0006.html
[19] http://lists.w3.org/Archives/Public/public-svg-wg/2013JanMar/0006.html
krit: I agree with the list in that email
... it's every element that has no content
heycam: I think theres a couple that might want ARIA markup
... like tspan
shepazu: title, metadata, desc
richardschwerdtfeger: desc is a description for something else
right?
shepazu: correct, it is a child of an element
richardschwerdtfeger: you wouldn't navigate to it or anything
... the criteria we used is in the post
shepazu: I thought with ARIA you define the behaviour in the
DOM
richardschwerdtfeger: the description would be applied to an
object and exposed as the description for that object
shepazu: there would be a native mapping of some SVG elements
to acce APIs and among those would be title and description
which would have a native mapping, they describe what they are
a child of. So we don't need to apply ARIA attributes to those
at all.
richardschwerdtfeger: correct
... SVG already has relationships that can be used already
shepazu: what about tspan?
richardschwerdtfeger: I understood that tspan doesn't include
content in your page, it is a reference within a span of text
heycam: it's a span element itself
richardschwerdtfeger: tspan should not be in the list then
ed: same for textpath as well
richardschwerdtfeger: We will remove tspan and textpath from
the list
shepazu: in SVG 1.2 tiny we said that you could apply the ARIA
property 'tooltip' to a title which was a child of an element
... that might give behaviour of providing a tooltip
<ed>
[20]http://www.w3.org/TR/SVGTiny12/struct.html#uiTitleDescBehav
ior
[20] http://www.w3.org/TR/SVGTiny12/struct.html#uiTitleDescBehavior
shepazu: maybe what we should do is not tie it to ARIA but tie
it to a CSS property so you can use hover
richardschwerdtfeger: by default, in HTML, the title attribute
will give you a tooltip
... does that happen in SVG?
krit: in some browsers it does
richardschwerdtfeger: it's nice for people with cognitive
impairments, but there's some situations where you don't want
to do that
... we have aria-label property, which Google asked for, which
is more specific
shepazu: I think the best way to define the behaviour is
through a CSS property
... title in HTML pretty reliably gives you a tooltip. In SVG
thats not the case, so there may be content out there that
assumes title has different behaviour
... my proposed solution is that we say title should be
displayed as a tooltip, but that you can control that in SVG
using display:none
... right now authors can't rely on the behaviour, we need to
specify the behaviour clearly
richardschwerdtfeger: why would people use titles that aren't
ever going to be visually rendered?
... the reason I'm asking is you could use aria-label which
computes to a name
shepazu: some people want to have metadata, particularly title
... I would say the title on the SVG root shouldn't not be
displayed
richardschwerdtfeger: I agree
shepazu: the behaviour I favour is to make the title of the
root element not appear as a tooltip, the title of anything
else does. Unless you apply css display:none
... I think that solves most cases
richardschwerdtfeger: that makes sense to me
<krit> <svg xmlns="[21]http://www.w3.org/2000/svg"
xmlns:xlink="[22]http://www.w3.org/1999/xlink">
[21] http://www.w3.org/2000/svg
[22] http://www.w3.org/1999/xlink
<krit> <rect width="100" height="100">
<krit> <title>TEST</title>
<krit> </rect>
<krit> </svg>
shepazu: I would go further and say, from an ARIA perspective,
title is always a label.
krit: with this example, FireFox and Opera show the tooltip
ed: I don't think display:none would affect it in Opera
heycam: I think we made title and desc styleable in SVG 2
... with the intention of it being used for something like this
<krit> krit: It seems to be styleable in SVG 1.1 also
heycam: I think display:none or the other values affect what
gets rendered inside the document, while the tooltip is outside
the document so it's a little disconcerting using display:none
richardschwerdtfeger: maybe we would need a different property?
shepazu: I was trying not to add extra properties
heycam: would this discussion affect whether aria attributes
would go on title?
shepazu: I think it doesn't, but has an inherent characteristic
<shepazu> [23]http://dabblet.com/gist/4506341
[23] http://dabblet.com/gist/4506341
Tav: question, ARIA things are attributes, but title is an
element. Is that ok?
richardschwerdtfeger: yes
Tav: FireFox will display a title attribute
heycam: are you thinking of xlink:title?
Tav: no, just title=
shepazu: that's because in HTML, if you put the title attribute
on an element it always displays as a tooltip
<heycam>
data:image/svg+xml,<svg+xmlns="[24]http://www.w3.org/2000/svg">
<circle+r="100"+title="blah"/></svg>
[24] http://www.w3.org/2000/svg
shepazu: it's not SVG behaviour but it's inheriting from HTML
Tav: there's a reason to use the element, at the last F2F we
made it internationalisable
shepazu: we should define what happens when there's a title
attribute on an element
richardschwerdtfeger: If you have an element that you want to
expose to assisted technology you can use the name or the
description. These properties are exposed to the API. For
performance reasons, I wouldn't map that to an accessibility
object unless you apply a role to it.
shepazu: We have addressed the issue of performance for title
... if the first element of a shape is not its title it is not
rendered as a tooltip and it should not map to the name of the
thing
... title has to be the first child of an element for it to be
the label
... and I would say that description has to be the second
... this helps resolve multiple titles, etc
richardschwerdtfeger: let me explain what I mean by performance
... the browser takes elements out of the DOM and creates
accessibility objects, this is a lot of load on the browser
... so unless the object has semantic meaning to the AT then
you probably don't want to map to an accessible object
... if you really want to support an AT, you want to apply a
role to it
shepazu: I think if we are worried about performance we should
define the behaviour in terms of parsing processing
... in general I would say that SVG does not have semantics,
but from the specification and the accompanying note is that
there is a strong semantic with title
... I'll make a proposal on the list for this
Summary of Action Items
[NEW] ACTION: Brian to ensure the specification explicitly
disallows the element that mpath references from looking at the
motion animation of that element [recorded in
[25]http://www.w3.org/2013/01/10-svg-minutes.html#action01]
[NEW] ACTION: Brian to update SVG 2 specification to allow
simple shapes to be referenced by animateMotion [recorded in
[26]http://www.w3.org/2013/01/10-svg-minutes.html#action02]
[NEW] ACTION: Cameron to investigate xml base, and other xml
attributes in the IDL and whether they're implemented [recorded
in [27]http://www.w3.org/2013/01/10-svg-minutes.html#action03]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [28]scribe.perl version
1.137 ([29]CVS log)
$Date: 2013-01-10 22:46:19 $
__________________________________________________________
[28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[29] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01
Check for newer version at [30]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/ patterns I would think it might work/ patterns I would thi
nk it might work, as in such attributes used inside the pattern, but per
haps not when used on the <pattern> element itself/
Succeeded: s/fillpath/filter/
Succeeded: s/simpmle/simple/
Succeeded: s/cant'/can't/
Found ScribeNick: nikos
Inferring Scribes: nikos
WARNING: No "Present: ... " found!
Possibly Present: Doug_Schepers IPcaller Tav aaaa aabb birtles cabanier
data ed heycam https joined krit nikos richardschwerdtfeger scribenick s
hepazu svg trackbot
You can indicate people for the Present list like this:
<dbooth> Present: dbooth jonathan mary
<dbooth> Present+ amy
Agenda: [31]http://lists.w3.org/Archives/Public/public-svg-wg/2013JanMar
/0001.html
Found Date: 10 Jan 2013
Guessing minutes URL: [32]http://www.w3.org/2013/01/10-svg-minutes.html
People with action items: brian cameron
[31] http://lists.w3.org/Archives/Public/public-svg-wg/2013JanMar/0001.html
[32] http://www.w3.org/2013/01/10-svg-minutes.html
End of [33]scribe.perl diagnostic output]
[33] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Thursday, 10 January 2013 22:49:19 UTC