See also: IRC log
<scribe> scribe: AmeliaBR
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.
<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.
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: AmeliaBR Inferring ScribeNick: AmeliaBR Present: nikos AmeliaBR Tav shepazu Agenda: https://lists.w3.org/Archives/Member/w3c-svg-wg/2016AprJun/0142.html Found Date: 26 May 2016 Guessing minutes URL: http://www.w3.org/2016/05/26-svg-minutes.html People with action items: nikos[End of scribe.perl diagnostic output]