See also: IRC log
<scribe> Scribe: Nikos
<scribe> scribenick: nikos
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
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
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[End of scribe.perl diagnostic output]