- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Thu, 30 Jun 2016 22:23:07 +0000
- To: www-svg <www-svg@w3.org>
www.w3.org/2016/06/30-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
30 Jun 2016
[2]Agenda
[2] https://lists.w3.org/Archives/Public/www-svg/2016Jun/0017.html
See also: [3]IRC log
[3] http://www.w3.org/2016/06/30-svg-irc
Attendees
Present
nikos, stakagi, AmeliaBR, Tav
Regrets
Chair
Nikos
Scribe
nikos
Contents
* [4]Topics
1. [5]Publishing new drafts of SVG Accessibility specs
2. [6]Avoiding camel case name for meshGradient
3. [7]Better error handling for nested links
4. [8]SVG 2 CR publishing plans
5. [9]Restore SVGSVGElement.prototype.getElementById
6. [10]Gradient stop colours with transparency values
7. [11]Unknown elements behaving as g
* [12]Summary of Action Items
* [13]Summary of Resolutions
__________________________________________________________
<stakagi> hello
<scribe> scribe: nikos
<scribe> scribenick: nikos
Publishing new drafts of SVG Accessibility specs
[14]https://lists.w3.org/Archives/Public/www-svg/2016Jun/0016.h
tml
[14] https://lists.w3.org/Archives/Public/www-svg/2016Jun/0016.html
AmeliaBR: Does anyone need to know anything not in the email?
... We're looking to publish the three specs
... The one that has the most interesting content from the SVG
side is the SVG AM
... which talks about how the basic svg semantics should be
interpreted from an SVG perspective
... the changes had to do with tricky little things
... like if you have conflicting information from an author,
which should you expose
... a lot was based on implementer feedback
... there's definitely still some open issues
... the graphics spec is pretty innocuous
... but the AAM spec has issues about use elements, view
elements, and we've created new roles for graphics, but
creating them for ARIA isn't enough - you have to have
something in the OS API
... so there's a lot of collaborative work to go on there
nikos: what's the timeline that you expect to get these to CR?
AmeliaBR: think the goal is this year
... There's dependencies. The SVG AAM relies on changes being
made to SVG 2 - especially wrt to use elements
... similarly it's dependent on changes to ARIA 1.1, which
we're trying to lock down this summer
... once those two specs are CR it'll be easier to sort out the
remaining issue
... and there'll be more peple with more time to work on them
RESOLUTION: SVG WG agrees to publish FPWD of SVG Graphics API
Mappings, and updated WD for WAI-ARIA Graphics Module and SVG
Accessibility API Mappings
Avoiding camel case name for meshGradient
[15]https://github.com/w3c/svgwg/issues/181
[15] https://github.com/w3c/svgwg/issues/181
nikos: So we recently agreed that mesh gradients will be split
into a geometry element and a paint server element
... currently the paint server element is called meshGradient,
but we've had complaints from implementers, particularly Tab
Tav: I'd like to get feedback from other implementers
AmeliaBR: I would like more feedback, but I'm not sure if we're
going to get it
... I personally don't think there's an optimal solution
nikos: I agree
AmeliaBR: we still have this situation where old elements are
camel cased and new elements are not
Tav: my thinking is that if anyone besides Tab complains then
I'd be willing to drop the camel case
... and go with meshgradient
nikos: +1 to meshgradient
Tav: no one is going to be writing meshgradients by hand
AmeliaBR: Simple four point gradients maybe?
Tav: I've done it but it's very tough
AmeliaBR: there's other places where you get tripped up - not
just writing SVG code. E.g. you might defining selectors
nikos: Having a quick look at an old conversation
[16]https://www.w3.org/2015/02/11-svg-minutes.html#item03
[16] https://www.w3.org/2015/02/11-svg-minutes.html#item03
scribe: looks like general consensus is for consistency
nikos: How about we try for more feedback. If we get feedback
that camel case is bad, we'll make it gradientmesh, otherwise
we'll keep it meshGradient and see what happens
... it's only a very small spec change
... at least we know what names we'll pick in each case
Better error handling for nested links
[17]https://github.com/w3c/svgwg/issues/178
[17] https://github.com/w3c/svgwg/issues/178
AmeliaBR: At the F2F I made some changes to allow nested links,
because it seemed logical to allow them
... got feedback that supporting it is a complete disaster
... both in SVG and creating nested links via script
... the HTML parser doesn't allow them, but they can be created
in the DOM using JS
... given there's no pressing need for nested links - you can
still have sibling elements that visually interact
... and there's no easy way to address the problems on the
accessibility side - they just don't expect to find nested
links
... my argument is to revert that and go back to nested links
being invalid
... second part is the error handling
... the way it's currently worded in SVG is that any element
that appears when it shouldn't don't render at all
... so for browsers that follow that, any nested link doesn't
show
... so along with unknown elements now rendering, we should
allow nested links to at least render
Tav: For me the question is having nested links useful?
... even having special forgiving behaviour is going to require
chanes
AmeliaBR: anything is going to require changes somewhere - we
don't have interop
Tav: so is having nested links something we'd want long term?
... we had the example of tspan inside text
... text links somewhere, tspan links somewhere else
... if we have nested graphical elements, like circle inside a
rectangle, then you might want to have nested links
... I don't have a strong feeling for this
... if we do allow fallback, it might prevent us having nested
links in future
AmeliaBR: if we define it as an invalid case. It's not changing
the handling of a valid document, it's changing error handling
... if it was supported it could be useful, but I don't think
it's essential
... there's other ways to achieve the same effect
Tav: I'd prefer to leave things but won't object
nikos: I don't have a strong opinion either way. If we drop the
href, they'd still be usable as an anchor
... we'd need to be clear on that
AmeliaBR: yeah we wouldn't mess with the DOM
nikos: My thinking of not rendering it at all is that at least
it's a clear indication that you're doing something wrong
AmeliaBR: I'm more concerned about accidental things - if you
have an svg with a link inside and you put that inside a html
link
Tav: I like immediate feedback
nikos: The other argument is that unknown elements currently
render. That may change as it's at risk
AmeliaBR: are we talking nested links or nested a elements? Not
all a elements are links
nikos: So all nested a elements should show. Only link a
elements wouldn't function as links
AmeliaBR: we can mark it at risk and keep it in sync with
unknown elements
nikos: Which implementations do what?
AmeliaBR: Blink and Webkit don't render. FF and Edge do - links
work if you're clicking, but they're not effectively exposed to
screen readers
... I haven't tracked whether that's a browser issue, screen
reader issue, or API issue
... My preference is to allow rendering but require nested link
functionality be ignore
RESOLUTION: Nested a elements will render but href attribute
will be ignored. But if unknown elements (at risk) are changed
to not render, a elements will also then not render.
<scribe> ACTION: Amelia to make changes wrt nested a elements
[recorded in
[18]http://www.w3.org/2016/06/30-svg-minutes.html#action01]
[18] http://www.w3.org/2016/06/30-svg-minutes.html#action01]
<trackbot> Created ACTION-3847 - Make changes wrt nested a
elements [on Amelia Bellamy-Royds - due 2016-07-07].
AmeliaBR: I'll add an at risk note also
SVG 2 CR publishing plans
nikos: At the end of the Amsterdam F2F I said two more weeks to
get everything we want done
... how are people going for that?
Tav: I haven't had a chance. That was expected though. Will
have time this week
nikos: I was having a look at the inline issues in the spec.
Making sure no normative ones are in there. One biggish one
with coords chapter, but I'll do that next week
... also been looking into what I need to do to publish
... should take me a day to work through the steps that Cameron
wrote up
AmeliaBR: I just need to look at the use element stuff
nikos: The document structure had some inline issues so they
should go when you do use element rewrite
... ok so let's review progress at next week's telcon, then
I'll publish the week after
AmeliaBR: we have a few issues that would be good to get more
feedback. They're tagged 'needs resolution' in GH
nikos: I'll send an email to the group today and try to get
wider input
<AmeliaBR> "Needs WG input":
[19]https://github.com/w3c/svgwg/issues?q=is%3Aissue+is%3Aopen+
label%3A%22Needs+WG+input%22
[19] https://github.com/w3c/svgwg/issues?q=is:issue+is:open+label:"Needs+WG+input"
<AmeliaBR> "Needs resolution":
[20]https://github.com/w3c/svgwg/issues?q=is%3Aissue+is%3Aopen+
label%3A%22Needs+resolution%22
[20] https://github.com/w3c/svgwg/issues?q=is:issue+is:open+label:"Needs+resolution"
nikos: Add CR milestone too
... to cut down the list
Restore SVGSVGElement.prototype.getElementById
AmeliaBR: I'm fine with it's a method that's widely supported
and moderalyte useful so why not put it back in the spec
<AmeliaBR> [21]https://github.com/w3c/svgwg/issues/182
[21] https://github.com/w3c/svgwg/issues/182
nikos: There was no question I was going to add it back into
the spec
... Just wanted to understand the WG thinking in the past
AmeliaBR: I like your suggestion of add it back in and suggest
using other options
nikos: I was curious of the perf difference of getDocumentById
vs querySelector for ids
... jsperf is down =(
AmeliaBR: logically it shouldn't be that different for a simple
id selector
Gradient stop colours with transparency values
[22]https://github.com/w3c/svgwg/issues/180
[22] https://github.com/w3c/svgwg/issues/180
AmeliaBR: We don't define what to do if gradient stop colour
values have transparency
... CSS specs say to premultiply so that the colour strength is
proportional to the transparency
... main reason to doing this is so that blue to transparent
looks as people would expect - fading out blue rather than
fading blue to transparent black
... my argument is that we should follow those rules
... problem with that is that there is still some debate on css
side as to whether that's the best behaviour
... also canvas gradients do the opposite
Tav: answer is what happens with opacity 0.99?
AmeliaBR: It's scaled - strength is proportional
Tav: I need to think about this
nikos: I want to do some testing too - I haven't had time so
far
AmeliaBR: There's a little extra math for implementers if we go
with this
... my argument is for consistency
... good for authors and hopefully good for implementers
... but because we have three techs making gradients, and we're
not going to have interop between all of them I'm feeling less
strongly that we need to align with CSS rather than canvas
... right now we have lots of implementations
nikos: I was also wondering if it's a platform dependent result
rather than just a browser result
... curious what Cairo does for example
<AmeliaBR> [23]http://codepen.io/AmeliaBR/pen/jrBOBv/
[23] http://codepen.io/AmeliaBR/pen/jrBOBv/
nikos: would be good to try FF on linux and WebKit GTK
Tav: FF on linux, the top one matches the bottom one and the
middle two match
AmeliaBR: so that's the same as what we get everywhere except
for with WebKit
nikos: Let's leave as an open issue. We need more time to
investigate. At least with multiple different implementations,
we can align with the one we think is most correct
AmeliaBR: I'd like to get feedback from CSS as to how close
they are to resolving this issue
Unknown elements behaving as g
[24]https://github.com/w3c/svgwg/issues/179
[24] https://github.com/w3c/svgwg/issues/179
AmeliaBR: We say unknown elements behave as the g element
... but g isn't allowed everywhere
... my suggestion is to make it an a without an href - that can
go in more places
Tav: I don't think an a is a good model
<AmeliaBR> <text>Some <i>fancy</i> text</text>
nikos: I think the point is that where it makes some sense to
render, then we can render via g. If it doesn't make sense for
g then it probably makes sense to actually ignore
AmeliaBR: use case is with text
... so treat unknown as tspan inside text
RESOLUTION: Treat unknown elements as tspan when inside text.
Presentation and inherited style apply, but nothing specific.
Summary of Action Items
[NEW] ACTION: Amelia to make changes wrt nested a elements
[recorded in
[25]http://www.w3.org/2016/06/30-svg-minutes.html#action01]
[25] http://www.w3.org/2016/06/30-svg-minutes.html#action01
Summary of Resolutions
1. [26]SVG WG agrees to publish FPWD of SVG Graphics API
Mappings, and updated WD for WAI-ARIA Graphics Module and
SVG Accessibility API Mappings
2. [27]Nested a elements will render but href attribute will
be ignored. But if unknown elements (at risk) are changed
to not render, a elements will also then not render.
3. [28]Treat unknown elements as tspan when inside text.
Presentation and inherited style apply, but nothing
specific.
[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, 30 June 2016 22:23:51 UTC