Minutes, 17 March 2016 telcon

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