The tests in css/css-ui/compute-kind-widget* are no longer justified by any spec test

[othermaciej]

The tests in css/css-us/compute-kind-widget*, which all browsers currently fail, don't seem to be justified by any current spec text. They were added in PR #30267 which cites whatwg/html#7004 , but that HTML PR text is in longer in the spec. The section of CSS Basic UI it references doesn't appear to exist any more.

These tests are included in Interop 2022 as part of the Forms category.

Assuming I didn't miss any new place that defines these requirements, I propose:

• These tests should be removed from Interop 2022. It doesn't seem in the spirit of the effort to include tests that don't match any spec or any implementation.
• These tests should be removed from WPT entirely. Doesn't seem right to have tests that aren't justified by any current CSS UI requirements in the css/css-ui/ directory, and assuming the requirements they depend on were removed intentionally, there doesn't seem to be value in keeping them around at all.

[gsnedders]

@zcorpan do you know the state here?

[zcorpan]

The relevant PRs (whatwg/html#7004 and w3c/csswg-drafts#6537) have not yet been merged. I believe the remaining concerns were basically editorial, and that was the case also when this was considered for inclusion in Interop 2022. I'll see if I can nudge the PRs this week.

[othermaciej]

Ah, I overlooked that they weren't merged yet. The current state makes it awkward to reference the spec text when making changes based on the tests, so it would be nice if they could be moved soon.

Also, the PR claims that the spec change largely matches Gecko and Chromium with a bit of cleanup, but then, it's surprising all browsers fail these tests (or at least fail the same subset), see here: https://wpt.fyi/results/css/css-ui/compute-kind-widget-generated?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&q=label%3Ainterop-2022-forms

Was this spec change intended to be an across-the-board behavior change in all browsers?

[othermaciej]

These two (which I overlooked before) do pass but only in Firefox:

https://wpt.fyi/results/css/css-ui/compute-kind-widget-fallback-props-revert-001.html?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&q=label%3Ainterop-2022-forms

https://wpt.fyi/results/css/css-ui/compute-kind-widget-no-fallback-props-001.html?label=experimental&label=master&product=chrome&product=firefox&product=safari&aligned&q=label%3Ainterop-2022-forms

Not sure if these cases are intended to remove widget styling or to not remove it; if they are supposed to maintain widget styling, how does that work, given that these are reftests, and browsers/platforms have different widget styling.

[zcorpan]

The test results look more dire than the actual situation because they are reftests and each reftest tests all widgets. So a single bug in one of the widgets will fail almost all of the tests. We could split the tests, or maybe only split out the widgets that are failing in all browsers.

Not sure if these cases are intended to remove widget styling or to not remove it; if they are supposed to maintain widget styling,

I can try to clarify what the expectation is. Meanwhile, if you look at the reference, is it not clear what the expectation is?

how does that work, given that these are reftests, and browsers/platforms have different widget styling.

Indeed, that's why reftests work well here. For most tests, the reference uses the same widgets with either no styling applied or 'appearance: none' depending on what it expects to happen in the test.

[zcorpan]

We could split the tests

#33421

[zcorpan]

With the split tests it's more evident that Chrome currently passes all of the tests in compute-kind-widget-generated except for the meter tests.

[zcorpan]

The spec changes have now been merged:

• Define which elements can be which kinds of widgets for CSS 'appearance' whatwg/html#7839
• [css-ui-4] Provide hooks for HTML to define rendering for widgets w3c/csswg-drafts#7224