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
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]
22:47:48 [heycam]
Topic: Path stroking conformance
22:47:50 [nikos]
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]
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]
22:49:52 [heycam]
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]
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]
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]
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]
23:36:05 [shepazu]
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"?
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]
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]
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:
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]
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
00:26:40 [AmeliaBR]
GitHub process for defining contributing agreements:
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]
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]
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]
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]
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]
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
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]
00:42:24 [heycam]
nikos: I'm happy to. everyone doesn't need to...
00:42:29 [shepazu]
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]
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 nikos
01:19:14 [AmeliaBR]
AmeliaBR has joined #svg
03:22:39 [stakagi]
stakagi has joined #svg
04:26:31 [shepazu]