- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Fri, 18 Mar 2016 00:27:33 +0000
- To: www-svg <www-svg@w3.org>
Hi all, Minutes from this morning’s call are available at: https://www.w3.org/2016/03/17-svg-minutes.html And as text, [1]W3C [1] http://www.w3.org/ - DRAFT - SVG Working Group Teleconference 17 Mar 2016 [2]Agenda [2] https://lists.w3.org/Archives/Public/www-svg/2016Mar/0010.html See also: [3]IRC log [3] http://www.w3.org/2016/03/17-svg-irc Attendees Present nikos, Tav, stakagi, AmeliaBR, shepazu Regrets Chair NIkos Scribe Nikos Contents * [4]Topics 1. [5]Telcon time after daylight savings switch 2. [6]Plans for an authoring practice guide 3. [7]Move path interrogation functions to SVGGeometryElement * [8]Summary of Action Items * [9]Summary of Resolutions __________________________________________________________ <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 [10]https://lists.w3.org/Archives/Member/w3c-svg-wg/2016JanMar/ 0103.html [10] https://lists.w3.org/Archives/Member/w3c-svg-wg/2016JanMar/0103.html <AmeliaBR> [11]http://doodle.com/poll/45vqw5krx8rhfigw [11] 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> [12]http://www.timeanddate.com/worldclock/meeting.html [12] 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 [13]http://www.timeanddate.com/worldclock/meetingtime.html?iso= 20160427&p1=240&p2=179&p3=80&p4=195&p5=248 [13] 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> [14]http://doodle.com/poll/a9p8uph2hka2ebta [14] 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 [15]https://github.com/w3c/svgwg/issues/69 [15] 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. [16]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. [17]Make the pathLength attribute and IDL property available on all elements that implement the SVGGeometryElement interface. [End of minutes] The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Friday, 18 March 2016 00:28:09 UTC