Minutes, 3 March 2016 SVG WG telcon

Hi all,

Minutes from today’s telcon are at:
https://www.w3.org/2016/03/03-svg-minutes.html


And as text:

   [1]W3C

      [1] http://www.w3.org/


                               - DRAFT -

                    SVG Working Group Teleconference

03 Mar 2016


   [2]Agenda

      [2] https://lists.w3.org/Archives/Public/www-svg/2016Mar/0000.html


   See also: [3]IRC log

      [3] http://www.w3.org/2016/03/03-svg-irc


Attendees

   Present
          nikos, stakagi, AmeliaBR, shepazu, Tav

   Regrets
          heycam

   Chair
          Nikos

   Scribe
          Nikos

Contents

     * [4]Topics
         1. [5]Clarify focus management for SVG & define
            rendered/non-rendered elements
         2. [6]`d` geometric property needs a clear & extensible
            name
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   trackbot, start telcon

   <scribe> Scribe: Nikos

   <scribe> scribenick: nikos

Clarify focus management for SVG & define rendered/non-rendered
elements

   [9]https://github.com/w3c/svgwg/pull/55


      [9] https://github.com/w3c/svgwg/pull/55


   <AmeliaBR> [10]https://github.com/w3c/svgwg/issues/50


     [10] https://github.com/w3c/svgwg/issues/50


   AmeliaBR: This is the PR - it has specific details in the
   comments
   ... Rich had initially gone through html focus section replaced
   html specific with svg specific and put it in svg 2
   ... at the f2f it was agreed we don't want that
   ... was confusing for implementers to realise the differences
   ... so we resolved to defer to html
   ... there's certain issues where that doesn't apply neatly
   ... we need clear definitions
   ... other issues where teh way keyboard is handled differently
   in svg
   ... html defers to platform support and let's people do what
   they've been doing all along
   ... but that doesn't work for svg because it's not consistent
   or accessible
   ... so in the PR I've pulled out the new normative requirements
   that we have in the draft
   ... a normative requirement to visibly show which element has
   keyboard focus
   ... that's standard for html and required for wcag
   ... but not all browsers do this in svg
   ... I've got wording to make requirement apply only if user is
   using the keyboard
   ... think it's good to make that a must requirement rather than
   a should
   ... the other main thing is listing which element is visible by
   default
   ... the only confusion is that there was a behaviour where
   Presto browsers where links weren't part of the main tabindex
   ... so got an extra complication in there about this
   ... not sure if it's necessary, maybe we can make links part of
   the main tabindex
   ... that would be much simpler
   ... another controversial thing is 'should respect svg tiny
   focusable attribute'
   ... also got a should if you change focus to an element that is
   off screen you should scroll or pan it into view
   ... it's got complications with the lack of support for the svg
   1 zoomandpan
   ... which is a whole separate issue
   ... also included a few more things because I think they're
   really important for authors to know for svg
   ... but it's just repeating content that is hidden in the
   depths of html

   nikos: seems reasonable to pull out the important specific
   points

   AmeliaBR: as far as what to do next - throw it out for a few
   days on the ML and ask for objections?
   ... the only other thing that Rich brought up was wondering if
   it would confuse things to link to the stable html5 section
   instead of the html 5.1 section which has a lot of new
   complications that aren't relevant to svg and that haven't been
   implemented yet
   ... so that section may get a lot of editing
   ... not sure what their schedules are

   nikos: I think we should link to the stable spec - that
   wouldn't cause any problems would it ?

   AmeliaBR: The new spec doesn't add anything relevant to svg, it
   only confuses things

   nikos: I think the PR looks ok. Would be happy to put this to
   the ML for objections. Think if there were people with strong
   views or a big interest in this they should be pinged
   personally

   AmeliaBR: what's the timeframe for getting comments

   nikos: For SVG 2 we have some time - is there a time factor
   from the accessibility group?

   AmeliaBR: if we could get a resolution by next week on the
   focus that would be good
   ... I may split the section based on controversionalness

   nikos: Since we don't have quorum I'll ask for a resolution via
   email on the list. Will give one week for objections.

`d` geometric property needs a clear & extensible name

   [11]https://github.com/w3c/svgwg/issues/49


     [11] https://github.com/w3c/svgwg/issues/49


   AmeliaBR: someone did some quick edits at the Sydney F2F.
   Upgraded both path type attributes
   ... I have some concerns over that because of the different
   feature the path is on
   ... we have path on hatch and mesh
   ... and we don't have polyline or points as a property in css
   ... I would like to see points on polygon/polyline treated the
   same way as d on path
   ... and I'd like to see the path of a textPath treated
   separately
   ... so it can be developed in future without confusing the
   syntax
   ... we've had proposals like stretching letters between two
   paths

   nikos: the textPath path is the basepath, if it was named that
   way we could add additional controlling paths later

   Tav: the syntax for the hatchpath and meshpath are different

   AmeliaBR: because they're path fragments?

   Tav: meshpath you can only have bezier and line
   ... for hatch path you drop the initial moveto

   nikos: I was going to say we need to make the distinction
   between path data that needs moveto and doesn't, didn't realise
   mesh path was so different

   AmeliaBR: we could restrict some of them from becoming css
   properties. I'm not hugely in favour of that because it's
   confusing for authors

   nikos: I think renaming is generally the direction people want
   to go in
   ... not so sure about not making all of them properties but if
   we satisfy the use cases people are asking for then we should
   be ok in the short term
   ... Is anyone able to make a proposal which we can get a
   resolution on?

   AmeliaBR: I'm a bit hesitant to take on extra tasks at this
   point
   ... there's a simple proposal for the CSS geometry properties
   using shape functions but there's complications with a cohesive
   dom representation
   ... which I'd like to see eventually but wasn't expecting to do
   in the next couple of months

   nikos: Could you write up what the minimal proposal would be on
   the github issue. Then if I get time before the April F2F I can
   take a look at it, or we can sit down together in April and
   bash it out

   AmeliaBR: Looks like all on the call are in favour of keeping
   separate properties for separate concepts and maybe have a
   single property for unifying similar concepts in paths vs
   polygons

   nikos: yes

Summary of Action Items

Summary of Resolutions

   [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 Thursday, 3 March 2016 22:12:53 UTC