IRC log of svg on 2016-02-03
Timestamps are in UTC.
- 22:47:20 [RRSAgent]
- RRSAgent has joined #svg
- 22:47:20 [RRSAgent]
- logging to http://www.w3.org/2016/02/03-svg-irc
- 22:47:22 [trackbot]
- RRSAgent, make logs public
- 22:47:24 [trackbot]
- Zakim, this will be GA_SVGWG
- 22:47:25 [Zakim]
- I do not see a conference matching that name scheduled within the next hour, trackbot
- 22:47:25 [trackbot]
- Meeting: SVG Working Group Teleconference
- 22:47:25 [trackbot]
- Date: 03 February 2016
- 22:47:27 [heycam]
- Scribe: Cameron
- 22:47:29 [heycam]
- ScribeNick: heycam
- 22:47:31 [heycam]
- Chair: Nikos
- 22:47:36 [heycam]
- Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2016/Agenda
- 22:47:48 [heycam]
- Topic: Path stroking conformance
- 22:47:50 [nikos]
- https://github.com/w3c/svgwg/issues/41
- 22:48:02 [heycam]
- nikos: this was some investigation Tav did, into how different implementations stroke paths
- 22:48:05 [heycam]
- ... in some of the corner cases
- 22:48:10 [heycam]
- ... there's a link to Tav's page in the GH isuse
- 22:48:12 [heycam]
- s/isuse/issue/
- 22:48:26 [heycam]
- ... and I had an action to do some further investigation, enumerate what each implementation does, and come up with some recommendations for what we should specify in SVG 2
- 22:48:38 [heycam]
- ... so looking at Tav's investigation, there are basically two options
- 22:48:47 [heycam]
- ... Fig 2 and Fig 3 are the common methods that are implemented everywhere
- 22:49:02 [heycam]
- ... currently SVG doesn't define any particular method for which pixels should be painted in this sort of case
- 22:49:06 [heycam]
- ... and it turns out most other specs don't either
- 22:49:23 [heycam]
- ... PDF has some description which sounds like what Fig 2 shows, but chatting with some PDF people their opinion was that PDF doesn't prescribe one particular way
- 22:49:35 [heycam]
- ... but the Adobe implementation has always been considered a reference implementation so everyone followed that
- 22:49:44 [heycam]
- ... so taht pretty much means all PDF implementations have converged on one implementation
- 22:49:47 [heycam]
- ... even though it's not specced
- 22:49:50 [heycam]
- s/taht/
- 22:49:52 [heycam]
- s/taht/that/
- 22:50:01 [heycam]
- ... Skia and CG do Fig 3, Cairo does Fig 2
- 22:50:17 [heycam]
- ... Edge follows Fig 2
- 22:50:38 [heycam]
- ... I also had a chat to Mark Kilgard from nVidia, and what is more appropriate for hardware support
- 22:50:42 [heycam]
- ... NV_path_rendering does Fig 2
- 22:51:00 [heycam]
- ... his justification is that he would prefer to do something expensive per pixel, rather than something that generates additional geometry and fills it
- 22:51:04 [heycam]
- ... so a test per pixel
- 22:51:13 [heycam]
- ... he also felt that we shouldn't pick a particular method over another
- 22:51:16 [heycam]
- ... I feel the same way
- 22:51:39 [heycam]
- ... I think this is such a fundamental thing that performance is the ultimate consideration, so people should do the fastest on their platform, since there's not one method that's used in the majority of cases
- 22:51:49 [heycam]
- ... so I also wouldnt recommend one over the other, but if I had to choose I'd choose Fig 2
- 22:52:58 [heycam]
- heycam: I agree
- 22:53:16 [heycam]
- AmeliaBR: is there openness to having a long term strategy of encouraging people to shift to the way that doesn't have weird cutouts?
- 22:53:48 [heycam]
- ... we can't make it a conformance requirement at this point, it'd be a huge performance hit, but if we were somehow to indicate a preference then by having that in a standard somewhere hopefully that would influence future implementations and eventually this problem might go away?
- 22:54:05 [heycam]
- shane: I think these are fundamental properties of underlying OSes, and I don't think there's any chance of shifting by including spec language
- 22:54:17 [heycam]
- ... more useful would be to include recommendations to avoid content that differs in rendering by platform
- 22:54:29 [heycam]
- nikos: yes, if people are using these corner cases to get specific effects, we want to avoid that
- 22:54:53 [heycam]
- ... even a long term strategy of suggesting one over the other, I don't think that's worthwhile, things might change maybe one method becomes more efficient than another
- 22:55:03 [heycam]
- shane: can we have author recommendations?
- 22:55:10 [heycam]
- ... is it as simple as don't use strokes for geometry?
- 22:55:32 [heycam]
- nikos: I don't want it to be that simple, because there is a lot of use for that, as long as you're not doing tight curves within small areas, then you're not going to run into issues
- 22:55:44 [heycam]
- AmeliaBR: rather than specific recommendations, an informative warning might be useful
- 22:56:03 [heycam]
- ... have a note box saying that the SVG spec doesn't define what happens when strokes curve back on themselves in tight corners, implementations differ, here's an example, be aware
- 22:56:15 [heycam]
- nikos: I'd be happy to put a couple of examples of what rendering looks like on different platforms at the moment
- 22:56:21 [heycam]
- shane: and a suggestion on the right way to do it
- 22:56:38 [heycam]
- AmeliaBR: is there a way to do it without changing the geometry of the path?
- 22:56:39 [heycam]
- shane: no
- 22:56:48 [heycam]
- heycam: but a suggestion on how to construct your path data to avoid those cases
- 22:56:50 [shane]
- s/shane/nikos/
- 22:57:02 [heycam]
- AmeliaBR: if you're going to make a tight corner, then do that rather than a loop
- 22:57:22 [heycam]
- ... depends. if you're drawing icons, you can adjust things to avoid these bugs. if you're plotting data, then you're stuck with whatever curves you've got
- 22:57:34 [heycam]
- nikos: one way to avoid it could be to change the coordinate space?
- 22:57:37 [heycam]
- Tav: don't think that would work
- 22:58:25 [heycam]
- AmeliaBR: it's not the first time this sort of language has been in the spec. SVG 1.1 handled patterns with overflow like this.
- 22:58:55 [heycam]
- nikos: everyone happy with not specifying one way or the other, and giving examples/warnings in the spec?
- 22:59:05 [heycam]
- Tav: I'm not really happy with that but I don't see any alternative now
- 22:59:16 [heycam]
- ... I agree with Amelia that Fig 2 is a much better rendering, and what people want
- 22:59:19 [heycam]
- nikos: I don't disagree with that
- 22:59:37 [heycam]
- AmeliaBR: would anyone argue for the weird cutout effect?
- 22:59:54 [heycam]
- nikos: TBH they both look slightly strange. it's not that one is clearly better than the other.
- 23:00:02 [heycam]
- Tav: right, Fig 2 is still not great
- 23:00:07 [heycam]
- nikos: but is nicer overall
- 23:00:14 [joone_mobile]
- joone_mobile has joined #svg
- 23:01:08 [heycam]
- shane: one option would be to go with a detection of the cases where you're happy to be different, and simple not render in all of those cases
- 23:01:11 [heycam]
- ... maybe just that portion of the path
- 23:01:25 [heycam]
- ... then everything would be consistent, and you wouldn't have things that look good on one platform and not on another
- 23:01:30 [heycam]
- ... don't know it's a good idea, but it's a possibility
- 23:01:37 [heycam]
- Tav: I don't know how you would cut out part of the stroke
- 23:02:01 [heycam]
- AmeliaBR: if the reason we're not specifying one way or the other is perf, then that would cancel out the perf benefit
- 23:02:08 [heycam]
- ... if you're going to detect hte problem, it's you can fix it
- 23:02:17 [heycam]
- shane: it's the perf cost of fixing it, though
- 23:02:23 [heycam]
- nikos: also only some implementations would need to fix it
- 23:02:32 [heycam]
- ... the problem with cutting out some path segments if they're going to look funny is generated data
- 23:02:42 [heycam]
- ... if you're drawing a waveform based on some input data, you don't have a lot of control in that case
- 23:02:59 [heycam]
- ... if an author is createing a path in inkscape, they can make geometry to represent that section fo stroke, but if it's generated data it's just going to disappear
- 23:03:14 [heycam]
- AmeliaBR: this isn't an error case, where we're saying we don't know how to handle the error, this is just geometry that has interesting side effects
- 23:03:18 [heycam]
- ... I don't think we should treat it like an error
- 23:03:27 [heycam]
- shane: I can't argue with that
- 23:03:42 [heycam]
- Tav: ok, so we'll put some examples in the spec
- 23:04:00 [heycam]
- ACTION: Nikos to add examples pointing out stroke painting inconsistencies between platforms, warning the author
- 23:04:00 [trackbot]
- Created ACTION-3831 - Add examples pointing out stroke painting inconsistencies between platforms, warning the author [on Nikos Andronikos - due 2016-02-10].
- 23:05:00 [heycam]
- heycam: nikos can you review the stroke shape generation algorithm since that's where these normative relaxations would have to go
- 23:05:07 [heycam]
- Topic: arc linejoin fallback
- 23:05:16 [Tav]
- http://tavmjong.free.fr/SVG/LINEJOIN_STUDY/#arcs
- 23:05:47 [heycam]
- Tav: just above that, fallback for miter clip
- 23:06:05 [heycam]
- ... I just wanted to make sure that what's in the spec, in the stroke generation algorithm, when the two lines are parallel, you still draw out to the clipping point
- 23:06:19 [heycam]
- ... the above one you see a flash because all of a sudden you fall back to bevel
- 23:06:30 [heycam]
- ... but there's no reason to, you can still clip at the miter-clip position
- 23:07:39 [heycam]
- ... I think it's just a matter of Cameron taking this into account in the stroke linejoin algorithm
- 23:07:48 [heycam]
- AmeliaBR: that's certainly what I'd expect, that you can extend the stroke by the miter-limit line
- 23:07:56 [heycam]
- ... when you have that parallel join
- 23:08:12 [heycam]
- ACTION: Cameron to fix the linejoin algorithm to handle parallel miter-clip issue
- 23:08:12 [trackbot]
- Created ACTION-3832 - Fix the linejoin algorithm to handle parallel miter-clip issue [on Cameron McCormack - due 2016-02-10].
- 23:08:19 [heycam]
- Tav: so now miter linejoin fallback
- 23:08:30 [heycam]
- ... I don't think the current fallback behaviour doesn't look good
- 23:08:36 [heycam]
- AmeliaBR: what about falling back to round?
- 23:08:44 [heycam]
- Tav: it would look better, but still give you an abrupt change in behaviour
- 23:08:58 [shepazu]
- shepazu has joined #svg
- 23:09:00 [heycam]
- ... at the end of the page, look at examples of using this line join in a squiggle
- 23:09:09 [heycam]
- ... if you fallback to a round linejoin it wouldn't look good
- 23:09:20 [heycam]
- ... the miter linejoin doesn't look too bad, but there are cases as you see above that it can look bad
- 23:09:28 [heycam]
- ... so some kind of fallback where you preserve some of the curvature
- 23:09:31 [heycam]
- ... I came up with three options
- 23:09:43 [heycam]
- ... at first I thought 2 and 3 would be mathematically difficult, turns out not so bad
- 23:09:59 [heycam]
- ... ignore the jerkiness of the fallback, it's just a weakness of the SMIL animation (the interpolation is linear between the paths there)
- 23:10:15 [heycam]
- ... so Fig 7, 8 and 9 are the three fallback options
- 23:10:36 [heycam]
- ... Option 1 still has a discontinuity, Option 2 & 3 are continuous so I would favour one of those
- 23:10:49 [heycam]
- ... they're both similar level of complexity
- 23:10:59 [heycam]
- ... I saw we choose either 2 or 3 then I'll do a survey of artists to see what they prefer
- 23:11:07 [shane]
- the talons still seem really long in 2 & 3
- 23:11:18 [heycam]
- AmeliaBR: the problem with these is the same problem in that they introduce corners at a certain point at the edges of the stroke
- 23:11:30 [heycam]
- AmeliaBR: it seems to be kicking in later with option 3 than option 2
- 23:11:53 [heycam]
- Tav: I think it should kick in at the same place. the spec would also state that when you have a half line stroke that is greater than the curvature, you fall back to round linejoin
- 23:12:26 [heycam]
- ... in Fig 11, you can see that falling back to a round line join looks better, and avoids having cutout regions
- 23:12:33 [heycam]
- ... round linejoins don't have problems with sharp curves
- 23:13:00 [Rossen]
- present+
- 23:13:03 [heycam]
- ed: one thing I noticed in Options 2 & 3 is that at the top of the curve, if you follow the outer stroke, it's not exactly on the same curvature
- 23:13:13 [heycam]
- ... that's my constructing the curves, there's a slight error
- 23:13:16 [heycam]
- s/.../Tav: /
- 23:13:22 [heycam]
- ed: as an artist I'd say that's not what you want
- 23:13:27 [heycam]
- RRSAgent: this meeting spans midnight
- 23:13:37 [heycam]
- Tav: ideally you'd want a sprial, but that's too complex
- 23:13:50 [heycam]
- shane: what about a variant of option 1 that morphs between the curved and straight variants?
- 23:13:57 [heycam]
- ... with option 1 the talon doesn't get excessively long
- 23:14:17 [heycam]
- AmeliaBR: for the static version the simplest end result is to just ahve the straight line at the end, but it's a matter of connecting over the discontinuity
- 23:14:32 [heycam]
- Tav: I've picked the worst case, when that talon gets really long because the lines are tangent to each other at the end
- 23:14:43 [heycam]
- ... I don't see the fact that the talons get long as particualrly being a problem
- 23:14:56 [heycam]
- ... if you don't want the talon long, you don't make the two segments parallel at the end
- 23:15:01 [heycam]
- shane: with generated data you might have no choice
- 23:15:11 [heycam]
- AmeliaBR: probably wouldn't be using this line join on a data vis
- 23:15:18 [heycam]
- Tav: you can always put a miter limit on
- 23:15:35 [heycam]
- AmeliaBR: I agree with Tav that all of these options are better than just switching to the miter which has a discontinuity and a weird shape
- 23:16:05 [heycam]
- Tav: can I get agreement with choosing one of these as a fallback then I'll do a survey to see what people prefer?
- 23:16:14 [heycam]
- nikos: anyone not happy with option 2 or 3 as fallback?
- 23:16:18 [heycam]
- ... I think I like 3 over 2, esp if you fix the curvature
- 23:16:24 [heycam]
- ... prob would prefer option 1 if it was continuous
- 23:16:32 [heycam]
- ... but I'd be happy with any
- 23:16:34 [ed]
- +1 for option 3
- 23:16:36 [heycam]
- s/any/any of option 2 or 3/
- 23:16:45 [heycam]
- Tav: I've got these partially implemented in Inkscape
- 23:16:57 [heycam]
- ... when I've fixed the bugs I'll release that in a trunk version that people can test
- 23:17:14 [heycam]
- nikos: might be a good test to try with a bunch of vector image files and set them all to arcs to see if you get anyhting standout horrible
- 23:17:36 [heycam]
- RESOLUTION: arcs fallback will be option 2 or 3 depending on survey feedback
- 23:17:49 [heycam]
- ACTION: Tav to survey whether option 2 or 3 would be better for arcs fallback
- 23:17:49 [trackbot]
- Created ACTION-3833 - Survey whether option 2 or 3 would be better for arcs fallback [on Tavmjong Bah - due 2016-02-10].
- 23:18:02 [heycam]
- Topic: Animation of SVG paths with Web Animations
- 23:18:11 [heycam]
- Tav: my worry was that this would fall through the cracks
- 23:18:19 [heycam]
- ... but talking to people this will end up in a spec somewhere
- 23:18:36 [heycam]
- AmeliaBR: there's a lot of push to make d a property, and so it would be naturally part of web animations
- 23:18:43 [heycam]
- shane: I believe that Cameron was working on that this morning
- 23:19:07 [heycam]
- ... also d should be directly animatable as an attribute once we resolve any remaining any issues once we work out Web Animations targetting attributes
- 23:19:14 [heycam]
- ... hasn't fallen through the cracks
- 23:19:27 [heycam]
- AmeliaBR: one extension that goes beyond Web Animations is introducing more flexibility in how you interpolate different paths
- 23:19:45 [heycam]
- ... the SMIL standard and the one that's been implemented in snap, d3, has this requirement of same number/type of segments
- 23:20:08 [heycam]
- ... and another option is to create normalization rules so that ifyou're animating frmo a striaght line to a cubic bezier you effectively upgrade the line to the cubic
- 23:20:17 [heycam]
- ... and therefore make it a lot more flexible to do those sorts of animations
- 23:20:39 [heycam]
- shane: we have experimented with this in the past, and in making splits in segments so you can animate when the numebr of segments difers, and it all works well, would love to do that
- 23:20:52 [heycam]
- ... but I don't think we can just come up with extended interpolation rules, we might need to introduce new syntax for that
- 23:21:00 [heycam]
- ... I certainly would be interested to move in that direction
- 23:21:06 [heycam]
- Tav: would like to avoid getting complicated right now
- 23:21:18 [heycam]
- ... I think maybe doing the line->bezier would be an exception, since that's an easy thing to do
- 23:21:35 [heycam]
- shane: it's all very easy, but I don't think we should have just one exception, if we're going to do it make it right
- 23:21:47 [heycam]
- ... the rules aren't hard, just whether to introduce new impl requirements or not
- 23:21:51 [heycam]
- ... and I agree at this stage we shouldn't
- 23:21:58 [heycam]
- AmeliaBR: I would say there's huge authoring demand for this
- 23:22:10 [heycam]
- ... when GSAP (?) introduce this, you can morph paths you don't have to carefully construct the paths to match
- 23:22:15 [heycam]
- ... so there's certainly demand for this
- 23:22:32 [heycam]
- ... but let's not do it piecemeal
- 23:22:41 [heycam]
- BogdanBrinza: sounds like a good Level 1 / Level 2 thing
- 23:22:57 [heycam]
- ... we can start with the same number/types of commands for Level 1, then extend in Level 2
- 23:23:07 [heycam]
- shane: are we having a Path module?
- 23:23:09 [heycam]
- heycam: yes there is one
- 23:23:13 [heycam]
- Tav: fine with me
- 23:24:01 [heycam]
- heycam: I'll continue working on that this afternoon
- 23:24:19 [heycam]
- AmeliaBR: the natual place for it might be CSS Transitions spec, which has rules for all other datatypes
- 23:24:25 [heycam]
- ... not sure if they want us to start throwing path data in there
- 23:24:33 [heycam]
- ... if not, then in SVG 2 Paths chapter which just repeats that rule about how to interpolate two paths
- 23:24:58 [heycam]
- birtles: the intention I think is the latter.. Transitions was just catching up for things already defined, but all new properties etc. should define their own rules for how they're interpolated and animated, so it should go in SVG 2 's path definitions
- 23:25:17 [heycam]
- Topic: initial value of 'd' property
- 23:25:31 [heycam]
- ed: I chatted with Eric Willigers last night, and noted lack of initial value for d
- 23:25:37 [heycam]
- ... question is whether none or the empty string
- 23:25:56 [heycam]
- AmeliaBR: can we all agree that an empty path really means nothing, because that impacts on stuff like bbox calcualtions
- 23:26:12 [heycam]
- ... you don't want that empty path contribute a dot at the origin to group bbox calculations
- 23:26:28 [heycam]
- ... whatever we call it, the "no d value specified" has to equate to the path not rendered and doesn't affect geom at all
- 23:27:45 [heycam]
- heycam: I think having none and path("") be the same would be fine, with none being the initial
- 23:27:48 [heycam]
- shane: also think about computed values
- 23:27:58 [heycam]
- AmeliaBR: also should normalization be done in the computed values?
- 23:29:18 [heycam]
- AmeliaBR: wouldn't we treat path("") as invalid syntax and dropped at parse time?
- 23:29:32 [heycam]
- shane: no I don't think that should be invalid
- 23:29:55 [heycam]
- ... just to be clear: path { d: path(""); }
- 23:30:13 [heycam]
- AmeliaBR: I did send a reply to your mail about path()
- 23:31:52 [heycam]
- heycam: so what about the d="" presentation attribute, shoudl we be accepting path() in there in addition to raw path syntax?
- 23:32:33 [heycam]
- shane: it's a non-starter to set d with a fill rule and make that affect the fill-rule property
- 23:32:41 [heycam]
- ... so we'd need to ignore the fill rule value in there
- 23:32:46 [heycam]
- AmeliaBR: we need the fill rule for clip-path
- 23:32:56 [heycam]
- shane: yes. I suggest having two variants of path(), and spec authors choose which one
- 23:35:00 [heycam]
- heycam: we can't use raw path data in the property value
- 23:35:04 [heycam]
- ... CSS parsing problems
- 23:35:25 [heycam]
- ... at that point we have different syntax from the existing d="" attribute, so we may as well have path() to match other property syntax patterns
- 23:35:46 [heycam]
- AmeliaBR: then we could also extend to CSS shapes in there like circle()
- 23:35:52 [shane]
- q+
- 23:36:05 [shepazu]
- q-
- 23:36:25 [nikos]
- ack shane
- 23:36:31 [heycam]
- shane: the only thing I would say is that there is definitely interest in CSS in the future in specifying a more readable syntax for paths
- 23:36:54 [heycam]
- ... I think that's a feeling in the CSSWG, that we could get quite efficient minimzation that happens with gzip, so we should bias towards readbility
- 23:37:11 [heycam]
- ... making this a function rather than a raw function makes it way easier to add new syntaxes in the future
- 23:38:10 [heycam]
- heycam: so should we allow path() in the presentation attribute too?
- 23:38:21 [heycam]
- shane: decide once we decide to extend the d property syntax?
- 23:38:31 [heycam]
- AmeliaBR: it wouldn't be hard to support... you don't have to parse far to tell
- 23:38:56 [heycam]
- heycam: true. also happy to leave it for now.
- 23:39:12 [shane]
- a/than a raw function/than a raw string/
- 23:39:20 [heycam]
- AmeliaBR: so those issues to the side, we're all in agreement that if the d property includes a fill rule it's ignored, and the fill-rule property is used instead?
- 23:39:31 [heycam]
- ... or if the path() has a fill rule valid it's invalid?
- 23:39:38 [heycam]
- shane: I don't think we've made a decision, but I suggest the latter
- 23:39:47 [heycam]
- ... if you provide a fill rule for a property that doesn't accept one then that's an error
- 23:41:42 [heycam]
- ... probably the most CSS-y way to do this is pull the fill-rule of the property out of the path()
- 23:41:53 [heycam]
- AmeliaBR: this has already shipped in some places, though
- 23:41:59 [heycam]
- ... so path() should match up with the other CSS Shapes functions
- 23:42:17 [heycam]
- shane: I'm really uncomfortable with supporting the d property on path elemetns such that it accepts a fill rule that necessarily must be ignored
- 23:42:54 [heycam]
- AmeliaBR: from another perspective, why don't we make the 'd' property a shorthand that somehow encompasses the fill-rule and overrides it?
- 23:43:07 [heycam]
- shane: if so then you wouldn't have the fill-rule inside the path()
- 23:44:03 [heycam]
- heycam: so how about we disallow fill-rule and decide to allow it if we want to apply d to other properties that need it later
- 23:44:43 [heycam]
- AmeliaBR: I would prefer generalizing it
- 23:44:53 [heycam]
- heycam: I think it's safe to disallow now and open up later if we need to
- 23:45:37 [birtles]
- shane: I'd like someone to summarize this discussion and send it to the CSS list
- 23:45:50 [birtles]
- heycam: I don't think ignoring the value inside there is such an extreme change
- 23:46:07 [birtles]
- AmeliaBR: as it is now you can use the fill rule in properties where it has no effect
- 23:46:20 [birtles]
- shane: but in this case the fill-rule has an effect but we throw it away
- 23:46:36 [birtles]
- heycam: someone can write it up and ask the CSSWG
- 23:46:39 [birtles]
- shane: I'll do it
- 23:47:09 [heycam]
- ACTION: Shane to ask CSSWG if disallowing fill rule in path() for d is good
- 23:47:10 [trackbot]
- Created ACTION-3834 - Ask csswg if disallowing fill rule in path() for d is good [on Shane Stephens - due 2016-02-10].
- 23:47:55 [heycam]
- Topic: Animation of path data
- 23:48:01 [heycam]
- nikos: Bodgan points out we missed out on a resolution
- 23:48:29 [heycam]
- AmeliaBR: two aspects: one resolve that SVG 2 Paths chapter should have rules for interpolating from SVG 1.1, same number/type rules
- 23:48:34 [heycam]
- ... just c/p the paragraphs from SVG 1.1
- 23:48:49 [heycam]
- ... and we also agreed that the Paths module would include more flexible path interpolation rules
- 23:48:51 [heycam]
- ... TBD later
- 23:49:32 [heycam]
- RESOLUTION: SVG 2 Paths chapter will include SVG 1.1 rules for interpolating path data with same number/types segments, and SVG Paths module will be the place to have extended interpolation rules
- 23:55:32 [AmeliaBR]
- Update on that resolution: it looks like the only paragraph in SVG 1.1 describing animation of path data is right after the "d" attribute is specified. It's already in SVG 2. May want to add an informative note that "this may be changed by a future specification"? https://svgwg.org/svg2-draft/paths.html#DAttribute
- 00:09:45 [nikos]
- ping AmeliaBR: We're back
- 00:10:28 [heycam]
- AmeliaBR, I don't think we want to say that it might change; rather that we might add new interpolations in the future
- 00:11:05 [AmeliaBR]
- heycam: that's better. Existing rules should stay the same, but new options become available.
- 00:11:11 [heycam]
- Topic: GitHub
- 00:11:16 [heycam]
- nikos: this is about how we want to track our work, issues
- 00:11:26 [heycam]
- ... I've been experimenting with filing issues there, tagging them
- 00:11:38 [heycam]
- ... I like the environment, it tracks the whole conversation, easy to drop in a comment and point to something
- 00:11:42 [heycam]
- ... seems like it would work very well
- 00:11:55 [heycam]
- ... there are other things too, hooking in with the spec build process if we want, hooks on issues being added etc.
- 00:11:59 [AmeliaBR]
- +1 to all Nikos has done to get GitHub rolling...
- 00:12:04 [heycam]
- ... might be an option once we have time
- 00:12:09 [AmeliaBR]
- s/+1/+100/
- 00:12:17 [heycam]
- ... the challenge there is moving everything to one place, and not falling back to old habits
- 00:12:21 [heycam]
- ... keeping conversations from getting fragmented
- 00:12:31 [heycam]
- ... comments from people who've used GH more would be good
- 00:12:34 [heycam]
- ... and others' feelings
- 00:12:50 [heycam]
- shepazu: first I want to mention that W3C most WGs are moving to GH, increasingly our toolchain is geared around GH
- 00:12:54 [heycam]
- ... so we'd be going with the flow
- 00:13:02 [heycam]
- ... there are ways to reflect issues into the mailing list
- 00:13:06 [heycam]
- ... some people find that problematic
- 00:13:12 [heycam]
- ... personally I feel it's a good place to archive our conversations
- 00:13:31 [heycam]
- ... if we really wanted to set up a GH only list then we could do that, if we don't want to send them to www-svg
- 00:13:50 [heycam]
- ... if we move to GH issues, I'm going to set up a demo in a few mins of a kanban board we're trying to mimic for the W3C issue trackers
- 00:14:03 [heycam]
- ... it lets you visualise what's going on, it's a useful organisational tool
- 00:14:14 [heycam]
- ... in general people are more prone to comment on GH than MLs, it's lower commitment
- 00:14:21 [heycam]
- ... so I'm in favour of it
- 00:14:26 [heycam]
- ... I'm not GH expert but I'm conformtable with it
- 00:14:57 [heycam]
- BogdanBrinza: we've been using it for some internal projects
- 00:15:03 [heycam]
- ... it's very useful for discussions and code in the same place
- 00:15:10 [heycam]
- ... test cases, commits, it's incredibly useful
- 00:15:23 [heycam]
- shane: in Houdini it's been great to have all the comments on an issue in the one place, when coming back to an issue months later
- 00:15:29 [heycam]
- nikos: one of the negatives is that it's online
- 00:15:36 [heycam]
- ... if you want to read conversatiosn offline it might be difficult
- 00:15:46 [heycam]
- shepazu: if you reflect issues to a mailing list that's resolved
- 00:15:50 [heycam]
- ... you can even respond to issues via email
- 00:16:15 [heycam]
- ... one downside is some organisations aren't allowed to participate on GH, because you can post code there
- 00:16:20 [heycam]
- ... I don't think it's a problem for our WG
- 00:17:01 [heycam]
- AmeliaBR: one issue I've heard is relying on an outside commercial entity, so long as everything is backed up somehwere it's not a problem
- 00:17:11 [heycam]
- ... for Git repos it's fine, since you have copies everywhere else
- 00:17:20 [heycam]
- ... the issues are hosted exclusively on GH, so it's a dependency on that company
- 00:17:30 [heycam]
- ... copying to a ML should be fine as a backup
- 00:17:47 [heycam]
- Tav: I think that is an improtant issue, inkscape for example relied on sourceforge
- 00:17:56 [heycam]
- ... somebody bought it, it's changed completely, we're moving off it
- 00:18:25 [heycam]
- shepazu: because so many WGs are on GH, if something happened there, I'm sure there'd be a grace period to offload their resources
- 00:19:23 [heycam]
- shane: I think we have a tool for migrating issues between GH projects
- 00:19:35 [heycam]
- nikos: I could run a GH Enterprise thing at work and mirror the issues
- 00:19:41 [heycam]
- shane: one thing that would be nice is an IRC interface
- 00:19:53 [heycam]
- ... right now we have Tracker, and the only benefit to tracker is its IRC interface
- 00:20:14 [shane]
- s/shane/shepazu/
- 00:20:19 [heycam]
- ... so for the Web Payments WG (and for others) is set up OAuth between a W3C interface so you could auth to make changes to repos, with that bridge we can make an IRC bot as well
- 00:20:28 [heycam]
- ... so we could say issue #15 in the channel and open/close issues
- 00:20:42 [heycam]
- nikos: we also have the W3C action tracker, and just have an issue assigned to someone
- 00:20:55 [heycam]
- shepazu: yes, especially now with Zakim also no longer being useful
- 00:20:58 [AmeliaBR]
- Possibly relevant: recent effort by some open-source groups to push GitHub to improve issues for better project management: https://github.com/dear-github/dear-github
- 00:22:19 [heycam]
- heycam: Houdini redirects any issue discussing emails on the ML to GH, do we want to do that too?
- 00:22:31 [heycam]
- nikos: [thumbs up]
- 00:22:44 [heycam]
- shepazu: I think being in GH "issues" focuses more on specific issues, too, rather than general discssion
- 00:23:11 [heycam]
- ... I remember from the old days in SVG we'd easily lose valuable comments because they were in the ML somewhere and weren't captured as issues properly
- 00:23:16 [heycam]
- ... this would help us track stuff more
- 00:24:14 [heycam]
- shane: what about contributions from people not in the WG?
- 00:24:18 [heycam]
- s/shane/shepazu/
- 00:24:26 [heycam]
- shepazu: generally it's not a problem, some people worry about it though
- 00:24:50 [heycam]
- shane: there are things you can do. I know that the Google GH repo has hooks of some sort to request anybody who is not in a list to sign an SLA
- 00:24:53 [heycam]
- ... that's done on PRs
- 00:25:31 [heycam]
- birtles: if we use GH more, we're more likely to get PRs
- 00:25:40 [heycam]
- ... what's the situation with regards to IP, do they need to sign a CLA
- 00:25:52 [heycam]
- ... when I asked about this in the past, I was told it's fine to accept PRs from anyone in the WG obviously, also a member org
- 00:25:58 [heycam]
- ... but there is some requirement for people outside those categories
- 00:26:10 [heycam]
- ... not sure we can fulfill that requirement by sticking something in the README.md?
- 00:26:40 [AmeliaBR]
- GitHub process for defining contributing agreements: https://help.github.com/articles/setting-guidelines-for-repository-contributors/
- 00:27:26 [heycam]
- AmeliaBR: this is not something unique to W3C
- 00:27:36 [heycam]
- ... all open sources communities have to deal with making sure people who contribute aren't going to sue
- 00:28:11 [heycam]
- ... so it's just a case of whether the W3C is OK with using the GH warning "don't contribute unless you agree to this", or if the W3C wants somebody to actually signed/clicked an agreement
- 00:28:25 [heycam]
- shepazu: I should know this, but I'm not sure. I will research this and get back to you tmr.
- 00:29:09 [heycam]
- AmeliaBR: one of the most important aspects is tagging issues well
- 00:29:31 [heycam]
- ... Nikos has been tagging them nicely, but I don't know whether he as chair wants to do that ongoing, or whteher there will be some sort of process of triaging new issues coming in
- 00:29:42 [heycam]
- ... similarly for things on the ML, do you want to have a chair's reponsibility to turn that into an issue?
- 00:29:52 [heycam]
- ... or reply to ask the commenter to put it on GH?
- 00:30:08 [heycam]
- nikos: I'm happy to keep doing this, and we should help the author by filing the GH issue for them
- 00:30:19 [heycam]
- ... on the subject of tags, I think it's important to get that worked out early
- 00:30:30 [shepazu]
- q+ kanban board
- 00:30:37 [shepazu]
- q+
- 00:30:37 [heycam]
- ... so we don't have a situation where the first 6 months of issue filing we don't have tags, but after we do
- 00:30:46 [heycam]
- ... so at the moment I've got tags for each spec, then tags for each chapter of SVG 2
- 00:30:54 [heycam]
- ... then there are a few others like "needs CSS review"
- 00:31:06 [heycam]
- ... I think we could use more tags, if people have suggestions feel free to just create them or bring it up
- 00:31:19 [heycam]
- AmeliaBR: my one suggestion is to have a single document that outlines the tagging scheme
- 00:31:34 [heycam]
- nikos: as an outcome of this discussion, I can write up a wiki page describing the GH workflow, tagging, etc.
- 00:31:55 [heycam]
- ack kanban
- 00:31:57 [heycam]
- ack board
- 00:31:59 [shepazu]
- https://waffle.io/w3c/svgwg
- 00:32:01 [heycam]
- nikos: what about GH wiki?
- 00:33:08 [heycam]
- shane: Houdini moved to the GH wiki
- 00:33:14 [heycam]
- nikos: I'll lay down some best practices in a wiki page
- 00:33:33 [heycam]
- shepazu: Wendy Seltzer has told me that there is a way of setting up a GH repo so there's a click through on contributions
- 00:33:40 [heycam]
- ... so I'll make sure that's set up correctly
- 00:33:48 [shepazu]
- https://waffle.io/w3c/svgwg
- 00:34:09 [heycam]
- ... this is a kanban board
- 00:34:23 [heycam]
- ... each column is a label
- 00:35:29 [heycam]
- ... you have to auth by clicking the person icon in the bottom left of the page
- 00:35:44 [shepazu]
- https://waffle.io/w3c/webpayments
- 00:36:18 [heycam]
- ... we have things broken down into New, Actions, Discussion, Proposals, In Progress, Postponed an Done
- 00:36:21 [heycam]
- s/an D/and D/
- 00:36:44 [heycam]
- AmeliaBR: so the idea is to separate out issues that are being discussed, and those where we have a clear resolution but needs to be done, or is in progress?
- 00:36:52 [shepazu]
- https://waffle.io/w3c/annotation
- 00:37:25 [heycam]
- shepazu: discussion is for things that will come up in the next telcon
- 00:37:31 [heycam]
- ... editing for when an action is assigned to do it
- 00:37:44 [heycam]
- ... there are different ways, we can pick our own labels
- 00:37:50 [heycam]
- ... this is a 3rd party service waffle.io
- 00:38:06 [heycam]
- ... we're trying to make something like this for W3C, but you can drag items between these different groups
- 00:38:09 [heycam]
- ... and that resolves them
- 00:38:14 [heycam]
- ... you can raise new issues etc.
- 00:38:23 [heycam]
- ... we don't have to use this, but it might be useful
- 00:38:25 [heycam]
- nikos: I like it
- 00:39:59 [heycam]
- shepazu: one danger is if there are different repos, this doesn't reflect that
- 00:40:08 [heycam]
- AmeliaBR: there's a way of cross linking issues between repos
- 00:40:18 [heycam]
- shepazu: but we'd need to maintain a master list of issues in our repo
- 00:40:57 [heycam]
- heycam: we have all our specs in the one repo
- 00:41:11 [heycam]
- AmeliaBR: but there is an FX repo
- 00:41:27 [heycam]
- shepazu: that's where that issue mover tool comes in handy
- 00:41:55 [heycam]
- shane: overall: awesome!
- 00:42:10 [heycam]
- ed: so are we using the kanban?
- 00:42:15 [shepazu]
- https://github.com/w3c/licenses
- 00:42:24 [heycam]
- nikos: I'm happy to. everyone doesn't need to...
- 00:42:29 [shepazu]
- https://labs.w3.org/hatchery/ash-nazg/
- 00:43:38 [heycam]
- shepazu: maybe the agenda could reference other issues
- 00:44:02 [heycam]
- nikos: or a special board for telcons
- 00:44:06 [heycam]
- shepazu: or just a label
- 00:44:13 [heycam]
- ... that does mean more work for you (chairs), but it's not much
- 00:45:18 [heycam]
- AmeliaBR: one issue with GH issues is you can't attach SVG files
- 00:45:24 [heycam]
- ... you have to zip it or host it elsewhere
- 00:45:57 [heycam]
- nikos: realistically I'd put things in jsfiddle and link to it, so it's not a dealbreaker
- 00:47:23 [heycam]
- shepazu: I can raise the issue of SVGs on GH issues
- 00:47:39 [heycam]
- Topic: SVG 2 issues
- 00:47:45 [shepazu]
- s/GH issues/GH issues and wiki/
- 00:47:47 [heycam]
- nikos: the main goal is that people should have something to work on for the rest of the day
- 00:48:01 [heycam]
- Tav: does anyone have not have spec editing to work on this afternoon?
- 00:48:05 [heycam]
- Tav: otherwise we should just get on to it
- 00:49:04 [heycam]
- nikos: the coords chapter does need looking at. I'm going to go through it, but you want to go throuhg it and see fi there are things that need improving that'd be useful
- 00:49:05 [heycam]
- shane: sure
- 00:50:10 [heycam]
- BogdanBrinza: in SVG Integration, looking at currently interoperable external resources in use
- 00:50:15 [heycam]
- ... and CSS sizing behaviour
- 00:50:27 [heycam]
- ... it's mostly interoperable, the spec didn't help us, so we had to build our cases
- 00:50:37 [heycam]
- ... while looking at SVG integrations the issues there are fairly light
- 00:50:41 [heycam]
- ... and tmr make a call on them?
- 00:50:45 [shepazu]
- q+ to ask about xlink:href
- 00:52:11 [heycam]
- heycam: there were previous discussions e.g. in Leipzig, which didn't make their way into the spec, you might want to look at the minutes there
- 00:52:19 [heycam]
- AmeliaBR: sizing issues come up a lot for authors
- 00:52:43 [heycam]
- BogdanBrinza: in my experience, SVG as background-image, inline and SVG-as-image, all the browsers are fairly interoperable between Firefox/Chrome/Edge, not necessarily IE/Safari
- 00:52:47 [heycam]
- ... but it's fairly close
- 00:53:27 [heycam]
- ... if it will help this group, the behaviour we trended to was SVG sizing first, then do CSS sizing, rather than making CSS sizing taking into account SVG properties
- 00:53:30 [heycam]
- ... I'll give more details tomorrow
- 00:54:03 [heycam]
- shepazu: changing topics, I still write SVG from time to time, doing it by hand I still struggle with xlink:href
- 00:54:13 [heycam]
- ... AIUI the only implementation right that supports barename href is Edge
- 00:55:09 [heycam]
- ... how the spec on that?
- 00:55:12 [heycam]
- heycam: spec changes have been made
- 00:56:31 [heycam]
- shepazu: href seems like low hanging fruit
- 00:56:48 [heycam]
- BogdanBrinza: I would imagine implementors would be willing to contribute tests suites they have intenrally, once we know the right framework
- 00:56:51 [heycam]
- ... I'm not sure what to do there
- 00:56:58 [heycam]
- shepazu: could I ask if you have tests for this?
- 00:57:02 [heycam]
- BogdanBrinza: for SVG sizing etc. we do
- 00:57:09 [heycam]
- ... I think we have close to 200 tests
- 00:57:15 [heycam]
- shepazu: could I get you to report back on what tests to contribute?
- 00:57:16 [heycam]
- BogdanBrinza: sure
- 00:57:30 [heycam]
- birtles: as for the format, we've decide we're doing testharness.js in WPT, and reftests
- 01:00:26 [nikos]
- http://www.meetup.com/SVG-AU/events/228075250/
- 01:11:34 [stakagi]
- I agree. Should a Vector Effect chapter be put on both cooords and painting?
- 01:13:48 [heycam]
- stakagi: I think that's fine. but have the primary property definition blue box in the Coords chapter
- 01:15:39 [stakagi]
- heycam: O.K.
- 01:18:28 [nikos]
- RRSAgent, make minutes
- 01:18:28 [RRSAgent]
- I have made the request to generate http://www.w3.org/2016/02/03-svg-minutes.html nikos
- 01:19:14 [AmeliaBR]
- AmeliaBR has joined #svg
- 03:22:39 [stakagi]
- stakagi has joined #svg
- 04:26:31 [shepazu]
- https://github.com/w3c/svgwg/pulls