Agenda for Mar 16, 2023

[nairnandu]

Here is the proposed agenda for Mar 16, 2023

• [css-color-4] Big number serialization problem #296
• Remove Offscreen Canvas filter tests #297
• Remove container query test dependent on Houdini Layout API #300
• Blocking metrics updates on test regressions #276
  • Write non-OK harness statuses to a log file results-analysis#150 needs review
  • Create a workflow for maintaining a list of labeled tests in-repo #288 needs review (avoiding accidental test list changes)
• Finish the Interop Team Charter #275

Previous meeting: #287

[foolip]

For the charter, https://github.com/web-platform-tests/interop/pull/102/files/c55227d21b7d28be694cea0924c3a96e1edfd91f..3ce967af43e3d046fe620a483cbf65b1c08357be are the changes I just pushed, trying to match what we discussed in #275.

[bkardell]

minutes:

Attendees:

• foolip
• nandu nair
• dan clark
• simon pieters
• tim nguyen
• sam sneddon
• bkardell

---

[css-color-4] Big number serialization problem #296

foolip: not specific to this, we should probably just avoid that

sam: this is about the max of colors in css, and we're just seeing it through serialization

james: yes, I'm not sure I understand the state of the issue. I would interpret what emilio said as "that sounds reasonable to use the smaller number as you suggest for interop" but that we should also create tests (not for interop) for the big numbers

foolip: this is a submitted test

Simon: Seems like the spec needs to change - webkit and chromium have different behavior

foolip: you're saying the test should be marked as tentative?

Simon: I haven't looked at the test, but if it doesn't match

Sam: no this is just about rounding - the spec requires at least 10 bits for p3, for example but the test requires more -

foolip: it seems its 41 bits... so yeah, we'll review that test separately, but the resolution should be at least to change ...

Sam: I think this is intentional in CSS, I'm not sure the test should even be tentative

foolip: So how about we don't add a test and ...

James: It is better to have a test and mark it as tentiative than to have nothing if browsers are doing something different. We shouldn't just ignore the fact that it's undefined

bkardell: suggest we take this test to csswg and ask for clarificatioin

jen: agree with bkardell. I don't like the idea of leaving a test in interop that doesn't belong there though. We should remove the test from interop

James: Yeah, I think we all agree to that part. As I understand everyone agrees this should not be a part of interop and the question is should google add a tentive test and who should have a say in that/why. It definitely isn't part of interop 2023

---

Remove Offscreen Canvas filter tests #297

Tim: there are tests relying on the filter api which gecko and webkit don't implement for canvases - I think this is orthogonal to offscreen canvas itself.

James: We said this in the initial issue so I think these shouldn't have been added in the first place.

bkardell: we agree we should remove them

nandu: any objections?.... ok... awesome.

foolip: I will make it so.

---

Remove container query test dependent on Houdini Layout API #300

Tim: One of these tests is testing something about the houdini layout api, it seems out of scope

James: I'm pretty confident we're supportive of removing it

bkardell: I agree

James: we've had a bunch of these cases where tests are relying on an unrelated feature for this topic. If you happen to support the one it should work and the test is valid, but you don't have to have one for the other.

nandu: any objections?... ok... cool.

foolip: I am doing it now

---

Blocking metrics updates on test regressions #276

nandu: we discussed this a few meetings back but we didn't arrive at a conclusion.

foolip: I have two reviews out that get us halfway there:

• Write non-OK harness statuses to a log file results-analysis#150 needs review
• Create a workflow for maintaining a list of labeled tests in-repo Create a workflow for maintaining a list of labeled tests in-repo #288 needs review (avoiding accidental test list changes)

If we can get both of those done, I can do a third PR to get us all the way there. I think sam self assigned one earlier today?

sam: yeah, I'll review it..

james: what's the whole workflow you're imagining there

foolip: that's so that if someone adds or removes one without our review....

james: but explain how you're saying this helps us? It queries the metadata and gives us a list -- at what point are we looking at it to see that something ununsual happened?

foolip: It updates with a pull request, so it has to be reviewed. It is going to be a little annoying when it is a change we have already decided to do, but we can just push those through

james: is this just the alert system them - the cannonical list is the metadata

bkardell: I think it is the cannonical one eventually? Because the whole reason we're doing this I think is in case we don't approve of that and want to change it.

james: yeah, you could imagine changing the way it allows metadata too so it just doesn't allow that without requiring approval.

foolip: Yes, it's possible -- I don't know how we'd do that. I think there is necessary scaffolding missing. I might know how I could do it, but I think it would redundant - this work is already done and I'm not really super inclined to do it again... If someone else wants to volunteer

james: my concern is mainly that this becomes a thing we don't actually look at because it's just a lot of noise and who cares or something. I just worry this could be more hassle in the long run because there are effectively 2 sources of data

foolip: Ok I will file an issue and see if maybe there is a way we can just not let people add or change that metadata without approval.

sam: Ok I will review both of those too

---

Finish the Interop Team Charter #275

foolip: I posted 2 changes about 5 minutes before the meeting so it's no suprise nobody had time to review this -- I described a chair role and an expanded scope that includes browser specfic failures. If we could get that charter change reviewed the charter would be unblocked.

james: Do you want some high level comments now based on skim reading right now

foolip: sure

james: Chair, sure. I might just remove the word elected because that suggests there is a specific process ...

foolip: It just says elected by concensus... but sure, "appointed" or something is fine

james: yeah I just think we should avoid the word 'election' here because nothing else involves 'voting' either.. I'm not sure why we have an extended scope - I have to think a bit more about the bsf because I'm not sure we've decided what we want to do with that at all and I don't want to suggest that this is a thing we have to do - I think we have to have a lot of converstaion, and I think we certinaly should be careful not to write the charter in such a way that assumes some outcome there.

foolip: Do you think that the wording does that?

james: I think it implies it has to continue to exist as a matter of chater. Maybe it could say "it is also possible for us to publish other metrics and make it clear that for example wpt has given us ownership over this specific one". I think the charter doesn't have to say anything about browser specifc failures, but something else - the rfc can make that clear.

sam: yeah, I think this should be in the rfc too because it really needs to be decided by the core team anyway.

foolip: Please reply in there with your suggestions!

sam: Ok I will help find someone who will do that.

---

CSSWG resolved to clarify Flexbox Intrinsic Main Size algorithm
#94

foolip: I talked to Jen about this a while ago - I don't think we need to keep watching. If they make some changes then we might have something to talk about..

tim: agree

james: agree

foolip: I will follow up on the issue

---

[forms] Don't include appearance tests for square-button / push-button / slider-horizontal #295

tim: depending on csswg issue we can potentially remove those from wpt altogether. I don't think there is anything we should do here until then

simon: I dont think we should remove the tests regardless of what csswg says... they should be removed from interop based on what the csswg resolves

james: you could update them to say they do nothing. the use counters I think are almost nothing, the interop value isn't great either. I don't have strong opinions - I'll leave these comments

---

Remove tests that depend on CSS zoom test-change-proposalProposal to add or remove tests for an interop area
#298 opened 5 days ago by emilio

foolip: I assume that the state of standardizing zoom is nowhere still?

james: It is completely noninteroperable

simon: there is no spec

james: I mean like "we don't even understand and agree what it should do"

foolip: If we mark these as tentative is there a spec issue we can reference?

nandu: Ok, so we agree we will unlabel it and then ... it's not part of interop, but it might be tentative or something

simon: we might very well have to come back to this

james: basically it is not implemented in gecko and emilio thinks we can't do what chrome and webkit do so he has a proposal, but it is ... complicated and unclear if that will work..

simon: I think chris h has also said they were looking into whether blink could change what they do and simplify so we could get interop

nandu: ok, we've removed the interop label

---

Remove appearance cssom tests that require the removal of values needed for compat #299

Tim: webkit implements two appearance values they can't remove - the apple pay and vertical slider ones

james: I will say I don't agree with the argument in here because it absolutely can be the case that people adding something non-standard can create problems... however, if we don't have concensus to include these tests, then we don't have concensus and should remove them

simon: And the replacement for slider-vertical doesn't exist

foolip: How many tests are we talking about?

Tim: I prposed splitting the tests, probably just splitting the invalid ones

simon: there are some invalid ones that chrome is failing

james: I think it is ok - it's one of the tradeoffs of interop that there's no way to easily excude a few things in a test, we have to sometimes just change the tests to break them out and that's ok

foolip: is the apple-pay one a historical test or does someone say you shouldn't..?

simon: CSS includes the grammar and how to parse and that includes this

james: I think the only question for us is whether we just remove them from WPT or whether we split them out

simon: splitting them out seems fine to me

foolip: can we talk about vertical slider..?

simon: It's about ranged slider in the vertical direction. This was a way that was added before appearance was standardized

james: There is no question it's not currently a valid value.. I guess I'm more inclined to split that one out so we could flip the bit on that one if that changes.. I dont really care what we do with apple pay

foolip: I think whatever webkit team wants to do with that is fine.