IRC log of svg on 2016-04-22

Timestamps are in UTC.

08:45:11 [RRSAgent]
RRSAgent has joined #svg
08:45:11 [RRSAgent]
logging to http://www.w3.org/2016/04/22-svg-irc
08:45:13 [trackbot]
RRSAgent, make logs public
08:45:13 [Zakim]
Zakim has joined #svg
08:45:15 [trackbot]
Zakim, this will be GA_SVGWG
08:45:15 [Zakim]
ok, trackbot
08:45:16 [trackbot]
Meeting: SVG Working Group Teleconference
08:45:16 [trackbot]
Date: 22 April 2016
08:45:20 [nikos]
Meeting: SVG London 2016 Day 3
08:45:24 [nikos]
chair: nikos
08:45:28 [nikos]
present+ nikos
08:45:33 [nikos]
present+ AmeliaBR
08:45:35 [nikos]
present+ Tav
08:45:38 [nikos]
present+ ChrisLittle
08:52:04 [Tav]
Tav has joined #svg
08:59:27 [stakagi]
stakagi has joined #svg
09:05:06 [nikos]
Topic: Next F2F
09:06:18 [nikos]
AmeliaBR: I'll be at CSS Day in Amsterdam in June
09:06:37 [nikos]
nikos: That may be a good opportunity to all be able to get together again
09:06:46 [nikos]
Tav: I may be able to do that
09:07:19 [nikos]
nikos: Let's see if any others would be able to make it. Seems like a good opportunity
09:20:04 [nikos]
nikos: Finding an office space might be problematic
09:24:19 [stakagi]
present+ stakagi
09:31:38 [AmeliaBR]
Chris Little notes that term "open path" is undefined in textPath discussion. Added issue to get linkable definitions of this & related terms: https://github.com/w3c/svgwg/issues/123
09:31:54 [nikos]
Topic: Tex tChapter
09:32:04 [nikos]
s/Tex t/Text
09:35:21 [nikos]
Tav: if you have multiple sub-paths, what is the behaviour of text on a path
09:35:50 [nikos]
... should the text flow from one sub-path to another, is this affected by the sub-path being closed?
09:39:47 [chaals]
chaals has joined #svg
09:39:59 [nikos]
nikos: What happens on a single closed sub-path now?
09:40:06 [nikos]
Tav: text flows around the shape multiple times
09:40:22 [nikos]
AmeliaBR: I would be happy that by default text gets clipped, and there is a control for allowing wrapping
09:42:30 [nikos]
Tav: I talked to heycam about overflow for text on a path, he said overflow wasn't intended to work on text on a path
09:42:42 [nikos]
... I believe text overflow only applies if overflow is none
09:42:53 [nikos]
... the SVG spec says that text-overflow applies regardless of the overflow property
09:43:01 [nikos]
... because we don't turn on scroll bars and do fancy things
09:43:05 [AmeliaBR_]
AmeliaBR_ has joined #svg
09:43:08 [nikos]
... the text-overflow only has two values - clip and ellipse
09:43:53 [nikos]
... So I removed the thing that says text-overflow applies to text paths
09:44:36 [nikos]
... if we want it to apply we need behaviour for clipping at any point - text on a path only drops whole characters if the mid point doesn't lie on the path
09:44:52 [nikos]
AmeliaBR: so we would need to discuss with css and come up with some new behaviour
09:45:13 [nikos]
Tav: My inclination is to keep it simple, but there is an issue in svg for how to allow text-overflow for content regions
09:45:17 [nikos]
... we don't want scroll bars
09:45:28 [nikos]
AmeliaBR: not useful for text in a shape
09:45:41 [nikos]
Tav: if you look at the figures now it shows overflow, clipping and ellipsis
09:45:49 [nikos]
... but there's no actual way to get the first option
09:46:39 [AmeliaBR_]
https://svgwg.org/svg2-draft/text.html#TextOverflowProperty
09:46:51 [nikos]
AmeliaBR_: for text, this is the default cSS text overflow property
09:47:02 [nikos]
... but none of those options include the svg behaviour for text path
09:47:09 [nikos]
Tav: yeah so I was going to keep that separate
09:47:23 [nikos]
... because it's already defined in svg 1.1
09:47:42 [nikos]
AmeliaBR_: we could ask CSS if they could add another value that drops characters
09:48:10 [nikos]
nikos: seems like it would be useful, but might be difficult to do if it's all handled inside the text layout engine
09:48:28 [nikos]
AmeliaBR_: if you have overflow hidden text-overflow describes how you hide it.
09:48:43 [nikos]
Tav: right now svg text says to ignore overflow
09:48:47 [nikos]
... we really don't want scroll bars
09:49:36 [AmeliaBR_]
Rules for interpretting overflow where scroll bars don't make sense: https://svgwg.org/svg2-draft/render.html#OverflowAndClipProperties
09:50:05 [nikos]
AmeliaBR_: may need to update that table, but we already have rules that turn a computed value into a used value that never has scroll bars
09:50:19 [nikos]
Tav: so that requires changing the rule on overflow and the describing text
09:50:29 [nikos]
... think we can agree that's what we do with shape
09:51:36 [nikos]
RESOLUTION: A value of scroll for overflow for text in a shape will be the equivalent of hidden
09:51:55 [nikos]
action: nikos to update table in render chapter to include overflow behaviour for text
09:51:56 [trackbot]
Created ACTION-3841 - Update table in render chapter to include overflow behaviour for text [on Nikos Andronikos - due 2016-04-29].
09:52:21 [nikos]
Tav: so lets talk about how text-overflow applies
09:52:43 [nikos]
AmeliaBR_: we are going to need to add a UA style sheet rule that says text path by default has hidden overflow
09:53:18 [nikos]
Tav: we need to be careful because as soon as we allow overflow for text on a path we have to define where the text goes
09:54:00 [nikos]
nikos: do we really want to change text on a path? what's the need for overflowing text on a path?
09:54:59 [nikos]
nikos: what about if we define it as an equivalent path that starts from the offset and ends at the offset
09:55:07 [nikos]
... and text on a path never wraps past the end
09:56:47 [nikos]
Tav: I can write it up like that
09:57:06 [nikos]
AmeliaBR_: do we ever want someone to be able to put an ellipsis on clipped text for text on a path?
09:57:26 [nikos]
Tav: I'm not too bothered about that
09:57:46 [nikos]
nikos: I think text on a path is a case where automatic layout isn't so important so we don't need to go there
09:58:13 [nikos]
ChrisLittle: As a user if I had a shape that was filled with text, If it was a rectangle I would expect it to continue beyond the end of the rect
09:58:32 [nikos]
... but if it's not a rectangle it gets messy. Maybe acceptable behaviour would be to just continue the last line?
09:58:40 [nikos]
AmeliaBR_: it's defined in CSS based on cSS layout boxes
09:59:01 [nikos]
... you have your layout box, you cut out your shape, then you continue beyond the bottom of the layout box
09:59:14 [nikos]
... in svg we don't have a layout box so we would have to say the layout box is the shapes layout box
09:59:32 [nikos]
... so we would have to create a box, but it would be inconsistent with the way css has defined it
09:59:44 [nikos]
Tav: i think for SVG 2 it's better to just say this may be defined in the future, we don't define it here
10:00:00 [nikos]
... and recommend you provide an overflow shape - I have a note about that in there already
10:00:43 [nikos]
... in normal cases it will be correct, but if someone adjusts the size it might look wonky
10:01:18 [nikos]
AmeliaBR: As browsers come up with implementations we may see ways of doing it that are better
10:02:51 [nikos]
RESOLUTION: The wrapping behaviour of text on a path will be defined based on the start offset for closed paths with a single sub-path and will not be controllable by text overflow and the other overflow properties
10:03:34 [nikos]
AmeliaBR: Right now path-offset is XML only
10:03:44 [nikos]
... we can leave start-offset as xml only for now
10:18:04 [chaals]
chaals has joined #svg
10:25:56 [AmeliaBR]
AmeliaBR has joined #svg
10:26:17 [nikos]
Topic: Github issues
10:26:35 [nikos]
scribe: nikos
10:26:47 [nikos]
RRSagent, make minutes
10:26:47 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/04/22-svg-minutes.html nikos
10:27:10 [nikos]
The list of github issues that we need to work through is at https://github.com/w3c/svgwg/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22London+2016%22+label%3ANew
10:27:27 [nikos]
Topic: zero value for pathLength
10:27:29 [nikos]
https://github.com/w3c/svgwg/issues/81
10:27:54 [nikos]
nikos: The spec doesn't state what to do with with pathLength=0
10:28:02 [nikos]
... implementations are not consistent
10:28:08 [nikos]
... see the github issue for details
10:28:54 [nikos]
AmeliaBR: if the author gives a pathLength of zero to a path that has non zero actual length, we have a theoretical scaling factor of infinity
10:29:03 [nikos]
... with this infinity factor anything positioned at zero stays at zero
10:29:14 [nikos]
... anything anywhere else gets clamped to the max possible value
10:32:31 [nikos]
Tav: Agree that continuity for animation is important
10:33:58 [nikos]
AmeliaBR: for dashing, dash-offset needs to be taken into account
10:34:23 [nikos]
RESOLUTION: if the author gives a pathLength of zero to a path that has non zero actual length, we have a theoretical scaling factor of infinity with this infinity factor anything positioned at zero stays at zero anything anywhere else gets clamped to the max possible value
10:35:10 [nikos]
Topic: Direction of markers and line caps on segment boundaries
10:35:16 [nikos]
https://github.com/w3c/svgwg/issues/79
10:35:48 [nikos]
nikos: Think what happened in this case is the algorithm didn't capture the behaviour we expect
10:37:07 [nikos]
nikos: So the algorithm currently says that the direction is based on the segment originating at a point, but I think we want to say that for start caps that is the case, but end caps should be based on the preceding segment
10:39:44 [nikos]
Tav:
10:41:20 [nikos]
Tav: Agree
10:42:25 [nikos]
RESOLUTION: The butt line of the cap must always be oriented correctly against the dash it is opening/closing
10:42:33 [nikos]
nikos: I'll update the algorithm
10:42:53 [nikos]
AmeliaBR: And we'll need to file bugs on the browsers that are doing it wrong at the moment
10:43:37 [nikos]
rrsagent, make minutes
10:43:37 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/04/22-svg-minutes.html nikos
10:44:32 [nikos]
Topic: Limit pattern & gradient attributes that are inheritable using href
10:44:55 [nikos]
AmeliaBR: We should include a list as suggested
10:45:19 [nikos]
... the other issue this raises is that style inheritance isn't defined clearly for what happens when you do that
10:45:27 [nikos]
... what I'd like it to have been is where style inheritance is like use elements
10:45:36 [nikos]
... you copy the pattern but change inherited colours
10:45:44 [nikos]
... or other style features
10:45:49 [nikos]
... but no one implements that way
10:46:04 [nikos]
Tav: so if you have a pattern that's referncing another pattern, you can't change the style on it?
10:46:17 [nikos]
AmeliaBR: you can change the pattern tile dimensions because they're attributes on the pattern element itself that you override
10:46:20 [nikos]
... and you can replace child content
10:46:29 [nikos]
... but you can't change inherited colours
10:46:38 [nikos]
... but it's not clearly said in svg 11 whether you should or shouldn't
10:46:54 [nikos]
... because it uses an href and is otherwise similar to use elements, I would ahve otherwise assumed that, and think it would be useful
10:47:09 [nikos]
... but if we are looking to match implementations, I haven't found an implementation that does it the useful way
10:47:16 [nikos]
Tav: wonder how easy it would be for them to implement it ?
10:47:21 [nikos]
... it does sound useful
10:49:04 [nikos]
nikos: if implementations are consistent, we should spec their behaviour
10:49:42 [nikos]
AmeliaBR: it'll be difficult to define that in a consistent way
10:49:49 [nikos]
... I'll give it a look when I do the use rewrite
10:50:22 [nikos]
RESOLUTION: pattern style inheritance will be specified to match current implementations
10:51:49 [nikos]
RESOLUTION: On the pattern element, specific relevant attributes override, not all attributes
10:51:57 [nikos]
rrsagent, make minutes
10:51:57 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/04/22-svg-minutes.html nikos
10:53:53 [nikos]
RESOLUTION: Paint servers will inherit only specific relevant attributes (be specific about which ones in the spec) not all attributes as the spec currently says
10:53:57 [nikos]
rrsagent, make minutes
10:53:57 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/04/22-svg-minutes.html nikos
10:54:20 [nikos]
nikos: ...
10:54:33 [nikos]
RESOLUTION: Paint servers will inherit only specific relevant attributes (be specific about which ones in the spec) not all attributes as the spec currently says
10:54:43 [nikos]
rrsagent, make minutes
10:54:43 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/04/22-svg-minutes.html nikos
11:01:25 [nikos]
Topic: Full glyph cell term is not defined
11:01:39 [nikos]
nikos: this one is easy, just need to check terms and describe it in those terms
11:01:46 [nikos]
... think it's advance width and EM box height
11:01:48 [nikos]
Tav: agree
11:02:45 [nikos]
Topic: How should text following <textPath> be positioned?
11:02:50 [nikos]
https://github.com/w3c/svgwg/issues/104
11:03:16 [nikos]
AmeliaBR: we have two interoperable implementations
11:04:46 [nikos]
nikos: Specify as end of the path provides new x/y?
11:04:49 [nikos]
Tav: yeah
11:05:07 [nikos]
AmeliaBR: what about closed paths and start offset stuff
11:05:27 [nikos]
nikos: So end of the equivalent path that we defined before?
11:05:53 [nikos]
AmeliaBR: using last letter is simpler, but agree end of the path is likely to be more aesthetically pleasing
11:06:37 [nikos]
RESOLUTION: text following textPath text is positioned as if the x,y is at the end point of the equivalent path
11:07:08 [nikos]
rrsagent, make minutes
11:07:08 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/04/22-svg-minutes.html nikos
11:09:31 [nikos]
Topic: Marker element percentages are missing reference values
11:09:37 [nikos]
https://github.com/w3c/svgwg/issues/64
11:11:41 [nikos]
So percentages are relative to the containing viewport, adjusted by the scaling factor of the stroke width
11:11:49 [nikos]
AmeliaBR: So percentages are relative to the containing viewport, adjusted by the scaling factor of the stroke width
11:12:11 [nikos]
... marker doesn't establish a new viewport, though it has a viewBox
11:17:03 [nikos]
... SVG11 didn't allow percentages on markerWidth and markerHeight
11:17:07 [nikos]
Tav: then lets get rid of it
11:17:22 [nikos]
AmeliaBR: spec doesn't allow percentages on pattern even though they do make sense and are supported!
11:17:42 [nikos]
... so spec for pattern needs updating
11:17:49 [nikos]
Tav: Makes sense for pattern, but marker has no bounding box
11:18:24 [nikos]
nikos: Should we drop it for markerWidth and markerHeight for now until we get a way of specifying percentages relative to something other than the viewport?
11:19:00 [nikos]
AmeliaBR: yes for markerWidth and markerHeight. refX and refY should allow percentages and be relative to whatever symbol is relative to - viewbox or whatever else
11:19:09 [nikos]
Tav: refX and refY on a symbol was added
11:20:00 [nikos]
AmeliaBR: for symbol and marker we need to define whether it's L/C/R of the viewbox you're drawing into or the width/height
11:20:12 [nikos]
... Think it has to be relative to the viewBox coordinate system
11:20:46 [nikos]
ACTION: Amelia to update refX/refY to define what it's all relative to
11:20:46 [trackbot]
Created ACTION-3842 - Update refx/refy to define what it's all relative to [on Amelia Bellamy-Royds - due 2016-04-29].
11:29:48 [nikos]
Topic: Clarify whether 'filter' attribute is valid for <tspan> elements
11:30:05 [nikos]
Amelia: in SVG 1.1 tspan and textPath weren't full graphics elements, they were just for text formatting
11:30:17 [nikos]
... we've already allowed transform, so I assume all other styles that goes on a graphics element
11:31:25 [Zakim]
Zakim has left #svg
11:31:43 [nikos]
... filter in filters spec applies to all elements
11:31:52 [nikos]
... I'm going to reply that FireFox is wrong
11:33:22 [nikos]
Tav: so you can apply a filter to a tpsan - and you use the bounding box for the tspan for the filter area
11:33:39 [nikos]
AmeliaBR: Yeah, we have text in svg 2 that mentions that
12:01:37 [chaals]
chaals has joined #svg
14:03:56 [RRSAgent]
RRSAgent has joined #svg
14:03:56 [RRSAgent]
logging to http://www.w3.org/2016/04/22-svg-irc
14:18:38 [nikos]
scribe: nikos
14:18:54 [nikos]
Topic: positioning attributes on textPath directly
14:19:24 [nikos]
AmeliaBR: can we put x,y,dx, and dy on textPath so that authors don't need to specify them on a parent text or tspan element?
14:19:38 [nikos]
Tav: It's extra parsing work.
14:21:08 [nikos]
... I'd like implementor feedback
14:21:50 [nikos]
nikos: Certainly beneficial for users and seems like it would be fairly easy to implement. We could add it and mark it at risk and see what people think
14:27:16 [AmeliaBR]
AmeliaBR has joined #svg
14:27:50 [nikos]
Tav: x and y should not be on textPath
14:28:00 [nikos]
... only dx and dy
14:28:07 [nikos]
AmeliaBR: there's definitions for how to use them mid way through
14:28:19 [nikos]
... in the one direction, with the rule that in the perpendicular direction they're ignored
14:28:30 [nikos]
... but that was never well defined and is inconsistent across browsers
14:28:37 [nikos]
... has it been removed?
14:28:41 [nikos]
Tav: I haven't done anything with it
14:39:28 [AmeliaBR]
Chromebug re startOffset (results in a bad SVG figure in the spec) https://bugs.chromium.org/p/chromium/issues/detail?id=476554 WebKit has same problem
14:40:21 [AmeliaBR]
Chromebug for interaction of startOffset & x/y attributes: https://bugs.chromium.org/p/chromium/issues/detail?id=521550
14:47:39 [nikos]
Discussion on before and after on SVG text -> https://www.w3.org/2015/03/12-svg-minutes.html#item04
14:53:24 [AmeliaBR]
AmeliaBR has joined #svg
14:54:16 [nikos]
Tav: it would be a non trivial amount of work to implement in InkScape
14:54:27 [nikos]
... not too hard to read in, but needs incorporating in the layout code
14:54:42 [nikos]
... it's very messy code
14:55:31 [nikos]
AmeliaBR: if we're not going to change it, can we add a warning into the spec?
14:55:42 [nikos]
... it really confused me
14:56:01 [nikos]
Tav: I would be happy to do that
15:07:48 [AmeliaBR]
Latest CSS WD spec on pseudo-elements: https://www.w3.org/TR/css-pseudo-4/
15:53:44 [nikos]
rrsagent, make minutes
15:53:44 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/04/22-svg-minutes.html nikos