See also: IRC log
<Tavmjong> +Tav
<scribe> scribe: AmeliaBR
<nikos> http://lists.w3.org/Archives/Public/www-svg/2016Apr/0030.html
NA: I sent out an email, since it
was only a small group there.
... We got a lot done, but will also discovered a number of
issues during the review & clean-up.
... We've got ~67 open issues on GitHub. Mostly editorial,
don't need a resolution.
... I wanted to get people's ideas about best plan for moving
towards CR.
... Option 1 is to spend next few weeks getting as much done as
we can, set a hard deadline, then publish CR as is.
... But there would almost certainly be remaining issues. Also
appendixes and stuff need lots of clean up work.
Option 2 is have another Editor's meeting. Suggestion is Amsterdam in June when Amelia's there for a conference.
scribe: And try to get spec to 100% for CR.
Tav: I could probably get my issues done in next few weeks, but not sure about rest of spec.
NA: We've got a lot of issues in chapters which don't have active maintainers the past few weeks.
ABR: For myself, the specific issues I took ownership of I should be able to get done in next month. But there are chapters we didn't get to in the review, and lots of clean-up issues we noted but which don't have owners yet.
DS: So the real question is how
can we get more people involved?
... For member companies that have been active in the past but
not currently, we may get more engagement if we can show
progress and a clear plan for what needs to be done.
NA: There is probably not a single solution; many different reasons people have not been active.
DS: True, but one reason is that it has been a long slog, and people have gotten frustrated by lack of visible progress.
NA: Any ideas how to show progress?
DS: Clear assessments for each
chapter, summarizing outstanding issues and who has committed
to address which. A progress report, basically, with a timeline
for how much work needs to be done, how long it would take, on
each chapter.
... Breaking down the problem into small components.
... Or would this process be so time consuming itself that it
would defeat its purpose?
NA: I don't think so. I was planning on something similar anyway, as part of reaching out to group members to see how they can contribute.
<nikos> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment
DS: How much work is it? Do we have a single tracking location?
NA: We did have this wiki page, but it's rather out of date. I was thinking of maybe adding some script to GitHub, where all our issues are.
ABR: GitHub does have a "Milestones" feature for grouping & tracking issues that block a project. Haven't used it myself, but I think it would be relevant.
DS: I don't have a lot of time, but I can take a few issues that don't need a lot of background research.
NA: I will contact others, see if we can get more people signing up for issues, but I think CR would be end of June.
NA: London meeting was productive, would like to do it again if it can work. Amelia's in Europe again & I've received permission to go, and we have a number of other WG members with limited travel budgets in the area.
DS: We may be able to get a host from CWI in Amsterdam.
NA: That would be great. We don't need much, just a conference room, wifi, and maybe some tea-making facilities.
DS: And I think Microsoft and
Google also have offices in Amsterdam.
... What are the dates?
NA: Sunday, June 19 - Wednesday June 22. If Sunday is difficult for meeting space, could start the Monday.
DS: I myself won't be able to make it. Neither the budget nor the time.
<nikos> http://cssday.nl/2016
<nikos> https://github.com/w3c/svgwg/issues/18
NA: SVG 2 currently says that it is there (deprecated) for historical reasons, but only ~50% of current implementations support it, so interoperable behavior doesn't exist.
ABR: I lean towards deprecating
something in one spec, removing it in next. But there are lots
of other things in SVG 2 that have been removed outright.
... What are the details on lack of support? Was this a choice
to remove, have their been complaints?
DS: If it's in WebKit but not
Blink, Blink must have removed at some point. There may be a
discussion thread somewhere.
... Do we have a way of marking things in the spec as obsolete,
instead of deprecated?
NA: No, I don't think so.
DS: Having a deprecated version before obsolete is mostly convention to support transition. But not relevant if support has already been removed from implementations.
ABR: Sounds good. I don't think we need a new section on "obsolete" APIs, but we do need to make sure the "What's changed" appendix is updated to clearly indicate any API from SVG 1.1 that has been removed.
RESOLUTION: Remove the window.SVGDocument alias from SVG 2.
<nikos> https://github.com/w3c/svgwg/issues/61
NA: I've done some reading since
adding this to the agenda. I'm not sure I'm ready to make a
decision yet.
... The <base> element changes how in-document links are
interpreted. So, if you have a fill referencing a paint server,
it will be relative to the base URL, not automatically in the
same document.
... I think the desire is to be consistent with HTML. But it
does often seem problematic with SVG.
<nikos> http://andronikos.id.au/base.svg
Tav: Can you put a <base> in a SVG? Can you override the value?
NA: This test file (link above) shows current behavior. We know allow HTML <base> in SVG, but only one per document. xml:base has been deprecated.
ABR: The lack of override is an unfortunate limitation of <base> relative to xml:base. Would be more convenient to be able to reset the base for inline SVG. It comes up a lot in problems with single-page app frameworks; questions come up on StackOverflow.
NA: I'll follow-up with TabAtkins, who raised this on www-style
ABR: Another important aspect of the discussion on www-style is whether URL references should be re-computed if <base> changes (as it does in these single-page app frameworks): causes implementation issues.
NA: I'll look into this further. Thanks for the added information; I'll assign the GH issue to myself.
DS: In the SVG Accessibility Task
Force, we started work on SVG Accessibility Authoring Guide,
but decided it would be best framed as an overall SVG Authoring
Guide. Most best practices have both accessibility and other
benefits.
... I've been working with chaals MN and Fred Esch. We've
decided to start fresh with a new document, rather than what
we'd been working on.
... Should get an initial skeleton published in next few
weeks.
... If anyone has ideas on what should be in it, let me know.
Or you can file issues when it's published.
... I would like to publish it on the main SVG repo instead of
the SVG Accessibility repo.
NA: Sounds good. What are the particular differences that you decided to start from scratch?
DS: Well the original is from
~2001, very outdated & made incorrect assumptions about how
things would work.
... chaals had re-started, but his draft was still very
accessibility focused, wanted to generalize.
trackbot, end telcon
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) Succeeded: s/CLI (?)/CWI/ Found Scribe: AmeliaBR Inferring ScribeNick: AmeliaBR Default Present: Tav, nikos, stakagi, shepazu, AmeliaBR Present: Tav nikos stakagi shepazu AmeliaBR Agenda: http://lists.w3.org/Archives/Public/www-svg/2016Apr/0028.html Found Date: 28 Apr 2016 Guessing minutes URL: http://www.w3.org/2016/04/28-svg-minutes.html People with action items:[End of scribe.perl diagnostic output]