SVG Working Group Teleconference -- 10 Jan 2013

<trackbot> Date: 10 January 2013

<krit> "G'day"

<scribe> scribenick: nikos

SVGDefinitionElement

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

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

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> 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="http://www.w3.org/2000/svg"><circle+r="100"+title="blah"/></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

- DRAFT -

SVG Working Group Teleconference

10 Jan 2013

Attendees

Contents

SVGDefinitionElement

animateMotion on shapes

xml{base,lang,space} IDL attributes

ARIA markup

Summary of Action Items

Scribe.perl diagnostic output