SVG Working Group Teleconference -- 30 Jun 2016

<stakagi> hello

<scribe> scribe: nikos

<scribe> scribenick: nikos

Publishing new drafts of SVG Accessibility specs

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

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

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

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 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": https://github.com/w3c/svgwg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Needs+WG+input%22

<AmeliaBR> "Needs resolution": https://github.com/w3c/svgwg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Needs+resolution%22

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

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

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.

- DRAFT -

SVG Working Group Teleconference

30 Jun 2016

Attendees

Contents