SVG Working Group Teleconference -- 03 Mar 2016

trackbot, start telcon

<scribe> Scribe: Nikos

<scribe> scribenick: nikos

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

<AmeliaBR> 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

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

- DRAFT -

SVG Working Group Teleconference

03 Mar 2016

Attendees

Contents

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

`d` geometric property needs a clear & extensible name

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output