IRC log of svg on 2016-03-17

Timestamps are in UTC.

19:26:00 [RRSAgent]
RRSAgent has joined #svg
19:26:00 [RRSAgent]
logging to
19:26:02 [trackbot]
RRSAgent, make logs public
19:26:04 [trackbot]
Zakim, this will be GA_SVGWG
19:26:04 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
19:26:05 [trackbot]
Meeting: SVG Working Group Teleconference
19:26:05 [trackbot]
Date: 17 March 2016
19:26:13 [nikos]
chair: NIkos
19:26:19 [nikos]
19:26:27 [nikos]
present+ nikos
19:29:53 [Tav]
Hmm, is the meeting really now? I though the time was fixed to UTC.
19:30:27 [nikos]
No, the booking is at US EDT
19:31:41 [shepazu]
yes, the time is fixed to US EDT
19:31:46 [shepazu]
or rather, US ET
19:34:54 [Tav]
OK. I'll call in a couple of minutes.
19:37:44 [Tav]
present+ Tav
19:46:55 [AmeliaBR]
AmeliaBR has joined #svg
19:52:13 [nikos]
Scribe: Nikos
19:52:15 [nikos]
scribenick: nikos
19:52:26 [nikos]
Topic: Telcon time after daylight savings switch
19:52:32 [nikos]
19:52:45 [AmeliaBR]
19:54:15 [nikos]
nikos: Don't think we need to discuss this too much yet, but could everyone please fill out the questionnaire
19:55:46 [Tav]
19:56:16 [nikos]
AmeliaBR: Doodle has a way to configure polls so that everyone sees results in their own timezone
19:56:23 [nikos]
nikos: I had no idea. That would have been good to use
19:58:34 [nikos]
shepazu: I can do 9am, but not Thursday
19:58:44 [nikos]
Tav: 10:00 and10:30 would work for me on Wednesday
19:59:55 [nikos]
20:00:27 [nikos]
shepazu: Not seeing good options at the moment. Maybe we should look to different days?
20:04:43 [nikos]
Topic: Plans for an authoring practice guide
20:05:16 [nikos]
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 [nikos]
... they're general good practices, not always accessibility specific things
20:05:46 [nikos]
... we think that an svg authoring practices guide will get more attention than svg accessibility practices guide
20:06:07 [nikos]
... Does this group have issues with the accessibility group leading the way on a general authoring practice guide?
20:06:48 [shepazu]
20:06:50 [nikos]
nikos: I support that. Had concerns when you raised the idea that we don't have time to work on it
20:07:13 [nikos]
... so if the accessibility group starts and drives this then that would be a nice way to get a document started
20:07:16 [shepazu]
20:08:28 [nikos]
ack shepazu
20:09:25 [nikos]
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 [nikos]
... so for every feature that we think is an accessibility feature, i.e. structuring your document
20:09:51 [nikos]
... making sure you have good navigation, etc
20:10:02 [nikos]
... we can look at each within the realm of general usability
20:10:26 [nikos]
... good accessibility is just one of many considerations that we'll put into the document
20:10:47 [nikos]
... so we'll also point out the other reasons to do something a particular way
20:11:25 [nikos]
nikos: where will this live?
20:11:33 [nikos]
AmeliaBR: talked about creating a repo for the accessibility TF
20:11:39 [nikos]
... but there are permissions issues
20:12:17 [nikos]
... we could do it in the svg repo using accessibility build tools
20:14:10 [nikos]
nikos: My main reason for hosting on the svgwg repo is to make it visible to a wider audience
20:14:37 [nikos]
AmeliaBR: there was a plan for chaals to create a repo for just this doco
20:14:45 [nikos]
shepazu: I'll talk to Chaals about hosting within the svgwg repo
20:15:00 [nikos]
... I think everyone on the accesibility group is part ofthe svgwg so that makes it easier
20:15:15 [nikos]
... if others want to make contributions we can find a way to make it happen
20:15:54 [nikos]
nikos: Sounds good. Please go ahead and get started and we'll get the hosting organised.
20:16:30 [nikos]
Topic: Move path interrogation functions to SVGGeometryElement
20:16:36 [nikos]
20:16:53 [nikos]
AmeliaBR: I put some proposed resolutions in the last comment
20:17:22 [nikos]
... right now we have these functions that are widely used - getTotalLength and less used getPointAtLength
20:17:25 [nikos]
... that are available on paths
20:17:41 [nikos]
... very useful, but currently only available on the path element and not on basic shapes
20:17:57 [nikos]
... 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 [nikos]
Tav: sounds good to me
20:18:21 [nikos]
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 [nikos]
... we have the SVGGeometryElement that does that
20:18:51 [nikos]
... should be a straigth forward code change
20:19:21 [nikos]
... other question is whether authors should be able to provide a pathLength
20:19:53 [nikos]
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 [nikos]
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 [nikos]
... other use is that pathlengths are arbitrary numbers and it's easier to think in certain ranges
20:21:24 [nikos]
... if the long term goal is to make percentages work based on path length it's less important
20:21:38 [nikos]
Tav: it's good for consistency. You should be able to use it on shapes as well
20:21:47 [nikos]
... so I'd be in favour
20:22:28 [stakagi]
stakagi has joined #svg
20:25:19 [nikos]
AmeliaBR: it's only relevant for declarative stuff
20:25:40 [nikos]
... you can't use percentages because they are relative to the viewport
20:26:21 [nikos]
... so pathlength has been abused to allow for relative coordinates on paths
20:26:39 [nikos]
... even though it was only intended to be used for managing imprecision
20:27:46 [nikos]
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 [nikos]
AmeliaBR: yes that sounds useful
20:28:08 [nikos]
nikos: Tav was going to add an issue regarding this, we were talking about it this morning
20:29:28 [nikos]
... 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 [nikos]
... everyone happy not adding pathLength to basic shapes at this point?
20:29:57 [nikos]
Tav: Think we should add it for consistency
20:30:01 [nikos]
shepazu: agree with Tav
20:30:15 [nikos]
... but we should go ahead and enable percentages relative to the path
20:30:46 [nikos]
Tav: I'll go ahead and make the issue
20:31:03 [nikos]
shepazu: who's using that hack?
20:31:11 [nikos]
AmeliaBR: it's not used alot, but is used for motion path
20:31:51 [nikos]
... it's not just used for hacky things. It's good for dealing with rounding errors
20:32:06 [nikos]
... could use it on a circle for example for subdividing
20:32:35 [nikos]
RESOLUTION: Make the pathLength attribute and IDL property available on all elements that implement the SVGGeometryElement interface.
20:33:05 [stakagi]
present+ stakagi
20:33:30 [stakagi]
20:34:08 [stakagi]
20:34:47 [nikos]
RRSAgent, make minutes
20:34:48 [RRSAgent]
I have made the request to generate nikos
20:35:57 [stakagi]
goo morning; yes I alreay posted pll
21:12:41 [Rich]
Rich has joined #svg
22:14:35 [Rich]
Rich has joined #svg
22:37:04 [nikos]
present+ AmeliaBR
22:37:12 [nikos]
present+ shepazu
22:37:19 [nikos]
RRSAgent, make minutes
22:37:19 [RRSAgent]
I have made the request to generate nikos
23:18:38 [Rich]
Rich has joined #svg