<scribe> Scribe: Nikos

<scribe> scribenick: nikos

Publish SVG Animation CR

nikos: The suggestion was to publish CR of SVG Animations, since we have multiple implementations

AmeliaBR: sounds reasonable. I've been advocating to publish a working draft at least. This is animation elements as defined in 1.1. There are multiple implementations. It's probably safe to go to CR.
... But going to CR means doing some editorial tidy up
... If we were going to WD, I would say go for it right away

nikos: We may need to publish a WD before going to CR anyway

shepazu: is it ready for publication?

nikos: As a WD it is

AmeliaBR: in the status page we could say we very quickly intend to move to CR because of exiting implementations?

https://svgwg.org/specs/animations/

nikos: Wait that's level two
... think that's a mistake and level two has been put in place of level 1

<AmeliaBR> https://svgwg.org/specs/animation-elements/

<AmeliaBR> ^^ That is "Level 3". "Level 2" is what we're talking about.

shepazu: Have we talked to Brian Birtles?

nikos: I pinged him but waiting to hear back

shepazu: First I'd like to hear from Brian, and talk to PLH about what's happening with the SVG WG

nikos: I still think we should publish a WD
... I've got all the WD updates ready to publish - strokes, markers, etc

AmeliaBR: only things we want to change with animation is:
... maybe getting rid of clock values which have no real implementations
... maybe deprecating stuff like animateMotion and animateTransform
... only new thing we've got in here is the discard element

shepazu: Don't want to discourage conversation on this, but I do want to keep us focused on SVG 2
... think when we hear back from Brian what level of effort he's willing to put in the spec
... we are out of charter now, we're on an extended charter. New charter doesn't mention this spec. I'm afraid that showing a lack of focus is going to discourage browser makers from getting involved in the process.

AmeliaBR: that's all fair, think we should get this as a WD and get the updated versions of the WDs done by the end of the year
... with the understanding that those projects will be shelved until SVG 2 is done

nikos: We resolved at TPAC to publish other specs. I'm concerened that if the WG shuts up, that things are organised and not confusing as to what the status of specs is
... I want this to be very low effort

AmeliaBR: I'm concerned about the level of work to publish CR. But WD needs to happen

shepazu: I'll talk to PLH

Make SVGUnitTypes a regular interface with only constants

https://github.com/w3c/svgwg/issues/291

nikos: Robert Longson raised this issue that in SVG 2 SVGZoomAndPan is no interface so the constants that are available on it can't be accessed through SVGZoomandPan
... this is something browsers are updaing at the moment, so important to discuss
... foolip made some comments about interop and made a counter proposal
... in FF SVGZoomAndPan has alwayd been expoed, but thats not the case in all browwsers

Also SVGUnitTypes is very similar

scribe: but implementation is the opposite
... SVGUnitTypes has always been exposed, SVGZoomAndPan has never been exposed interoperably
... We have a PR to update SVGUnitTypes

AmeliaBR: updating it to match Chrome
... which exposes one but not the other

nikos: FF has agreed to the PR for SVGUnitTypes
... so proposed resolution is to expose SVGUnitTypes, but not have any other interfaces implement it

AmeliaBR: The PR just focusing on SVGUnitTypes, by removing the implementations of the interface. It does cancel out some potential functionality. We're relying on the data provided by the contributors
... Usage data shows the constants not being used via the interfaces that implement SVGUnitTypes

nikos: Conversely, data shows the constants are being used directly via the SVGUnitTypes interface
... MS and Google have said they want to have constants only on SVGUnitTypes, and FF has agreed that would be OK if it's what the other implementors want

RESOLUTION: SVGUnitTypes will not be nointefaceobject. No other interfaces will implement SVGUnitTypes. Accept PR #295

nikos: For SVGZoomAndPan, Google want to keep it as is. FF want to expose the SVGZoomAndPan interface directly
... at the moment SVGZoomAndPan is nointerfaceobject

AmeliaBR: According to foolip, WebKit is the same

nikos: My issue is that author expectation would be that the constants should be available via the SVGZoomAndPan interface
... But it's something that's not used and not that big a deal
... Robert has said he doesn't expect FF to change, Chrome implementation is different
... Let's see how discussion in the issue goes wrt SVGZoomAndPan and come back to that one later

Interaction of `x` attribute and `startOffset` in a textPath element

https://github.com/w3c/svgwg/issues/265

Tav: My expectation is that x and startoffset would have an effect

AmeliaBR: when you reset text, is it relative to startoffset, or to the start of the path?
... that's where we have differences

nikos: Does the algorithm clarify that?

AmeliaBR: Do we have a test case?

<AmeliaBR> http://jsfiddle.net/u5z02hpx/9/

AmeliaBR: FF does 5 past 50%, Edge is the outlier, it does 5 past the beginning.

<AmeliaBR> http://jsfiddle.net/u5z02hpx/12/

nikos: FF is ignoring the x attribute on the text element

<AmeliaBR> http://jsfiddle.net/u5z02hpx/12/

<AmeliaBR> http://jsfiddle.net/u5z02hpx/13/

AmeliaBR: This version is more clear

nikos: So first question is whether x element on text is equivalent to x on tspan, that's where the algorithm says yes

AmeliaBR: So the problem with FF is it's ignoring any positions set on the text element that should inherit down

Tav: Looking at the 13 test case, if you put a letter after the first text element but before the textPath - that should be positioned by the x and y of the text element?
... how does that affect the starting x and y position along the textPath?

AmeliaBR: it wouldn't for absolute positions because they would get reset
... the issue is the way the attributes work is they don't apply per element, they apply per character
... so they get inherited down and applied per char
... for chars inside textPath they are applied in the textPath coordinate system
... where the x axis is the path
... browsers seem to be consistent with that with dy
... if there is a letter outside textPath dy applies, otherwise it applies to what's in textPath

Tav: If you have two dy values?
... My guess is that SVG 1.1 didn't intend on having text outside the textPath

nikos: Yeah it's not very useful
... for a lot of pain
... Do people have a behaviour they would like?

Tav: I would like x + startoffset

AmeliaBR: The idea is that positioning attributes apply per char, whether or not they are on an ancestor or child of the textPath. The textPath coordinate system is measured relative to the startOffset point. x=0 is the defined startOffset.

Tav: Think that makes the most sense

nikos: And that seems to be roughly what the algorithm is saying - without having looked at it in fine detail

RESOLUTION: positioning attributes apply per char, whether or not they are on an ancestor or child of the textPath. The textPath coordinate system is measured relative to the startOffset point. x=0 is the defined startOffset.

<scribe> ACTION: Tav to update text prose with text/textPath offset resolution [recorded in http://www.w3.org/2016/11/17-svg-minutes.html#action01]

<trackbot> Created ACTION-3864 - Update text prose with text/textpath offset resolution [on Tavmjong Bah - due 2016-11-24].

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Nikos
Inferring ScribeNick: nikos
Found ScribeNick: nikos
Present: shepazu nikos stakagi AmeliaBR Tav
Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Nov/0001.html
Found Date: 17 Nov 2016
Guessing minutes URL: http://www.w3.org/2016/11/17-svg-minutes.html
People with action items: tav