IRC log of svg on 2016-03-03

Timestamps are in UTC.

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