19:26:00 RRSAgent has joined #svg 19:26:00 logging to http://www.w3.org/2016/03/17-svg-irc 19:26:02 RRSAgent, make logs public 19:26:04 Zakim, this will be GA_SVGWG 19:26:04 I do not see a conference matching that name scheduled within the next hour, trackbot 19:26:05 Meeting: SVG Working Group Teleconference 19:26:05 Date: 17 March 2016 19:26:13 chair: NIkos 19:26:19 Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Mar/0010.html 19:26:27 present+ nikos 19:29:53 Hmm, is the meeting really now? I though the time was fixed to UTC. 19:30:27 No, the booking is at US EDT 19:31:41 yes, the time is fixed to US EDT 19:31:46 or rather, US ET 19:34:54 OK. I'll call in a couple of minutes. 19:37:44 present+ Tav 19:46:55 AmeliaBR has joined #svg 19:52:13 Scribe: Nikos 19:52:15 scribenick: nikos 19:52:26 Topic: Telcon time after daylight savings switch 19:52:32 https://lists.w3.org/Archives/Member/w3c-svg-wg/2016JanMar/0103.html 19:52:45 http://doodle.com/poll/45vqw5krx8rhfigw 19:54:15 nikos: Don't think we need to discuss this too much yet, but could everyone please fill out the questionnaire 19:55:46 http://www.timeanddate.com/worldclock/meeting.html 19:56:16 AmeliaBR: Doodle has a way to configure polls so that everyone sees results in their own timezone 19:56:23 nikos: I had no idea. That would have been good to use 19:58:34 shepazu: I can do 9am, but not Thursday 19:58:44 Tav: 10:00 and10:30 would work for me on Wednesday 19:59:55 http://www.timeanddate.com/worldclock/meetingtime.html?iso=20160427&p1=240&p2=179&p3=80&p4=195&p5=248 20:00:27 shepazu: Not seeing good options at the moment. Maybe we should look to different days? 20:04:43 Topic: Plans for an authoring practice guide 20:05:16 AmeliaBR: has come up in the accessibility group - there are a lot of accessibility issues where it comes down to authors needing to know how to give information 20:05:28 ... they're general good practices, not always accessibility specific things 20:05:46 ... we think that an svg authoring practices guide will get more attention than svg accessibility practices guide 20:06:07 ... Does this group have issues with the accessibility group leading the way on a general authoring practice guide? 20:06:48 q+ 20:06:50 nikos: I support that. Had concerns when you raised the idea that we don't have time to work on it 20:07:13 ... so if the accessibility group starts and drives this then that would be a nice way to get a document started 20:07:16 http://doodle.com/poll/a9p8uph2hka2ebta 20:08:28 ack shepazu 20:09:25 shepazu: accessibility TF wanted to just make it about accessibility and Amelia, myself and others thought it would not appeal broadly to people who might want to read a document about SVGs best pratices 20:09:45 ... so for every feature that we think is an accessibility feature, i.e. structuring your document 20:09:51 ... making sure you have good navigation, etc 20:10:02 ... we can look at each within the realm of general usability 20:10:26 ... good accessibility is just one of many considerations that we'll put into the document 20:10:47 ... so we'll also point out the other reasons to do something a particular way 20:11:25 nikos: where will this live? 20:11:33 AmeliaBR: talked about creating a repo for the accessibility TF 20:11:39 ... but there are permissions issues 20:12:17 ... we could do it in the svg repo using accessibility build tools 20:14:10 nikos: My main reason for hosting on the svgwg repo is to make it visible to a wider audience 20:14:37 AmeliaBR: there was a plan for chaals to create a repo for just this doco 20:14:45 shepazu: I'll talk to Chaals about hosting within the svgwg repo 20:15:00 ... I think everyone on the accesibility group is part ofthe svgwg so that makes it easier 20:15:15 ... if others want to make contributions we can find a way to make it happen 20:15:54 nikos: Sounds good. Please go ahead and get started and we'll get the hosting organised. 20:16:30 Topic: Move path interrogation functions to SVGGeometryElement 20:16:36 https://github.com/w3c/svgwg/issues/69 20:16:53 AmeliaBR: I put some proposed resolutions in the last comment 20:17:22 ... right now we have these functions that are widely used - getTotalLength and less used getPointAtLength 20:17:25 ... that are available on paths 20:17:41 ... very useful, but currently only available on the path element and not on basic shapes 20:17:57 ... the argument is that now we have basic shapes defined as an equivalent path, why can we not make these apply to basic shapes as well? 20:18:06 Tav: sounds good to me 20:18:21 AmeliaBR: it's a matter of moving those methods from the path specific interfaces to a general interface that covers all shapes 20:18:29 ... we have the SVGGeometryElement that does that 20:18:51 ... should be a straigth forward code change 20:19:21 ... other question is whether authors should be able to provide a pathLength 20:19:53 RESOLUTION: Make the getTotalLength() and getPointAtLength(distance) methods, currently defined on the SVGPathElement interface, available for all elements that implement the SVGGeometryElement interface. The length calculation would be based on the equivalent path for each shape. 20:20:48 AmeliaBR: regarding the pathLength. It has two effects. First is that pathLength calculations are not always perfect so it allows the author to normalise for discrepencies 20:21:08 ... other use is that pathlengths are arbitrary numbers and it's easier to think in certain ranges 20:21:24 ... if the long term goal is to make percentages work based on path length it's less important 20:21:38 Tav: it's good for consistency. You should be able to use it on shapes as well 20:21:47 ... so I'd be in favour 20:22:28 stakagi has joined #svg 20:25:19 AmeliaBR: it's only relevant for declarative stuff 20:25:40 ... you can't use percentages because they are relative to the viewport 20:26:21 ... so pathlength has been abused to allow for relative coordinates on paths 20:26:39 ... even though it was only intended to be used for managing imprecision 20:27:46 shepazu: couldn't we make a keyword that makes percentages relative to path length? so that instead of using this convoluted method of setting pathLength, we allow percentages relative to path length 20:27:52 AmeliaBR: yes that sounds useful 20:28:08 nikos: Tav was going to add an issue regarding this, we were talking about it this morning 20:29:28 ... So I propose we let Tav do that, we have discussion about whether we can break existing behaviour, and we don't go ahead and add pathLength to basic shapes 20:29:50 ... everyone happy not adding pathLength to basic shapes at this point? 20:29:57 Tav: Think we should add it for consistency 20:30:01 shepazu: agree with Tav 20:30:15 ... but we should go ahead and enable percentages relative to the path 20:30:46 Tav: I'll go ahead and make the issue 20:31:03 shepazu: who's using that hack? 20:31:11 AmeliaBR: it's not used alot, but is used for motion path 20:31:51 ... it's not just used for hacky things. It's good for dealing with rounding errors 20:32:06 ... could use it on a circle for example for subdividing 20:32:35 RESOLUTION: Make the pathLength attribute and IDL property available on all elements that implement the SVGGeometryElement interface. 20:33:05 present+ stakagi 20:33:30 ^^ 20:34:08 bye 20:34:47 RRSAgent, make minutes 20:34:48 I have made the request to generate http://www.w3.org/2016/03/17-svg-minutes.html nikos 20:35:57 goo morning; yes I alreay posted pll 21:12:41 Rich has joined #svg 22:14:35 Rich has joined #svg 22:37:04 present+ AmeliaBR 22:37:12 present+ shepazu 22:37:19 RRSAgent, make minutes 22:37:19 I have made the request to generate http://www.w3.org/2016/03/17-svg-minutes.html nikos 23:18:38 Rich has joined #svg