Use correct properties for progress element

[dizhang168]

In Progress Element's description of how to render native appearance [1], we should use block-size: 1em instead of height: 1em and inline-size: 10em instead of width: 10em. This change will not affect existing behavior for horizontal writing mode (the specced behavior).

• At least two implementers are interested (and none opposed):
  • Chrome
  • Mozilla (assumption as Progress element vertical is already supported and related issues are resolved link)
• Tests are written and can be reviewed and commented upon at:
  • Allow Progress element to have writing mode vertical web-platform-tests/wpt#36659
    • Note: Since supporting writing-mode vertical is optional and up to UA, these are manual tests.
• Implementation bugs are filed:
  • Chromium: https://crbug.com/681917
  • Gecko: Not necessary
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=247754
  • Related issue: Clarify value direction for elements "progress" and "meter" with vertical writing mode #8413
• MDN issue is filed: N/A

(See WHATWG Working Mode: Changes for more details.)

The choice to support writing-mode is left to the UA [2]. Blink would like to enable writing-mode vertical for control forms, including the Progress element. The changes proposed in this PR will be correct for both writing mode vertical and horizontal. For more implementation details, see chromium CL [3].

[1] https://html.spec.whatwg.org/multipage/rendering.html#the-progress-element-2
[2] https://drafts.csswg.org/css-ui-4/#appearance-switching:~:text=User%20agents%20may%20disregard%20some%20CSS%20properties%20on%20widgets%20rendered
[3] https://chromium-review.googlesource.com/c/chromium/src/+/3979781

---

/rendering.html ( diff )

[domenic]

Can you restore the pull request template, including implementer interest, tests, and browser bugs?

[dizhang168]

Thanks, I wrongly assumed this was just an editorial change. Please let me know if it is missing anything.

[domenic]

I think non-manual tests should be possible here. I can think of a few ideas:

• Testing using getComputedStyle(). Some cool examples of this are HTML: Test UA style for h1..h6, hgroup, sectioning elements web-platform-tests/wpt#33917 or HTML: test for UA style: li { text-align: match-parent; } web-platform-tests/wpt#30178 , but those are specifically for the UA stylesheet, not for native appearance, so maybe it's not as applicable. You might need to write something more custom.

• Reftests. At least mismatch tests, testing that progress with vertical writing mode does not render the same as it does with horizontal writing mode.

I agree that because of the clause you linked about native appearance, these tests would be .optional.html tests. But adding them would still be good.

[dizhang168]

Thanks for your recommendations, I just changed the WPT tests in web-platform-tests/wpt#36659 to be .optional.html.
Do you think I should also add getComputedStyle() tests too?

[domenic]

Do you think I should also add getComputedStyle() tests too?

If possible, yes!

[dizhang168]

Added the new test css/css-writing-modes/progress-appearance-native-computed-style.optional.html
where the assertions are:

  const style = getComputedStyle(progress);
  assert_equals(style.blockSize, "16px");
  assert_equals(style.inlineSize, "160px");
  assert_equals(style.blockSize, style.height);
  assert_equals(style.inlineSize, style.width);

https://github.com/web-platform-tests/wpt/blob/a3fa0d0057e28acd94903a898e8d0eda2bffd253/css/css-writing-modes/progress-appearance-native-computed-style.optional.html

Edit: I merged the CL in chromium since it is experimental and the WPT tests are all optional. If more feedback, I am happy to add more patches.

[domenic]

LGTM! I will follow up internally with how to get the participation check to pass, and then we can merge.

[domenic]

All merged! Please remember to file a bug on bugs.webkit.org pointing to this PR and to the new tests, and edit the original post to include a link to it.