22:47:20 RRSAgent has joined #svg 22:47:20 logging to http://www.w3.org/2016/02/03-svg-irc 22:47:22 RRSAgent, make logs public 22:47:24 Zakim, this will be GA_SVGWG 22:47:25 I do not see a conference matching that name scheduled within the next hour, trackbot 22:47:25 Meeting: SVG Working Group Teleconference 22:47:25 Date: 03 February 2016 22:47:27 Scribe: Cameron 22:47:29 ScribeNick: heycam 22:47:31 Chair: Nikos 22:47:36 Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2016/Agenda 22:47:48 Topic: Path stroking conformance 22:47:50 https://github.com/w3c/svgwg/issues/41 22:48:02 nikos: this was some investigation Tav did, into how different implementations stroke paths 22:48:05 ... in some of the corner cases 22:48:10 ... there's a link to Tav's page in the GH isuse 22:48:12 s/isuse/issue/ 22:48:26 ... 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 ... so looking at Tav's investigation, there are basically two options 22:48:47 ... Fig 2 and Fig 3 are the common methods that are implemented everywhere 22:49:02 ... currently SVG doesn't define any particular method for which pixels should be painted in this sort of case 22:49:06 ... and it turns out most other specs don't either 22:49:23 ... 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 ... but the Adobe implementation has always been considered a reference implementation so everyone followed that 22:49:44 ... so taht pretty much means all PDF implementations have converged on one implementation 22:49:47 ... even though it's not specced 22:49:50 s/taht/ 22:49:52 s/taht/that/ 22:50:01 ... Skia and CG do Fig 3, Cairo does Fig 2 22:50:17 ... Edge follows Fig 2 22:50:38 ... I also had a chat to Mark Kilgard from nVidia, and what is more appropriate for hardware support 22:50:42 ... NV_path_rendering does Fig 2 22:51:00 ... 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 ... so a test per pixel 22:51:13 ... he also felt that we shouldn't pick a particular method over another 22:51:16 ... I feel the same way 22:51:39 ... 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 ... so I also wouldnt recommend one over the other, but if I had to choose I'd choose Fig 2 22:52:58 heycam: I agree 22:53:16 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 ... 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 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 ... more useful would be to include recommendations to avoid content that differs in rendering by platform 22:54:29 nikos: yes, if people are using these corner cases to get specific effects, we want to avoid that 22:54:53 ... 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 shane: can we have author recommendations? 22:55:10 ... is it as simple as don't use strokes for geometry? 22:55:32 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 AmeliaBR: rather than specific recommendations, an informative warning might be useful 22:56:03 ... 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 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 shane: and a suggestion on the right way to do it 22:56:38 AmeliaBR: is there a way to do it without changing the geometry of the path? 22:56:39 shane: no 22:56:48 heycam: but a suggestion on how to construct your path data to avoid those cases 22:56:50 s/shane/nikos/ 22:57:02 AmeliaBR: if you're going to make a tight corner, then do that rather than a loop 22:57:22 ... 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 nikos: one way to avoid it could be to change the coordinate space? 22:57:37 Tav: don't think that would work 22:58:25 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 nikos: everyone happy with not specifying one way or the other, and giving examples/warnings in the spec? 22:59:05 Tav: I'm not really happy with that but I don't see any alternative now 22:59:16 ... I agree with Amelia that Fig 2 is a much better rendering, and what people want 22:59:19 nikos: I don't disagree with that 22:59:37 AmeliaBR: would anyone argue for the weird cutout effect? 22:59:54 nikos: TBH they both look slightly strange. it's not that one is clearly better than the other. 23:00:02 Tav: right, Fig 2 is still not great 23:00:07 nikos: but is nicer overall 23:00:14 joone_mobile has joined #svg 23:01:08 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 ... maybe just that portion of the path 23:01:25 ... then everything would be consistent, and you wouldn't have things that look good on one platform and not on another 23:01:30 ... don't know it's a good idea, but it's a possibility 23:01:37 Tav: I don't know how you would cut out part of the stroke 23:02:01 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 ... if you're going to detect hte problem, it's you can fix it 23:02:17 shane: it's the perf cost of fixing it, though 23:02:23 nikos: also only some implementations would need to fix it 23:02:32 ... the problem with cutting out some path segments if they're going to look funny is generated data 23:02:42 ... 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 ... 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 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 ... I don't think we should treat it like an error 23:03:27 shane: I can't argue with that 23:03:42 Tav: ok, so we'll put some examples in the spec 23:04:00 ACTION: Nikos to add examples pointing out stroke painting inconsistencies between platforms, warning the author 23:04:00 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: nikos can you review the stroke shape generation algorithm since that's where these normative relaxations would have to go 23:05:07 Topic: arc linejoin fallback 23:05:16 http://tavmjong.free.fr/SVG/LINEJOIN_STUDY/#arcs 23:05:47 Tav: just above that, fallback for miter clip 23:06:05 ... 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 ... the above one you see a flash because all of a sudden you fall back to bevel 23:06:30 ... but there's no reason to, you can still clip at the miter-clip position 23:07:39 ... I think it's just a matter of Cameron taking this into account in the stroke linejoin algorithm 23:07:48 AmeliaBR: that's certainly what I'd expect, that you can extend the stroke by the miter-limit line 23:07:56 ... when you have that parallel join 23:08:12 ACTION: Cameron to fix the linejoin algorithm to handle parallel miter-clip issue 23:08:12 Created ACTION-3832 - Fix the linejoin algorithm to handle parallel miter-clip issue [on Cameron McCormack - due 2016-02-10]. 23:08:19 Tav: so now miter linejoin fallback 23:08:30 ... I don't think the current fallback behaviour doesn't look good 23:08:36 AmeliaBR: what about falling back to round? 23:08:44 Tav: it would look better, but still give you an abrupt change in behaviour 23:08:58 shepazu has joined #svg 23:09:00 ... at the end of the page, look at examples of using this line join in a squiggle 23:09:09 ... if you fallback to a round linejoin it wouldn't look good 23:09:20 ... the miter linejoin doesn't look too bad, but there are cases as you see above that it can look bad 23:09:28 ... so some kind of fallback where you preserve some of the curvature 23:09:31 ... I came up with three options 23:09:43 ... at first I thought 2 and 3 would be mathematically difficult, turns out not so bad 23:09:59 ... 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 ... so Fig 7, 8 and 9 are the three fallback options 23:10:36 ... Option 1 still has a discontinuity, Option 2 & 3 are continuous so I would favour one of those 23:10:49 ... they're both similar level of complexity 23:10:59 ... I saw we choose either 2 or 3 then I'll do a survey of artists to see what they prefer 23:11:07 the talons still seem really long in 2 & 3 23:11:18 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 AmeliaBR: it seems to be kicking in later with option 3 than option 2 23:11:53 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 ... in Fig 11, you can see that falling back to a round line join looks better, and avoids having cutout regions 23:12:33 ... round linejoins don't have problems with sharp curves 23:13:00 present+ 23:13:03 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 ... that's my constructing the curves, there's a slight error 23:13:16 s/.../Tav: / 23:13:22 ed: as an artist I'd say that's not what you want 23:13:27 RRSAgent: this meeting spans midnight 23:13:37 Tav: ideally you'd want a sprial, but that's too complex 23:13:50 shane: what about a variant of option 1 that morphs between the curved and straight variants? 23:13:57 ... with option 1 the talon doesn't get excessively long 23:14:17 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 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 ... I don't see the fact that the talons get long as particualrly being a problem 23:14:56 ... if you don't want the talon long, you don't make the two segments parallel at the end 23:15:01 shane: with generated data you might have no choice 23:15:11 AmeliaBR: probably wouldn't be using this line join on a data vis 23:15:18 Tav: you can always put a miter limit on 23:15:35 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 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 nikos: anyone not happy with option 2 or 3 as fallback? 23:16:18 ... I think I like 3 over 2, esp if you fix the curvature 23:16:24 ... prob would prefer option 1 if it was continuous 23:16:32 ... but I'd be happy with any 23:16:34 +1 for option 3 23:16:36 s/any/any of option 2 or 3/ 23:16:45 Tav: I've got these partially implemented in Inkscape 23:16:57 ... when I've fixed the bugs I'll release that in a trunk version that people can test 23:17:14 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 RESOLUTION: arcs fallback will be option 2 or 3 depending on survey feedback 23:17:49 ACTION: Tav to survey whether option 2 or 3 would be better for arcs fallback 23:17:49 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 Topic: Animation of SVG paths with Web Animations 23:18:11 Tav: my worry was that this would fall through the cracks 23:18:19 ... but talking to people this will end up in a spec somewhere 23:18:36 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 shane: I believe that Cameron was working on that this morning 23:19:07 ... 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 ... hasn't fallen through the cracks 23:19:27 AmeliaBR: one extension that goes beyond Web Animations is introducing more flexibility in how you interpolate different paths 23:19:45 ... 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 ... 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 ... and therefore make it a lot more flexible to do those sorts of animations 23:20:39 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 ... 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 ... I certainly would be interested to move in that direction 23:21:06 Tav: would like to avoid getting complicated right now 23:21:18 ... I think maybe doing the line->bezier would be an exception, since that's an easy thing to do 23:21:35 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 ... the rules aren't hard, just whether to introduce new impl requirements or not 23:21:51 ... and I agree at this stage we shouldn't 23:21:58 AmeliaBR: I would say there's huge authoring demand for this 23:22:10 ... when GSAP (?) introduce this, you can morph paths you don't have to carefully construct the paths to match 23:22:15 ... so there's certainly demand for this 23:22:32 ... but let's not do it piecemeal 23:22:41 BogdanBrinza: sounds like a good Level 1 / Level 2 thing 23:22:57 ... we can start with the same number/types of commands for Level 1, then extend in Level 2 23:23:07 shane: are we having a Path module? 23:23:09 heycam: yes there is one 23:23:13 Tav: fine with me 23:24:01 heycam: I'll continue working on that this afternoon 23:24:19 AmeliaBR: the natual place for it might be CSS Transitions spec, which has rules for all other datatypes 23:24:25 ... not sure if they want us to start throwing path data in there 23:24:33 ... if not, then in SVG 2 Paths chapter which just repeats that rule about how to interpolate two paths 23:24:58 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 Topic: initial value of 'd' property 23:25:31 ed: I chatted with Eric Willigers last night, and noted lack of initial value for d 23:25:37 ... question is whether none or the empty string 23:25:56 AmeliaBR: can we all agree that an empty path really means nothing, because that impacts on stuff like bbox calcualtions 23:26:12 ... you don't want that empty path contribute a dot at the origin to group bbox calculations 23:26:28 ... 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: I think having none and path("") be the same would be fine, with none being the initial 23:27:48 shane: also think about computed values 23:27:58 AmeliaBR: also should normalization be done in the computed values? 23:29:18 AmeliaBR: wouldn't we treat path("") as invalid syntax and dropped at parse time? 23:29:32 shane: no I don't think that should be invalid 23:29:55 ... just to be clear: path { d: path(""); } 23:30:13 AmeliaBR: I did send a reply to your mail about path() 23:31:52 heycam: so what about the d="" presentation attribute, shoudl we be accepting path() in there in addition to raw path syntax? 23:32:33 shane: it's a non-starter to set d with a fill rule and make that affect the fill-rule property 23:32:41 ... so we'd need to ignore the fill rule value in there 23:32:46 AmeliaBR: we need the fill rule for clip-path 23:32:56 shane: yes. I suggest having two variants of path(), and spec authors choose which one 23:35:00 heycam: we can't use raw path data in the property value 23:35:04 ... CSS parsing problems 23:35:25 ... 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 AmeliaBR: then we could also extend to CSS shapes in there like circle() 23:35:52 q+ 23:36:05 q- 23:36:25 ack shane 23:36:31 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 ... 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 ... making this a function rather than a raw function makes it way easier to add new syntaxes in the future 23:38:10 heycam: so should we allow path() in the presentation attribute too? 23:38:21 shane: decide once we decide to extend the d property syntax? 23:38:31 AmeliaBR: it wouldn't be hard to support... you don't have to parse far to tell 23:38:56 heycam: true. also happy to leave it for now. 23:39:12 a/than a raw function/than a raw string/ 23:39:20 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 ... or if the path() has a fill rule valid it's invalid? 23:39:38 shane: I don't think we've made a decision, but I suggest the latter 23:39:47 ... if you provide a fill rule for a property that doesn't accept one then that's an error 23:41:42 ... probably the most CSS-y way to do this is pull the fill-rule of the property out of the path() 23:41:53 AmeliaBR: this has already shipped in some places, though 23:41:59 ... so path() should match up with the other CSS Shapes functions 23:42:17 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 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 shane: if so then you wouldn't have the fill-rule inside the path() 23:44:03 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 AmeliaBR: I would prefer generalizing it 23:44:53 heycam: I think it's safe to disallow now and open up later if we need to 23:45:37 shane: I'd like someone to summarize this discussion and send it to the CSS list 23:45:50 heycam: I don't think ignoring the value inside there is such an extreme change 23:46:07 AmeliaBR: as it is now you can use the fill rule in properties where it has no effect 23:46:20 shane: but in this case the fill-rule has an effect but we throw it away 23:46:36 heycam: someone can write it up and ask the CSSWG 23:46:39 shane: I'll do it 23:47:09 ACTION: Shane to ask CSSWG if disallowing fill rule in path() for d is good 23:47:10 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 Topic: Animation of path data 23:48:01 nikos: Bodgan points out we missed out on a resolution 23:48:29 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 ... just c/p the paragraphs from SVG 1.1 23:48:49 ... and we also agreed that the Paths module would include more flexible path interpolation rules 23:48:51 ... TBD later 23:49:32 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 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 ping AmeliaBR: We're back 00:10:28 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 heycam: that's better. Existing rules should stay the same, but new options become available. 00:11:11 Topic: GitHub 00:11:16 nikos: this is about how we want to track our work, issues 00:11:26 ... I've been experimenting with filing issues there, tagging them 00:11:38 ... I like the environment, it tracks the whole conversation, easy to drop in a comment and point to something 00:11:42 ... seems like it would work very well 00:11:55 ... there are other things too, hooking in with the spec build process if we want, hooks on issues being added etc. 00:11:59 +1 to all Nikos has done to get GitHub rolling... 00:12:04 ... might be an option once we have time 00:12:09 s/+1/+100/ 00:12:17 ... the challenge there is moving everything to one place, and not falling back to old habits 00:12:21 ... keeping conversations from getting fragmented 00:12:31 ... comments from people who've used GH more would be good 00:12:34 ... and others' feelings 00:12:50 shepazu: first I want to mention that W3C most WGs are moving to GH, increasingly our toolchain is geared around GH 00:12:54 ... so we'd be going with the flow 00:13:02 ... there are ways to reflect issues into the mailing list 00:13:06 ... some people find that problematic 00:13:12 ... personally I feel it's a good place to archive our conversations 00:13:31 ... 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 ... 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 ... it lets you visualise what's going on, it's a useful organisational tool 00:14:14 ... in general people are more prone to comment on GH than MLs, it's lower commitment 00:14:21 ... so I'm in favour of it 00:14:26 ... I'm not GH expert but I'm conformtable with it 00:14:57 BogdanBrinza: we've been using it for some internal projects 00:15:03 ... it's very useful for discussions and code in the same place 00:15:10 ... test cases, commits, it's incredibly useful 00:15:23 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 nikos: one of the negatives is that it's online 00:15:36 ... if you want to read conversatiosn offline it might be difficult 00:15:46 shepazu: if you reflect issues to a mailing list that's resolved 00:15:50 ... you can even respond to issues via email 00:16:15 ... one downside is some organisations aren't allowed to participate on GH, because you can post code there 00:16:20 ... I don't think it's a problem for our WG 00:17:01 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 ... for Git repos it's fine, since you have copies everywhere else 00:17:20 ... the issues are hosted exclusively on GH, so it's a dependency on that company 00:17:30 ... copying to a ML should be fine as a backup 00:17:47 Tav: I think that is an improtant issue, inkscape for example relied on sourceforge 00:17:56 ... somebody bought it, it's changed completely, we're moving off it 00:18:25 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 shane: I think we have a tool for migrating issues between GH projects 00:19:35 nikos: I could run a GH Enterprise thing at work and mirror the issues 00:19:41 shane: one thing that would be nice is an IRC interface 00:19:53 ... right now we have Tracker, and the only benefit to tracker is its IRC interface 00:20:14 s/shane/shepazu/ 00:20:19 ... 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 ... so we could say issue #15 in the channel and open/close issues 00:20:42 nikos: we also have the W3C action tracker, and just have an issue assigned to someone 00:20:55 shepazu: yes, especially now with Zakim also no longer being useful 00:20:58 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: Houdini redirects any issue discussing emails on the ML to GH, do we want to do that too? 00:22:31 nikos: [thumbs up] 00:22:44 shepazu: I think being in GH "issues" focuses more on specific issues, too, rather than general discssion 00:23:11 ... 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 ... this would help us track stuff more 00:24:14 shane: what about contributions from people not in the WG? 00:24:18 s/shane/shepazu/ 00:24:26 shepazu: generally it's not a problem, some people worry about it though 00:24:50 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 ... that's done on PRs 00:25:31 birtles: if we use GH more, we're more likely to get PRs 00:25:40 ... what's the situation with regards to IP, do they need to sign a CLA 00:25:52 ... 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 ... but there is some requirement for people outside those categories 00:26:10 ... not sure we can fulfill that requirement by sticking something in the README.md? 00:26:40 GitHub process for defining contributing agreements: https://help.github.com/articles/setting-guidelines-for-repository-contributors/ 00:27:26 AmeliaBR: this is not something unique to W3C 00:27:36 ... all open sources communities have to deal with making sure people who contribute aren't going to sue 00:28:11 ... 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 shepazu: I should know this, but I'm not sure. I will research this and get back to you tmr. 00:29:09 AmeliaBR: one of the most important aspects is tagging issues well 00:29:31 ... 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 ... similarly for things on the ML, do you want to have a chair's reponsibility to turn that into an issue? 00:29:52 ... or reply to ask the commenter to put it on GH? 00:30:08 nikos: I'm happy to keep doing this, and we should help the author by filing the GH issue for them 00:30:19 ... on the subject of tags, I think it's important to get that worked out early 00:30:30 q+ kanban board 00:30:37 q+ 00:30:37 ... 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 ... so at the moment I've got tags for each spec, then tags for each chapter of SVG 2 00:30:54 ... then there are a few others like "needs CSS review" 00:31:06 ... I think we could use more tags, if people have suggestions feel free to just create them or bring it up 00:31:19 AmeliaBR: my one suggestion is to have a single document that outlines the tagging scheme 00:31:34 nikos: as an outcome of this discussion, I can write up a wiki page describing the GH workflow, tagging, etc. 00:31:55 ack kanban 00:31:57 ack board 00:31:59 https://waffle.io/w3c/svgwg 00:32:01 nikos: what about GH wiki? 00:33:08 shane: Houdini moved to the GH wiki 00:33:14 nikos: I'll lay down some best practices in a wiki page 00:33:33 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 ... so I'll make sure that's set up correctly 00:33:48 https://waffle.io/w3c/svgwg 00:34:09 ... this is a kanban board 00:34:23 ... each column is a label 00:35:29 ... you have to auth by clicking the person icon in the bottom left of the page 00:35:44 https://waffle.io/w3c/webpayments 00:36:18 ... we have things broken down into New, Actions, Discussion, Proposals, In Progress, Postponed an Done 00:36:21 s/an D/and D/ 00:36:44 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 https://waffle.io/w3c/annotation 00:37:25 shepazu: discussion is for things that will come up in the next telcon 00:37:31 ... editing for when an action is assigned to do it 00:37:44 ... there are different ways, we can pick our own labels 00:37:50 ... this is a 3rd party service waffle.io 00:38:06 ... we're trying to make something like this for W3C, but you can drag items between these different groups 00:38:09 ... and that resolves them 00:38:14 ... you can raise new issues etc. 00:38:23 ... we don't have to use this, but it might be useful 00:38:25 nikos: I like it 00:39:59 shepazu: one danger is if there are different repos, this doesn't reflect that 00:40:08 AmeliaBR: there's a way of cross linking issues between repos 00:40:18 shepazu: but we'd need to maintain a master list of issues in our repo 00:40:57 heycam: we have all our specs in the one repo 00:41:11 AmeliaBR: but there is an FX repo 00:41:27 shepazu: that's where that issue mover tool comes in handy 00:41:55 shane: overall: awesome! 00:42:10 ed: so are we using the kanban? 00:42:15 https://github.com/w3c/licenses 00:42:24 nikos: I'm happy to. everyone doesn't need to... 00:42:29 https://labs.w3.org/hatchery/ash-nazg/ 00:43:38 shepazu: maybe the agenda could reference other issues 00:44:02 nikos: or a special board for telcons 00:44:06 shepazu: or just a label 00:44:13 ... that does mean more work for you (chairs), but it's not much 00:45:18 AmeliaBR: one issue with GH issues is you can't attach SVG files 00:45:24 ... you have to zip it or host it elsewhere 00:45:57 nikos: realistically I'd put things in jsfiddle and link to it, so it's not a dealbreaker 00:47:23 shepazu: I can raise the issue of SVGs on GH issues 00:47:39 Topic: SVG 2 issues 00:47:45 s/GH issues/GH issues and wiki/ 00:47:47 nikos: the main goal is that people should have something to work on for the rest of the day 00:48:01 Tav: does anyone have not have spec editing to work on this afternoon? 00:48:05 Tav: otherwise we should just get on to it 00:49:04 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 shane: sure 00:50:10 BogdanBrinza: in SVG Integration, looking at currently interoperable external resources in use 00:50:15 ... and CSS sizing behaviour 00:50:27 ... it's mostly interoperable, the spec didn't help us, so we had to build our cases 00:50:37 ... while looking at SVG integrations the issues there are fairly light 00:50:41 ... and tmr make a call on them? 00:50:45 q+ to ask about xlink:href 00:52:11 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 AmeliaBR: sizing issues come up a lot for authors 00:52:43 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 ... but it's fairly close 00:53:27 ... 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 ... I'll give more details tomorrow 00:54:03 shepazu: changing topics, I still write SVG from time to time, doing it by hand I still struggle with xlink:href 00:54:13 ... AIUI the only implementation right that supports barename href is Edge 00:55:09 ... how the spec on that? 00:55:12 heycam: spec changes have been made 00:56:31 shepazu: href seems like low hanging fruit 00:56:48 BogdanBrinza: I would imagine implementors would be willing to contribute tests suites they have intenrally, once we know the right framework 00:56:51 ... I'm not sure what to do there 00:56:58 shepazu: could I ask if you have tests for this? 00:57:02 BogdanBrinza: for SVG sizing etc. we do 00:57:09 ... I think we have close to 200 tests 00:57:15 shepazu: could I get you to report back on what tests to contribute? 00:57:16 BogdanBrinza: sure 00:57:30 birtles: as for the format, we've decide we're doing testharness.js in WPT, and reftests 01:00:26 http://www.meetup.com/SVG-AU/events/228075250/ 01:11:34 I agree. Should a Vector Effect chapter be put on both cooords and painting? 01:13:48 stakagi: I think that's fine. but have the primary property definition blue box in the Coords chapter 01:15:39 heycam: O.K. 01:18:28 RRSAgent, make minutes 01:18:28 I have made the request to generate http://www.w3.org/2016/02/03-svg-minutes.html nikos 01:19:14 AmeliaBR has joined #svg 03:22:39 stakagi has joined #svg 04:26:31 https://github.com/w3c/svgwg/pulls