[forms] vertical writing-mode tests seem suspicious.

[emilio]

Test List

These tests:

• https://wpt.fyi/results/css/css-writing-modes/forms/range-input-appearance-none-vertical-rtl.optional.html
• https://wpt.fyi/results/css/css-writing-modes/forms/range-input-appearance-native-vertical-rtl.optional.html

Rationale

Seem backwards? I'd expect a vertical range (like Firefox does), but Firefox is the only engine failing the test?

cc @nt1m who created these tests.

[jfkthame]

It looks like the reason Firefox is failing these is that direction: rtl is not having any effect on the vertical range control, which it probably should.

On the other hand, Safari and Chrome both render a horizontal control, which seems even more wrong, but the test doesn't detect this as a failure.... :-(

[nt1m]

It looks like the reason Firefox is failing these is that direction: rtl is not having any effect on the vertical range control, which it probably should.

This is precisely what this is testing.

Seem backwards? I'd expect a vertical range (like Firefox does), but Firefox is the only engine failing the test?

I think Chrome was failing this test too with their vertical form controls enabled (maybe it's no longer the case?). WebKit passes with the vertical form controls enabled.

On the other hand, Safari and Chrome both render a horizontal control, which seems even more wrong, but the test doesn't detect this as a failure.... :-(

Yeah I agree that should be detected as a failure, happy to take suggestions on how to fix the test. Potentially a new mismatch? or something that turns red? not sure what's the most simple path here.

[jfkthame]

Presumably we could at least assert a mismatch against a testcase that doesn't have vertical writing-mode, but is otherwise the same.

[nt1m]

I'll take a look next week, but I'm happy to review PRs if one comes first.

Also side note about vertical form controls, most of the tests were me and @dizhang168's work so we'd appreciate if Gecko has any new tests to contribute to the tests from their own implementation experience of vertical form controls :)

[jfkthame]

So this raises the question in my mind: which direction should an inline-oriented range control progress by default in vertical writing mode? (Without RTL getting involved.)

In Gecko, for a vertical range control in horizontal writing mode, it progresses from bottom to top (like the mercury going up a thermometer).

Currently, in vertical writing mode (e.g. Japanese with writing-mode: vertical-rl) we use the same rendering, which means the range will progress "upstream" against the inline flow of the text. I think that seemed reasonable, given that (AFAIK) the Japanese don't normally hold their thermometers with the bulb at the top and the mercury expanding downwards.

But if that's so, then what about RTL directionality in vertical writing modes, e.g. an Arabic or Hebrew section within a vertical Japanese page? If we now reverse the direction of the range, it'll be progressing downwards, against the inline direction of the RTL text; and that doesn't feel very natural to me.

So my gut feeling is that in vertical writing mode, the vertical range should always progress upwards, regardless of the inline direction. But that's not what these tests are asserting.

WDYT? (Does any spec discuss this?) Should we actually reverse the "default" for vertical writing modes, so that an inline-oriented range control within vertical Japanese would progress downwards? What does webkit do? (I don't seem to have support for this in the version of Safari Tech Preview that I have here.)

[nt1m]

There's whatwg/html#8413 opened to discuss this.

I personally think we should just follow the inline flow direction (and this is what WebKit does, you can enable "Vertical form controls" from experimental feature flags to test), since there doesn't seem to be any agreement on what's the best experience for each language.

[dizhang168]

The reason it is passing in chrome right now is because it is defaulting to the horizontal behavior. To make these tests fail consistently when not correctly implemented, maybe whenever we are testing range-input-appearance-*-vertical-*.optional.html, we add the line <link rel="mismatch" href="range-input-appearance-*-horizontal*.optional.html">. And vice versa.

On a side note, some of these writing mode tests made it to Interop 2023 and I wonder if we should change them to be not optional anymore.

[nt1m]

I submitted a PR to fix this: web-platform-tests/wpt#39004