search

w3c / svgwg

SVG Working Group specifications
Other
704 stars 132 forks source link

SVGWG Agenda TPAC 2019 #731

Open dirkschulze opened 5 years ago

dirkschulze commented 5 years ago

This is an initial thread to collect agenda items for TPAC 2019 in Fukuoka.

Just add new responses for whatever we should discuss at TPAC. We will sort it later.

Agenda

9:00 - 10:30 Session 1

11:00 - 12:15 Session 2

13:30 - 15:00 Session 3

16:00 - 18:00 Session 4 SVG CG

Issues per chapter

Number of issues General
86 Open Issues
40 Marked with needs editing
Number of issues chapter
20 SVG Core
9 Text chapter
6 Document Structure chapter
5 Paths chapter
4 Linking chapter
3 Entire spec
3 Basic Data Types and Interfaces chapter
2 Interactivity chapter
2 Co-ordinates chapter
2 Painting chapter
1 Filters
1 Paint Servers chapter
1 Rendering Model chapter
AmeliaBR commented 5 years ago

As I've mentioned to a few people, I think a primary task should be to plan work priorities, schedules, and assignments for the next year. We will hopefully have people in attendance who don't normally call in to our teleconferences, so maybe we can get some new commitments, or discuss ways to make contributing easier.

For specific issue discussion, we should focus on anything where there are people from outside the group who want to discuss & collaborate while we're in one place. @litherum mentioned some specific issues that @rniwa wanted to talk about (presumably about shadow DOM?) I'm not sure if @r12a or any other internationalization folks want to follow up with any of the open internationalization issues.

We're scheduled to have an SVG community group session in the early afternoon (1:30pm Japan time, I think?). My main agenda item for that is "How to create a better support system for the CG?"

Finally, I wonder if it's too late to ask @foolip or some of the other WPT folks to stop by and help guide us through some of our testing requirements. A good overview of setting up automated ref tests would be helpful. (There's this lovely tutorial that I've been meaning to read, but in person may be better!) I've also been intending to set up some SVG-specific meta tags for things like handling SVG processing modes — what's the best approach for that?. Similarly, it would be nice to tag tests in a way that makes it easier for non-browser implementers to figure out which tests are relevant to them. And maybe add cross-test dependencies so it's easier to track the real failures/passes (& easier to reduce testing time by not running tests that won't give useful results because a dependency has already failed).

(PS, to anyone I've tagged, please comment to let us know if you are interested & what your time constraints would be. Or to tag a colleague in your place!)

gsnedders commented 5 years ago

Finally, I wonder if it's too late to ask @foolip or some of the other WPT folks to stop by and help guide us through some of our testing requirements.

Hi, feel free to ping me on IRC at pretty much any point (or DM me on Twitter if I don't respond or something).

dirkschulze commented 5 years ago

Discussion around <use>-element:

We will discuss everything from security model up to style inheritance changes from SVG 1.1 to SVG2.

foolip commented 5 years ago

Sorry I'm leaving TPAC now, but if I can be of service online just poke me wherevr you can find me!

litherum commented 5 years ago

Here’s some questions that Apple is interested in. We should discuss these with Ryosuke.

https://svgwg.org/svg2-draft/single-page.html#interact-Focus mentions how any element that generates a scrollable region should be treated as if tabindex=0 is set. This is a weird “should” statement given HTML doesn’t do this. It’s also problematic because it would mean that we can’t decide whether an element is focusable or not without layout information

The section also mentions “focusable” content attribute. But it doesn’t really specify what happens when its value is set to “auto” or whether it supersedes tabindex=-1 or not: https://www.w3.org/TR/SVGTiny12/interact.html#focusable-attr

For example, this SVG tutorial asserts that “focusable” would override tabindex: https://allyjs.io/tutorials/focusing-in-svg.html#making-svg-elements-focusable

Given Firefox nor Chrome seems to implement this content attribute, it’s hard to tell what the right behavior is.

Edit: See https://github.com/w3c/svgwg/issues/736

dirkschulze commented 5 years ago

FXTF topics https://github.com/w3c/fxtf-drafts/issues?q=is%3Aissue+is%3Aopen+label%3A%22Needs+SVGWG+Input%2FDecision%22

css-meeting-bot commented 5 years ago

The SVG Working Group just discussed Short status update.

The full IRC log of that discussion <mstange> Topic: Short status update
<mstange> krit: We have 86 open issues. 40 of those are marked needs-editing. They are distributed to different chapters.
<mstange> krit: Issues in SVG Core are spanning multiple sections.
<mstange> krit: What is the expectations for 1. fixing the issues and 2. the timeline when to fix them?
<mstange> krit: So far, AmeliaBR did a lot of changes recently. I tried to keep up but had no chance.
<mstange> krit: The text chapter is still open and requires some contributions to fix them.
<mstange> krit: I don't think we have other members than Tav who's looking at those.
<mstange> krit: Tav is still an active member but he hasn't done any edits in the last two or three months.
<mstange> AmeliaBR: We can definitely go through things like need-editing issues where we know what the changes need to be.
<mstange> AmeliaBR: They just need to be done.
<mstange> heycam: It would be good to have actual names on the issues.
<mstange> krit: Amelia, how much time do you think you can spend on these issues? I will fix the issues assigned to me and maybe 10 more.
<mstange> heycam: I can do some today.
<mstange> krit: Rossen, is there somebody at Microsoft who could join the WG or look at some of the issues?
<mstange> Rossen: I have to check how much time David Storey has. I know he was interested.
<mstange> AmeliaBR: And he's familiar with stuff so it's easy to ramp up.
<mstange> Rossen: And between myself and ??? we can spend some time.
<mstange> krit: We are in the PR state, so we don't expect huge changes.
<mstange> krit: It's going to be mostly small edits.
<Rossen_> s/???/Bogdan/
<mstange> krit: We do not have all the members here. We probably cannot assign all the issues, but certainly some of them.
<mstange> heycam: With the number of open issues discussed, is there (missed)
<mstange> krit: We made some changes that are normative and require a CR update.
<mstange> krit: We should fix as many normative changes as possible.
<mstange> Rossen_: The issues that are currently marked as needs-editing, are those resolved?
<mstange> AmeliaBR: Yes, we know what to write for those issues.
<mstange> AmeliaBR: If the resolution is missing in the issue, sometimes the github bot may have failed to pull them out of the transcript.
<mstange> Rossen_: What about the definitions for the transform-box?
<mstange> krit: We have those definitions already, just in the wrong place.
<mstange> Rossen_: I was just trying to gauge how ready the need-editing issues are.
<mstange> AmeliaBR: Every change goes through review. Make a PR, don't just commit.
<mstange> krit: At least one member needs to review.
<mstange> krit: We can go through the issues marked as needs-editing and take a brief look at them, and assign some of them.
<AmeliaBR> s/transform-box/svg layout box vs css layout box, that looks more than editorial/
<mstange> krit: If you prefer, you can take a look first privately and then assign them.
<mstange> krit: As for plans for the future: heycam asked if there will be a new CR. I strongly think we should fix the normative issues first.
<mstange> krit: I will ask Apple and Mozilla people to help out with contributing.
<mstange> krit: AmeliaBR, what are you proposing for next year?
<mstange> AmeliaBR: So much of it is who has time to work on things. We have lots of pressure from W3C management to actually get something published.
<mstange> krit: Having a timeline would communicate what we think the status of the SVG 2 spec is.
<mstange> heycam: Do we have a good idea of what work is left to do, apart from knowing "this many issues"?
<mstange> AmeliaBR: "This many issues" for editing. We have a few big ones, like cleaning up the use element sections.
<mstange> AmeliaBR: If we don't get any implementer commitment for wrapping text, we have to clean up the text chapter.
<mstange> AmeliaBR: There's also lots of other cleanup to do, most of which to address issues brought up by implementers saying "this isn't clear".
<mstange> AmeliaBR: This won't be done by the end of the year, which was the target date in the charter.
<mstange> AmeliaBR: Next spring, assuming as many people as have been working or more can keep working on it, and assuming we don't have too many more of "something's broken in this section, can you fix it?".
<mstange> AmeliaBR: That's the issues we know about. Testing is still a whole other task.
<mstange> krit: We have had 60 commits this year. To fix the 80 issues, we probably need at least 80 commits, so we'll need at least another year at the current rate.
<mstange> AmeliaBR: Teleconferences and bug testing take up time.
<mstange> krit: My current expectation is that we don't expect to have the spec finished by the end of the year. But maybe by TPAC next year? Would be more realistic. That does not include testing yet.
<mstange> krit: That's something that needs to be done in parallel.
<mstange> AmeliaBR: Aiming for final CR (I don't think we can call it a PR without a test suite) in advance of next TPAC is reasonable at the rate we're going. If we have more people, it might speed up.
<mstange> heycam: I think that is a good goal to work towards.
<mstange> krit: Anything else to discuss?
<mstange> AmeliaBR: The second side is testing. We're supposed to write tests as we make edits. We haven't been very great about that. We do have some people like Eric ??? pulling through and cleaning up tests and posting them, so we have some tests added.
<mstange> AmeliaBR: How high of a priority should adding tests be, from an implementers' perspective?
<mstange> heycam: In some ways, the test suite is dependent on the spec.
<mstange> krit: If we fix something, should be we be required to write tests along with it?
<mstange> heycam: If both all of the spec editing work and the test work needs to be done before PR, and if it's not going to discourage people from making test edits, then yes. It should even save time!
<mstange> AmeliaBR: Especially for any normative edits we should make the tests at the same time.
<mstange> krit: Issues that are fixed in terms of spec editing work but don't have tests should marked with the needs-test label.
<mstange> github: https://github.com/w3c/svgwg/issues/731
<mstange> krit: Anything else?
<mstange> AmeliaBR: We need more active contributors.
<mstange> krit: If the issue is the telecon time, we can work on that.
aphillips commented 5 years ago

Would you like i18n (@r12a and I) to visit you today? We're free now until 2pm or can possibly meet between 3 and 5.