Intent to Ship: Form Controls Support Vertical Writing Mode

[Di Zhang]

Contact emails

dizh...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-writing-modes-4/#block-flow

Summary

CSS property writing-mode should be enabled for form controls elements as it will allow lines of text to be laid out horizontally or vertically. With this feature, we are allowing the form control elements input, textarea, select, meter, progress and button to have vertical-rl or vertical-lr writing mode. This is important for interopability.

Blink component

Blink>Forms

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

If a developer set an element to have `writing-mode: vertical-lr`: Currently, will default to `writing-mode: horizontal-tb` and show the element as horizontal writing mode. With feature, will have `writing-mode: vertical-lr` and show the element as vertical writing mode.

Gecko: Shipped/Shipping

WebKit: In development

Web developers: No signals

Other signals:

Ergonomics

No, there are no other platform APIs this feature will be frequently be used in tandem with.

Activation

It should not be challenging for developers to take advantage of this feature immediately as it is simply using the CSS property on the desired form control elements.

Security

This is a form control feature and I don't expect security risks.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

There are no WebView specific changes with this feature.

Debuggability

This feature is debuggable by trying to access the form control element's writing-mode CSS value in DevTools.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name on chrome://flags

FormControlsVerticalWritingModeSupport

Finch feature name

FormControlsVerticalWritingModeSupport

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=681917

Measurement

None

Availability expectation

Feature is available on Web Platform mainline within 12 months of launch in Chrome.

Adoption expectation

Feature is considered a best practice for some use case within 12 months of reaching Web Platform baseline.

Adoption plan

We plan to release this feature in milestone 118. Firefox has already implemented this feature and Safari is working on it as it is part of Interop2023.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No

Estimated milestones

Shipping on desktop	118
DevTrial on desktop	117

Shipping on Android	118
DevTrial on Android	118

Shipping on WebView

118

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

https://github.com/whatwg/html/issues/8413

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5602118873907200

This intent message was generated by Chrome Platform Status.

[Alex Russell]

LGTM1

[Chris Harrelson]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d0714fc1-e163-4b87-825c-541d54d31ab0n%40chromium.org.

[Daniel Bratell]

This could be interesting if existing content by accident has used these properties on their form control, but if Gecko has shipped it, we should just make sure it works the same in Chromium.

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9H3atqsinHzW%2BwHCpkfrgR7oV5k6mne0YRcHA0Mq8nRQ%40mail.gmail.com.

[Di Zhang]

Hi! Thanks for the quick LGTM, sending a quick update on feature as we are preparing to ship part of it in 118.

Due to a bug for the text based form controls (crbug.com/484651), we are planning to ship this feature in two parts.

FormControlsVerticalWritingModeSupport

* select

* meter

* progress

* button

* non-text-based input types

These elements are fully implemented and put behind the flag in 118. We will do a slow rollout release using Finch.

We want to release them first because many interop2023 tests depend on these changes [1]

FormControlsVerticalWritingModeTextSupport

* textarea

* input types email, number, password, search, tel, text, url.

These elements will not be enabled in stable until crbug 484651 is fixed.

[1] https://wpt.fyi/results/css/css-writing-modes/forms?q=label%3Ainterop-2022-forms%20or%20label%3Ainterop-2023-forms&run_id=5154358192242688&run_id=5119435091738624&run_id=5117099485167616

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d0714fc1-e163-4b87-825c-541d54d31ab0n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Di Zhang]

While implementing and shipping Form Control Vertical Writing Mode support, we discovered a discrepancy between Chromium's behavior and the other two engines for vertical sliders. For elements <progress>, <meter>, <input type=range> with vertical writing-mode, the other two browsers do this:
- If direction: ltr, value is rendered top to bottom.
- If direction: rtl, value is rendered bottom to top.

This behavior is not specced since the user interface is up to the UA [1]. To achieve interoperable behavior, I have added the feature FormControlsVerticalWritingModeDirectionSupport which enables the behavior above, to match the other browsers.

This is implemented as experimental in M122. Because this might be a breaking change, we will do a slow rollout through Finch in M122 and will hopefully enable by default in stable in M123. Virtual tests are added to make sure the feature can be disabled if needed.

[1] https://github.com/whatwg/html/issues/8413