Agenda for Oct 6 meeting

[foolip]

Here's the agenda for our meeting today:

• State of CSS launched and being promoted. Will ask for partial results of the freeform questions in "CSS Usage" and share with interop team next week, before Thu. Those are:
  • Browser Incompatibilities: Are there any existing CSS features that you have difficulties using (or avoid altogether) because of lack of support, or differences between browsers?
  • What features do you feel are currently missing from CSS altogether?
  • Any other pain points related to writing CSS?
• focus-area-proposal Focus Area Proposal : 49 proposals so far
  • https://github.com/orgs/web-platform-tests/projects/2/views/1 is a project board listing spec and test status
• investigation-effort-proposal Investigation Effort Proposal : 1 proposal
• test-change-proposal Proposal to add or remove tests for an interop area
• Other Embedded Content #147 - how to split?

Previous meeting: #162

Apologies for posting this agenda late!

[meyerweb]

Philip: Any topics to add to the agenda?
Brian: Adding in MathML and SVG. It would be good to let people know about the changes in both and have a concrete focus on what we want to get right. Would like to find a way to commit to something.
Philip: Okay, added.

[meyerweb]

Philip: State of CSS Survey has launched. 7,000 responses in the first 24 hours (last year was 8,000 total).
… I’ll ask for partial results of the survey before it closes. The survey will probably still be open on October 15th, when we close for proposals.
… We may also talk about an MDN short survey about Interop 2023 later in this call.

[meyerweb]

Philip: focus-area proposals for Interop 2023 — we suddenly have 49! I made a project board today so I could fill in the spec and testing situation for each proposal. Where there are empty cells, it means I couldn’t figure out which working group was responsible, or if there were any tests.
… 26 are CSS WG, 9 are WHATWG, 7 are non-CSS W3C WGs, a couple from Khronos and TC39, and 5 have no specification identified.
… Probably can’t use the project board to record positions on each proposal. So we’ll make a spreadsheet.
… One proposal is for WebGPU, which is a little odd. It’s not currently shipped, but implementation is happening. The test suite is unfinished and the spec is in flux. So this would be quite different than usual.
… The proposal seems to be to finish the tests and spec.

James G.: I don’t think this benefits from being part of Interop 2023. This doesn’t really fit into our established categories. I don’t expect us to have a positive opinion on this sort of thing.

Philip: I’m wondering how we can communicate that this isn’t a good fit.

James G.: I expect quite a few people are going to find their proposal not accepted.
… Some of the proposals I’ve seen are already bundling things like “we should fix this and also add this new feature!” which is problematic
… We usually take proposals as all or nothing.

Philip: I assume one of the ones you’re talking about is history and navigation. What’s the other?

James G.: Web Components, which has like 10 sub-proposals.

Tim N.: That one should definitely be split.

Philip: Where would you draw the line between splitting things and accepting proposals on the conditoin that some part is withdrawn?

Tim N.: I would support more, smaller proposals, rather than buckets. That way we can organize them into more sensible buckets later on. If we have large, differently-sized buckets, there’s a risk of weird scoring. It’s better for proposals to be as small as they can.

Philip: In the case of History and navigation, I did ask Domenic if it was okay if we did only the cleanup work and not the new Navigation API. He didn’t think that was useful.

James G.: If people think a proposal is only useful if it’s kept in one piece, than that’s a proposal. I don’t know that I agree with it, but that’s their position.

Philip: I would say that if you want to see a proposal split, say so on the issue. We’re not tracking if that request has been made, though.

[meyerweb]

Philip: Test change proposals I looked over earlier and it seems to be in a good place. I think they’re all dealt with in one way or another. Tim, do you agree?

(discussion of various test change issues)

Tim: We could close #137.

Philip: I’ll do that.

Brian: It would be great to mark if we’re landing a new implementation or two and we're hoping to set things off well, or if it’s something that’s been around for a long time and it just has interop issues.

Philip: Hmm. Do these sort neatly into those two categories?

Tim: Maybe proposal could be split up and specific labels could be used.

James: We could flag things as an existing feature that has significant cleanup needed. At the moment, there isn’t a clear distinction.

Tim: I think it would make more sense to put even small fixes into a category rather than sweeping them all into a "web compatibility" category. There are some features that got removed from the forms area, like appearance values.

Philip: Would it be useful to add to a proposal which engines a thing is implemented in? Everyone can edit this, so we can give that a shot.

James: Doesn’t really answer the question of how to deal with proposals that are both cleanup and new implementation.

Brian: I like Tim's idea of splitting things into tiny pieces and then figure out what goes where.

James: I think if we had a policy that proposals have to fit into one of these categories, that would create a useful split. We generally judge the value of fixes versus new features differently.

Philip: I suspect the boundary will be blurry. Like forms this year, which has new API, removing API, and fixing incompatibility. I can add something if it's clear what that thing is, but I'm not hearing anything clear.

Brian: It's a useful exercise to see if we can label the categories, to see if they make any sense.

Tim: We could split it as adding, changing, and removing. I think those are clearly defined.

Brian: Adding would be even if it's landing in one more browser?

Tim: Adding would be things like Cascade Layers, that were implemented nowhere.

Brian: If we rewind a bit, summary/details took 7-8 years to roll out everywhere. At what point does adding become not adding?

James: It makes sense to say it's adding new features or API surfaces in some browsers. Like subgrid, which Firefox had, but it was significant work to add to other engines. But what's the point of these labels? To help people know how to submit? To organize things for ourselves.

Tim: For me, it’s more about grouping.

Brian: For me, it's more about the decision-making process. We should be clear about what we're trying to do. Are we trying to set things on a good path to start, or is it more about filling the potholes? Also, as you're going through these, it's helpful to understand the current status of things based on their category.

Philip: Those who need this information, try adding things to the project board and we'll see what works.

[foolip]

I've filed #191 about the proposals where splitting has been discussed.