W3C

- DRAFT -

SVG Working Group Teleconference

17 Mar 2016

Agenda

See also: IRC log

Attendees

Present
nikos, Tav, stakagi, AmeliaBR, shepazu
Regrets
Chair
NIkos
Scribe
Nikos

Contents


<Tav> Hmm, is the meeting really now? I though the time was fixed to UTC.

No, the booking is at US EDT

<shepazu> yes, the time is fixed to US EDT

<shepazu> or rather, US ET

<Tav> OK. I'll call in a couple of minutes.

<scribe> Scribe: Nikos

<scribe> scribenick: nikos

Telcon time after daylight savings switch

https://lists.w3.org/Archives/Member/w3c-svg-wg/2016JanMar/0103.html

<AmeliaBR> http://doodle.com/poll/45vqw5krx8rhfigw

nikos: Don't think we need to discuss this too much yet, but could everyone please fill out the questionnaire

<Tav> http://www.timeanddate.com/worldclock/meeting.html

AmeliaBR: Doodle has a way to configure polls so that everyone sees results in their own timezone

nikos: I had no idea. That would have been good to use

shepazu: I can do 9am, but not Thursday

Tav: 10:00 and10:30 would work for me on Wednesday

http://www.timeanddate.com/worldclock/meetingtime.html?iso=20160427&p1=240&p2=179&p3=80&p4=195&p5=248

shepazu: Not seeing good options at the moment. Maybe we should look to different days?

Plans for an authoring practice guide

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
... they're general good practices, not always accessibility specific things
... we think that an svg authoring practices guide will get more attention than svg accessibility practices guide
... Does this group have issues with the accessibility group leading the way on a general authoring practice guide?

nikos: I support that. Had concerns when you raised the idea that we don't have time to work on it
... so if the accessibility group starts and drives this then that would be a nice way to get a document started

<shepazu> http://doodle.com/poll/a9p8uph2hka2ebta

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
... so for every feature that we think is an accessibility feature, i.e. structuring your document
... making sure you have good navigation, etc
... we can look at each within the realm of general usability
... good accessibility is just one of many considerations that we'll put into the document
... so we'll also point out the other reasons to do something a particular way

nikos: where will this live?

AmeliaBR: talked about creating a repo for the accessibility TF
... but there are permissions issues
... we could do it in the svg repo using accessibility build tools

nikos: My main reason for hosting on the svgwg repo is to make it visible to a wider audience

AmeliaBR: there was a plan for chaals to create a repo for just this doco

shepazu: I'll talk to Chaals about hosting within the svgwg repo
... I think everyone on the accesibility group is part ofthe svgwg so that makes it easier
... if others want to make contributions we can find a way to make it happen

nikos: Sounds good. Please go ahead and get started and we'll get the hosting organised.

Move path interrogation functions to SVGGeometryElement

https://github.com/w3c/svgwg/issues/69

AmeliaBR: I put some proposed resolutions in the last comment
... right now we have these functions that are widely used - getTotalLength and less used getPointAtLength
... that are available on paths
... very useful, but currently only available on the path element and not on basic shapes
... 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?

Tav: sounds good to me

AmeliaBR: it's a matter of moving those methods from the path specific interfaces to a general interface that covers all shapes
... we have the SVGGeometryElement that does that
... should be a straigth forward code change
... other question is whether authors should be able to provide a pathLength

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.

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
... other use is that pathlengths are arbitrary numbers and it's easier to think in certain ranges
... if the long term goal is to make percentages work based on path length it's less important

Tav: it's good for consistency. You should be able to use it on shapes as well
... so I'd be in favour

AmeliaBR: it's only relevant for declarative stuff
... you can't use percentages because they are relative to the viewport
... so pathlength has been abused to allow for relative coordinates on paths
... even though it was only intended to be used for managing imprecision

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

AmeliaBR: yes that sounds useful

nikos: Tav was going to add an issue regarding this, we were talking about it this morning
... 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
... everyone happy not adding pathLength to basic shapes at this point?

Tav: Think we should add it for consistency

shepazu: agree with Tav
... but we should go ahead and enable percentages relative to the path

Tav: I'll go ahead and make the issue

shepazu: who's using that hack?

AmeliaBR: it's not used alot, but is used for motion path
... it's not just used for hacky things. It's good for dealing with rounding errors
... could use it on a circle for example for subdividing

RESOLUTION: Make the pathLength attribute and IDL property available on all elements that implement the SVGGeometryElement interface.

<stakagi> ^^

<stakagi> bye

<stakagi> goo morning; yes I alreay posted pll

Summary of Action Items

Summary of Resolutions

  1. 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.
  2. Make the pathLength attribute and IDL property available on all elements that implement the SVGGeometryElement interface.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/03/17 22:37:24 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Nikos
Inferring ScribeNick: nikos
Found ScribeNick: nikos
Present: nikos Tav stakagi AmeliaBR shepazu
Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Mar/0010.html
Found Date: 17 Mar 2016
Guessing minutes URL: http://www.w3.org/2016/03/17-svg-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]