SVG Working Group Teleconference -- 26 May 2016

<scribe> scribe: AmeliaBR

Closepath & missing coordinates

Nikos: When I was updating the path grammar to allow Z to fill in missing points, I realized there was a problem when the previous segment was an H or V: might not be able to connect up.
... Amelia proposed that it could draw a horizontal or vertical line followed by a separate close path, but I think that is overly complicated.
... The purpose of this feature is to allow curves to connect up to end point without an extra (0-length) closepath segment.
... So I think we've got agreement, I'm just going to make it invalid to have missing coordinates on H or Z.
... I should be able to finish it today & push to GitHub.

Issues blocking CR

<nikos> https://rawgit.com/nikosandronikos/svg2-cr-issues/master/svg2-cr-issues.html

<nikos> https://github.com/w3c/svgwg/issues/44

Nikos: There are a lot of issues flagged "needs editing". But there are a few others which may need decisions.
... Issue 44 relates to conditional processing and audio/video playback. I think this is mostly editorial, not sure if there's a debate.

AmeliaBR: Since no one else has chimed in, I think we can go ahead with the interpretation I proposed (conditional processing stops all playback)

Nikos: Is it worth testing current implementations?

Amelia: There are no current implementations of audio/video in SVG.

Doug: So should we remove it altogether? Or at least, not make it a priority?

Amelia: We could mark audio/video at risk. But still need to spec it clearly enough that it could actually be implemented.
... If we're not going to spec it properly, then the alternative is to remove the feature altogether, which is just as much work.

Doug: It's a matter of time and priorities. We need commitments from browser vendors (at least 2) that they are interested in implementing these features in the next year.

Nikos: I think this is a fairly straightforward implementation process, and there was interest in it.

<nikos> https://github.com/w3c/svgwg/issues/99

Nikos: I've marked Issue 44 as needs editing. Next is issue 99.
... defining <use> elements with shadow DOM, assigned to Amelia

Amelia: This is still one my priority item, but I've been working on the accessibility specs instead.
... From what I looked at, it should be mostly straightforward, but there are a number of areas where things have not been well defined (in SVG 1.1) or not implemented as defined, so one way or another there will be breaking normative changes.
... Specific complications include whether shadow DOM elements should be accessible and have event targeting, be able to receive focus.
... Also there are href & patterns/gradients. I would like to define those with the same model.

Nikos: For the accessibility parts, will that need to be defined in SVG 2? What's the timeline for that?

Amelia: Most of the accessibility details will be in SVG-AAM, but we'll need to define focus handling in SVG: can shadow elements within a <use> receive focus? That's new for SVG 2, since there was no focus handling in SVG 1.1
... On timelines, ARIA 1.1 should go to CR around same time as SVG 2. Then the supplemental specs should be tidied up in following months. Right now, the accessibility details are waiting for SVG to be finalized.

<nikos> https://github.com/w3c/svgwg/issues/101

Nikos: Issue 101 relates to foreign-namespaced content in <title> and <desc>.

Amelia: Right now, as the accessibility mappings are defined, any markup inside title/desc has no effect, only plain text is used, so namespaces don't have any effect

Nikos: Can we leave it undefined, then?

Amelia: We can leave it as allowed, but has no effect.

<nikos> https://github.com/w3c/svgwg/issues/102

Nikos: This is related to title/desc

Amelia: That one's assigned to me & I have related actions from the Accessibility task force.
... Last I looked at it, realized it's going to need a lot of re-writing.

<nikos> https://github.com/w3c/svgwg/issues/139

Nikos: Issues with respect to Switch

Amelia: This is a master issue linking a number of others. Some are editorial clean-up, but others need decisions. Things that were never well defined in SVG 1.1: Do we want to define them now to do something useful, or is that too much complication at this point?

Nikos: OK, I'll try to review more closely for next week, see if I have any ideas.

<nikos> https://github.com/w3c/svgwg/issues/118

Amelia: It would be great to have 1 meeting for all the switch-related issues, since they're interconnected.

Nikos: Issue 118 was with scoped attribute on style elements. But it looks like that's been removed from HTML for now, so nothing for us to do to synchronize.
... There are remaining issues on Text, maybe Tav knows the status.

Tav: A number of those are waiting on CSS. A few things Fantasai had said she'd had changes ready, but I'm not sure that they've been published.

Nikos: Can you email www-svg with a list of the specific changes we're waiting on. Might speed things along.

Tav: I'm not sure whether we had a decision on Issue 103, re filters and <tspan>

https://github.com/w3c/svgwg/issues/103

Amelia: The issues there go beyond filters. It comes down to whether <tspan> and <textPath> are now treated as independent graphics elements, and how does that interact with anything that relies on the object bounding box.
... we decided that they can be transformed, but that's actually different from inline spans in CSS styled HTML.

Tav: I'm happy reverting the ability to transform tspan/textPath if that makes it more consistent. It was added in based on the transform attribute being valid for an <a> element in SVG. Is it valid on a link in HTML?

Amelia: In HTML, doesn't matter the element type. It matters the CSS display type. A normal inline link can't be transformed, need to turn it into a block.
... This still leaves the question of filters. Because that would have been allowed under SVG 1.1, not sure whether it actually worked in implementations. Don't want to disallow something the previously worked.

Nikos: In that issue (103), there are links to bug reports in Firefox and Chrome. Both had problems, but different.

<nikos> ACTION: Nikos to look at issue #103 [recorded in http://www.w3.org/2016/05/26-svg-minutes.html#action01]

<trackbot> Created ACTION-3843 - Look at issue #103 [on Nikos Andronikos - due 2016-06-02].

Amelia: So, 2 issues in there: Can the filter spec be redefined to allow textPath/tspan to still have filters even though they are otherwise like inline elements? And, how do we define the correct bounding box on a tspan/textPath, not only for filters but also paint servers?

<nikos> https://github.com/w3c/svgwg/issues/88

Nikos: Issue 88 relates to images & whether we can synchronize with HTML's resource fetching algorithm. I don't think this is critical. I'll leave it assigned to Bogdan if he has a chance to follow up with us.

<nikos> https://github.com/w3c/svgwg/issues/135

Nikos: Issue 135 is marked as needs WG input, relates to gradient transform

Amelia: I don't think there's any debate about what this should be, it's just a question of whether the normative text clearly describes it.

Nikos: I think that's all we have for needing discussion right now. Everyone needs to continue with their assigned actions.

Amelia: An FYI, I'll be focusing on the two issues we discussed today (use elements and title/desc). I also have an action for editorial clean-up of the rendering chapter; that probably won't happen before Amsterdam, but I don't think there would be any normative changes, anyway.

- DRAFT -

SVG Working Group Teleconference

26 May 2016

Attendees

Contents

Closepath & missing coordinates

Issues blocking CR

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output