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