20:27:51 RRSAgent has joined #svg 20:27:51 logging to http://www.w3.org/2016/03/03-svg-irc 20:28:03 RRSAgent, start telcon 20:28:03 I'm logging. I don't understand 'start telcon', nikos. Try /msg RRSAgent help 20:29:39 trackbot, start telcon 20:29:41 RRSAgent, make logs public 20:29:43 Zakim, this will be GA_SVGWG 20:29:43 I do not see a conference matching that name scheduled within the next hour, trackbot 20:29:44 Meeting: SVG Working Group Teleconference 20:29:44 Date: 03 March 2016 20:29:48 Chair: Nikos 20:30:06 Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Mar/0000.html 20:30:11 present+ nikos 20:34:18 present+ stakagi 20:35:56 present+ AmeliaBR 20:36:41 present+ shepazu 20:36:59 present+ Tav 20:39:48 Scribe: Nikos 20:39:52 scribenick: nikos 20:40:12 regrets: heycam 20:41:59 Topic: Clarify focus management for SVG & define rendered/non-rendered elements 20:42:05 https://github.com/w3c/svgwg/pull/55 20:42:42 https://github.com/w3c/svgwg/issues/50 20:42:42 AmeliaBR: This is the PR - it has specific details in the comments 20:43:02 AmeliaBR: Rich had initially gone through html focus section replaced html specific with svg specific and put it in svg 2 20:43:07 ... at the f2f it was agreed we don't want that 20:43:16 ... was confusing for implementers to realise the differences 20:43:22 ... so we resolved to defer to html 20:43:31 ... there's certain issues where that doesn't apply neatly 20:43:34 ... we need clear definitions 20:43:58 ... other issues where teh way keyboard is handled differently in svg 20:44:10 ... html defers to platform support and let's people do what they've been doing all along 20:44:18 ... but that doesn't work for svg because it's not consistent or accessible 20:44:35 ... so in the PR I've pulled out the new normative requirements that we have in the draft 20:44:55 ... a normative requirement to visibly show which element has keyboard focus 20:45:04 ... that's standard for html and required for wcag 20:45:08 ... but not all browsers do this in svg 20:45:34 ... I've got wording to make requirement apply only if user is using the keyboard 20:45:42 ... think it's good to make that a must requirement rather than a should 20:45:56 ... the other main thing is listing which element is visible by default 20:46:12 ... the only confusion is that there was a behaviour where Presto browsers where links weren't part of the main tabindex 20:46:18 ... so got an extra complication in there about this 20:46:28 ... not sure if it's necessary, maybe we can make links part of the main tabindex 20:46:34 ... that would be much simpler 20:46:51 ... another controversial thing is 'should respect svg tiny focusable attribute' 20:47:39 ... also got a should if you change focus to an element that is off screen you should scroll or pan it into view 20:47:52 ... it's got complications with the lack of support for the svg 1 zoomandpan 20:47:58 ... which is a whole separate issue 20:48:20 ... also included a few more things because I think they're really important for authors to know for svg 20:48:35 ... but it's just repeating content that is hidden in the depths of html 20:48:50 nikos: seems reasonable to pull out the important specific points 20:49:14 AmeliaBR: as far as what to do next - throw it out for a few days on the ML and ask for objections? 20:49:51 ... 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 20:49:56 ... so that section may get a lot of editing 20:50:01 ... not sure what their schedules are 20:50:43 nikos: I think we should link to the stable spec - that wouldn't cause any problems would it ? 20:51:00 AmeliaBR: The new spec doesn't add anything relevant to svg, it only confuses things 20:52:23 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 20:52:30 AmeliaBR: what's the timeframe for getting comments 20:52:56 nikos: For SVG 2 we have some time - is there a time factor from the accessibility group? 20:53:18 AmeliaBR: if we could get a resolution by next week on the focus that would be good 20:53:31 AmeliaBR: I may split the section based on controversionalness 20:54:34 nikos: Since we don't have quorum I'll ask for a resolution via email on the list. Will give one week for objections. 20:55:13 Topic: `d` geometric property needs a clear & extensible name 20:55:19 https://github.com/w3c/svgwg/issues/49 20:55:39 AmeliaBR: someone did some quick edits at the Sydney F2F. Upgraded both path type attributes 20:55:50 ... I have some concerns over that because of the different feature the path is on 20:56:00 ... we have path on hatch and mesh 20:56:09 ... and we don't have polyline or points as a property in css 20:56:24 ... I would like to see points on polygon/polyline treated the same way as d on path 20:56:32 ... and I'd like to see the path of a textPath treated separately 20:56:40 ... so it can be developed in future without confusing the syntax 20:56:49 ... we've had proposals like stretching letters between two paths 20:57:34 nikos: the textPath path is the basepath, if it was named that way we could add additional controlling paths later 20:57:44 Tav: the syntax for the hatchpath and meshpath are different 20:57:58 AmeliaBR: because they're path fragments? 20:58:11 Tav: meshpath you can only have bezier and line 20:58:22 ... for hatch path you drop the initial moveto 20:59:26 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 21:00:03 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 21:01:04 nikos: I think renaming is generally the direction people want to go in 21:01:23 ... 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 21:02:05 nikos: Is anyone able to make a proposal which we can get a resolution on? 21:02:13 AmeliaBR: I'm a bit hesitant to take on extra tasks at this point 21:02:45 ... there's a simple proposal but there's complications with a cohesive dom representation 21:03:05 ... which I'd like to see eventually but wasn't expecting to do in the next couple of months 21:03:18 s/proposal/proposal for the CSS geometry properties using shape functions/ 21:04:32 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 21:04:55 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 21:05:02 nikos: yes 21:07:21 RRSAgent, make minutes 21:07:21 I have made the request to generate http://www.w3.org/2016/03/03-svg-minutes.html nikos 22:11:07 stakagi_ has joined #svg