- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Thu, 3 Mar 2016 22:12:17 +0000
- To: www-svg <www-svg@w3.org>
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