Clarify value direction for elements "progress" and "meter" with vertical writing mode

[dizhang168]

Currently, elements "progress" and "meter" don't have well defined behavior when they have the style writing-mode: vertical-lr or writing-mode: vertical-rl. For example, Firefox is the only vendor to support vertical writing-mode for these elements. Here is what a progress bar looks like:

<progress value="70" min="0" max="100" style="writing-mode: vertical-lr"> 70% </progress>

Question 1: Should the value part (blue color) of the element be rendered from top down (as reading is normally done from top to bottom) or should it be rendered bottom to top (so it looks like a glassware that gets filled up)?

Further, currently for the horizontal mode, we are able to change the direction of the progress bar from left-to-right to right-to-left.

<progress value="70" min="0" max="100" style="direction: rtl"> 70% </progress>
<progress value="70" min="0" max="100" style="direction: ltr"> 70% </progress>

However, there are no direction for ttb top-to-bottom or btt bottom-to-top (not that I am aware of at least).
Question 2:
Should there be a way to allow changing direction for the vertical writing modes?

Spec link:
https://html.spec.whatwg.org/#the-progress-element
https://html.spec.whatwg.org/#the-meter-element
https://drafts.csswg.org/css-writing-modes-4/#block-flow
https://drafts.csswg.org/css-writing-modes/#direction

(ps: was told that this question is better fit for whatwg/html instead of csswg w3c/csswg-drafts#7929)

[andreubotella]

The direction CSS property isn't meant to change the direction of a progress bar, but to change the direction of the inline progression of text, meant to be used for languages that are written right-to-left such as Hebrew and Arabic. Changing the direction of the progress bar is a side effect, that I don't think is a good practice. And in cases such as writing sideways RTL languages in vertical text, the direction property can still be used (where "left" maps to top and "right" to bottom).

That said, HTML should indeed probably specify the native (and primitive) appearance of <progress> and <meter> in terms of block-size and inline-size, rather than height and width.

[r12a]

The direction CSS property isn't meant to change the direction of a progress bar, but to change the direction of the inline progression of text, meant to be used for languages that are written right-to-left such as Hebrew and Arabic. Changing the direction of the progress bar is a side effect, that I don't think is a good practice.

I'm curious to know why you think this is not good practice (especially given that Blink, Gecko, and WebKit browsers all currently apply the RTL directionality for the progress bar). Do you have information from RTL script users indicating a preference for it to be otherwise?

(Btw, we shouldn't be referring to the CSS direction property for the examples above – RTL/LTR direction in HTML should be controlled using the dir attribute rather than CSS.)

[andreubotella]

I'm curious to know why you think this is not good practice (especially given that Blink, Gecko, and WebKit browsers all currently apply the RTL directionality for the progress bar). Do you have information from RTL script users indicating a preference for it to be otherwise?

It looked like the OP was about changing the direction of progress/meter bars in absence of any internationalization need for it, just as a styling change. That's what I was objecting to. If that's not what was meant, my bad.

[r12a]

It looked like the OP was about changing the direction of progress/meter bars in absence of any internationalization need for it, just as a styling change. That's what I was objecting to. If that's not what was meant, my bad.

Yes, for the scenario you describe the use of the direction property doesn't seem semantically correct, though if there really is a use case for changing the reading directions independently of the surrounding text, then perhaps that would point to the need for some other CSS property(?)

The case for the vertical text is interesting. The links above point to questions i have asked of the experts in our various language fora. The query for the arabic script folks has a short thread already. I also put out feelers about the vertical text expectations to Chinese, Japanese, and Mongolian folks.

[nt1m]

I think the progress & meter should fill up in the inline flow direction for consistency with horizontal mode and how webpage flow works generally, so:

• writing-mode: vertical-* & direction: ltr: Top to bottom
• writing-mode: vertical-* & direction: rtl: Bottom to Top
• writing-mode: sideways-* & direction: ltr: Bottom to Top
• writing-mode: sideways-* & direction: rtl: Top to Bottom

[nt1m]

Same question applies to input[type=range] fwiw.

[r12a]

We have been getting feedback from the expert communities, as follows.

There appears to be consensus that horizontally inline controls should grow in the reading direction – ie. left to right for english, right to left for arabic, hebrew, etc. w3c/hlreq#32 w3c/alreq#259

For vertical text we have an interesting situation:
Japanese folks prefer the control to grow from bottom to top. w3c/jlreq#342
Chinese folks prefer it to grow from top to bottom. w3c/clreq#500

[nt1m]

Since the Japanese folks ideally want the direction to be controllable by CSS, it probably makes sense to follow the inline direction, even if it makes the default less ideal? This way someone can just use direction: rtl on the form control itself to flip it.

I think a default direction of bottom to top isn't really ideal for vertical WM, even if flippable with direction: rtl, given it makes the behavior counterintuitive when you compare with the text around it.

[dizhang168]

An update on the blink implementation (will ship soon): We are following what is suggested above by nt1m.
For <meter>, <progress>, <input type=range>, if direction: ltr, value is rendered top to bottom. If direction: rtl, value is rendered bottom to top.

[yisibl]

The top-to-bottom on the input range in Firefox when using writing-mode: vertical-lr I think is a bug rather than an intentional feature.

This is because Firefox also supports orient="vertical", which, when added, goes from bottom to top, which is the opposite of writing-mode: vertical-lr.

<input type="range" value="80" orient="vertical">
<input type="range" value="80" orient="vertical" style="writing-mode: vertical-lr">
<progress value="70" min="0" max="100" style="writing-mode: vertical-lr"> 70% </progress>

@emilio Can you provide more information?

[emilio]

orient=vertical "wins" somewhat intentionally afaict: https://bugzilla.mozilla.org/show_bug.cgi?id=1157142

@jfkthame can probably provide more context.

[dholbert]

ntim's proposal makes intuitive sense to me as an implementor, but I worry that it's a bit ergonomically awkward for authors... The proposal seems to force authors to use two different pieces of horizontal left/right terminology in order to get a vertical (bottom-to-top) meter/progress-bar.

In particular, to get a vertical progress bar that fills from bottom-to-top (like a volume indicator, say):
(1) Authors would have to make a choice between vertical-rl vs. vertical-lr. (It's unclear to an author what the significance of choosing "team lr" vs "team rl" is, but they must pick one team or the other.)
(2) Authors have to specify direction: rtl in order for the bar to grow from bottom-to-top.

Both of these feel pretty weird because nothing about the control has a left/right relevancy.

(With my implementor hat on, this all makes sense in terms of logical axes, just as ntim said. But I'm not sure authors have that same mental model or are going to intuitively understand the reasoning here.)

Having said that, I'm not objecting; just wanted to be sure this author-facing rough edge has been considered.

[nt1m]

There's w3c/csswg-drafts#9832 that might make things more intuitive for authors, but I think until that's resolved, making the form controls follow the text flow makes sense to me.