SVG Working Group Teleconference -- 16 Apr 2015

<trackbot> Date: 16 April 2015

<smailus> afk for bio break

<scribe> scribeNick: ed

stroke-dasharray="0"

https://lists.w3.org/Archives/Public/www-svg/2015Apr/0001.html

ABR: there was a inconsistency between firefox and the other browsers when you had stroke-dasharray=0
... comes down to some unclear prose
... spec said should be treated as a value of none was specified, but it was unclear where that meant for the stroke or for stroke-dasharray
... <reads proposed text>
... so still draw the stroke, but don't dash it
... Robert Longson was happy with the proposed wording
... so, can we resolve on doing that clarification?

All: yes

<scribe> ACTION: AmeliaBR to clarify the wording around stroke-dasharray=0 to say that that means draw the stroke but don't dash it [recorded in http://www.w3.org/2015/04/16-svg-minutes.html#action01]

<trackbot> Created ACTION-3777 - Clarify the wording around stroke-dasharray=0 to say that that means draw the stroke but don't dash it [on Amelia Bellamy-Royds - due 2015-04-23].

meeting at TPAC?

DS: it's in Sapporo, Japan
... we need to let the planners know if SVGWG is meeting, by apr 30
... and we don't want to meet with days overlapping with CSS
... who here will attend?

Rossen: we're going to have somebody there, probably me and maybe bogdan
... will attend CSS too

ED: will go if SVG is meeting

DS: will go

BB: I expect I'll go

<TabAtkins> I'm attending.

<stakagi> will go

Tav: I'll probably not go, too expensive for two days

TPAC is 26-30 Oct 2015

DS: does anyone think we shouldn't meet at tpac?

DS: thu-fri is typically when svg meets
... might be a bit crowded, but no problem
... assuming people in the group will attend CSS too, so we shouldn't have overlap

Rossen: maybe FXTF too?

DS: will we have one?

Rossen: sure, if there are things to discuss
... assuming it'll happen on wednesday
... or perhaps take some time from the css or svg meeting

<scribe> ACTION: ed to respond to the TPAC organizers saying SVG will meet at TPAC 2015 [recorded in http://www.w3.org/2015/04/16-svg-minutes.html#action02]

<trackbot> Created ACTION-3778 - Respond to the tpac organizers saying svg will meet at tpac 2015 [on Erik Dahlström - due 2015-04-23].

SVG 2 open issue discussion

https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment

Rossen: orthogonal question, some chapter are assigned to Dirk, anyone know if he's still active in the group, and if he's going to work on the things he's assigned?
... if not, we should divvy up the chapters on other ppl

DS: he hasn't been on the calls recently

AmeliaBR: he's been active on the list

Rossen: ok, moving on to the issues then

chapter 19, extensibility

<Rossen> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Extensibility_.28Rossen.29

<AmeliaBR> https://svgwg.org/svg2-draft/extend.html#issue2

AmeliaBR: issue 2 and 3, it's not specific to foreignObject
... going to come up all over the svg dom
... what to do with the attributes we turned into presentation attributes, has to be done consistently across the board

Rossen: sounds good
... I believe the issues were raised in the wrong part of the spec
... not specific to FO itself
... I woudln't expect anythign special here

BB: the only thing that might be different
... maybe because it's not used so much we could make them domstrings

AmeliaBR: I'd advise caution there
... ppl also expect things to work the same way

BB: ppl probably don't use animVal for width and height on a FO

Rossen: but what makes FO special here?

BB: if the APIs aren't used (much) it'd be nicer to be able to simplify things

ED: I'm fine with moving this to whatever chapter needs to deal with this, I agree that the extensibility chapter shouldn't do it alone

Rossen: fine with moving it to the proper chapter

DS: might be useful to raise an issue in ext chapter about other ways to embed html
... we should raise such an issue here as a placeholder

AmeliaBR: iframe and foreignObject have similarities

DS: maybe those two chapters should simply be merged

AmeliaBR: there's a difference in linking vs embedding, but merging might make sense

DS: I wouldn't look for FO in an extensibility chapter

Rossen: I can merge those chapters if that's what we want to do
... I see that in embedded content chapter, there are other examples of x,y,width,height presentation attributes

<scribe> ACTION: Rossen to merge the embedded content and extensibility chapters (removing the ext chapter) [recorded in http://www.w3.org/2015/04/16-svg-minutes.html#action03]

<trackbot> Created ACTION-3779 - Merge the embedded content and extensibility chapters (removing the ext chapter) [on Rossen Atanassov - due 2015-04-23].

animations chapter

Rossen: three issues needing discussion

<Rossen> https://svgwg.org/svg2-draft/animate.html#issue2

AmeliaBR: what is #xC?

Tav: it's form feed

AmeliaBR: consistency is good

ED: so, I did some changes to the types chapter to align what is considered "whitespace" across svg, html and css
... it was previously referenced from here (I think)
... the types chapter is referencing css now, so automatically is aligned with that
... I think the animations chapter should use the same definition of whitespace

Rossen: ok, sounds good, point to css definition of whitespace

RESOLUTION: align what is considered whitespace in animations chapter with CSS, by referencing css' definition of whitespace

<scribe> ACTION: Rossen to reference CSS' definition of whitespace for the S production in the animations chapter (issue 2) [recorded in http://www.w3.org/2015/04/16-svg-minutes.html#action04]

<trackbot> Created ACTION-3780 - Reference css' definition of whitespace for the s production in the animations chapter (issue 2) [on Rossen Atanassov - due 2015-04-23].

<Rossen> https://svgwg.org/svg2-draft/animate.html#issue8

Rossen: this is unclear to me
... should we reference the transform property, or what is this about?

<TabAtkins> The CSS definition of whitespace is at http://dev.w3.org/csswg/css-syntax/#whitespace

<TabAtkins> (Note that u+000c is processed out during preprocessing, and so doesn't show up in the definition explicitly. There's a note covering this.)

BB: not sure who added this, but maybe that you can use the regular animate element to animate transform

AmeliaBR: I think the immidiate issue is to just change the text, so that animateTransform refers to the transform style property as well as the attribute

BB: I'm adressing this chapter top-to-bottom, so not sure we need to talk about this yet

Rossen: the rest are mostly editorial

BB: I've been working on this chapter

<Rossen> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Animation_.28Rossen.29

Rossen: the reason why the animation chapter had my name next to it, happy to give it back to you brian
... so for issue 8, add the reference to transform property and then deprecate?

<Rossen> https://svgwg.org/svg2-draft/animate.html#issue8

BB: just needs to be updated to talk about the transform property

<Rossen> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Animation_.28Brian.29

Rossen: ok, I did reflect this in the chapter assessment, and assigned Brian the animation chapter

deprecating xlink:href

BB: there are three questions I have around this
... first, animated interfaces
... since we're not going ahead with heycam's new dom
... if that's the case, then the href IDL attributes point to an SVGAnimatedString
... and if they're not used much
... to replace them with plain domstring

ED: I landed a patch in blink today for measuring the usage of href.baseVal and href.animVal, we'll have to wait a bit for the results

<AmeliaBR> Q: What interface makes xlink:href available as an animated string?

BB: For <image>, <script> we resolved to add the src attribute. Does setting the href IDL attribute update src?

the xlink:href interface is called SVGURIReference

<birtles> https://svgwg.org/svg2-draft/types.html#InterfaceSVGURIReference

BB: i updated the definitions there
... not sure if you have animations
... maybe you should always update href if animating

<birtles> i.e. even if it explicitly animates attributeName="xlink:href" should it just animate "href" anyway?

AmeliaBR: what is the current language for href? which takes preference if both src and href specified?

Rossen: document order?

BB: what do you mean?

Rossen: last one overrides

AmeliaBR: but attributes aren't ordered
... parsers don't keep track of the order the attributes are in

DS: ok, rossen you're right to have a single attr do the same thing
... but the situation is that svg got it wrong, svg was defined in -99, so svg went with consistency with something that didn't take off
... my opinion: make href an alias for src, and if both present src takes precedence
... both map to src
... we ran into similar problem, barename href vs xlink:href.... we decided it should default to href
... in this case we're saying href should default to src

Rossen: any precedent in html?

DS: don't think so

Rossen: other question: if we say src is the primary one and the href is secondary, how do you deal with invalid values and fallback

DS: src should be authoriative

Rossen: but we're talkign about tools that sometimes screw up content

BB: barename href vs xlink:href, we should ignore xlink:href if we see a barename href

AmeliaBR: sounds good

<TabAtkins> I say no fallback. If src is present, it's used, regardless of whether it's "wrong" or whatever.

AmeliaBR: not sure what the original resolution was

<TabAtkins> Yeah, what BB said.

AmeliaBR: if we're making <image> to use src that will trigger behaviours in older browsers
... will be handled as html:img

<birtles> http://www.w3.org/2012/09/19-svg-minutes.html#item05

BB: pasted link to the last discussion we had about this

AmeliaBR: I think we shouldn't ruin the src fallback "hack"

<TabAtkins> We're talking *very* old browsers that don't understand <svg> at all. It's not a big deal.

AmeliaBR: if we gave src a meaning in svg it'll break the html fallback

DS: content validation might help a bit

<AmeliaBR> TabAtkins: 5-6% of web site visits in the US are on IE8- or Android 2.3-

<TabAtkins> Let's encourage them to upgrade. ^_^

<TabAtkins> (IE team has openly encouraged devs to stop developing for IE8.)

AmeliaBR: for script it's sort of the same between html and svg
... the problem is with image

DS: right, we should do the change (using src) for script but not for image

ED: out of time, let's continue the discussion on the mailinglist (or in another call)

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

16 Apr 2015

Attendees

Contents