- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Fri, 18 Nov 2016 00:02:33 +0000
- To: www-svg <www-svg@w3.org>
https://www.w3.org/2016/11/17-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
17 Nov 2016
[2]Agenda
[2] https://lists.w3.org/Archives/Public/www-svg/2016Nov/0001.html
See also: [3]IRC log
[3] http://www.w3.org/2016/11/17-svg-irc
Attendees
Present
shepazu, nikos, stakagi, AmeliaBR, Tav
Regrets
Chair
Nikos
Scribe
Nikos
Contents
* [4]Topics
1. [5]Publish SVG Animation CR
2. [6]Make SVGUnitTypes a regular interface with only
constants
3. [7]Interaction of `x` attribute and `startOffset` in a
textPath element
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
<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?
[10]https://svgwg.org/specs/animations/
[10] 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> [11]https://svgwg.org/specs/animation-elements/
[11] 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
[12]https://github.com/w3c/svgwg/issues/291
[12] 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
[13]https://github.com/w3c/svgwg/issues/265
[13] 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> [14]http://jsfiddle.net/u5z02hpx/9/
[14] http://jsfiddle.net/u5z02hpx/9/
AmeliaBR: FF does 5 past 50%, Edge is the outlier, it does 5
past the beginning.
<AmeliaBR> [15]http://jsfiddle.net/u5z02hpx/12/
[15] http://jsfiddle.net/u5z02hpx/12/
nikos: FF is ignoring the x attribute on the text element
<AmeliaBR> [16]http://jsfiddle.net/u5z02hpx/12/
[16] http://jsfiddle.net/u5z02hpx/12/
<AmeliaBR> [17]http://jsfiddle.net/u5z02hpx/13/
[17] 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
[18]http://www.w3.org/2016/11/17-svg-minutes.html#action01]
[18] 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].
Summary of Action Items
[NEW] ACTION: Tav to update text prose with text/textPath
offset resolution [recorded in
[19]http://www.w3.org/2016/11/17-svg-minutes.html#action01]
[19] http://www.w3.org/2016/11/17-svg-minutes.html#action01
Summary of Resolutions
1. [20]SVGUnitTypes will not be nointefaceobject. No other
interfaces will implement SVGUnitTypes. Accept PR #295
2. [21]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.
[End of minutes]
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 Friday, 18 November 2016 00:03:11 UTC