Skip to content

Poor level of support for vertical form controls #247

@xfq

Description

@xfq

This issue is applicable to languages that can be vertically set, especially Mongolian, since it has no horizontal setting. (Linked from: ChineseJapaneseMongolian)

In vertically set text, form controls should also be oriented vertically, in order to fit into the flow of the content. The following examples show what you'd expect to see for various types of form in vertically set Chinese.

vertical form controls

For more examples see the following. Note, especially, that the sideways direction differs for Mongolian.

JapaneseChineseMongolian

The same vertical orientation needs to be applied to the display of buttons, progress bars, etc.

The GAP

Unfortunately, this is not supported by all browsers, creating difficulties for use of forms in vertical text (especially traditional Mongolian, where reverting to horizontal is not an option).

css-writing-modes Creates an expectation that forms should be rendered vertically, but doesn't specify details for rendering.

Priority

Handling of vertical text in forms is a major gap.

Tests & results

CJK tests:

Interactive test, When vertically-set CJK text contains a textarea element, the control will also be vertical. A preceding label will appear above the top right corner of the textarea box.

Interactive test, When vertically-set CJK text contains a text input element, the control will be vertical. A preceding label will appear above the box.

Interactive test, When vertically-set CJK text contains a select element, the control will be vertical, and multiple options will extend, vertically-set, towards the left.

Blink, Gecko, and WebKit mostly passes all the above tests except for two small problems:

  1. although the initial select control is vertical, the alternative options box is horizontal, and opens to the right.
  2. the label associated with a textarea control appears above the top left corner of the box, rather than top right.

i18n test suite, Forms: vertical-rl and Forms: vertical-lr

Same results as for the previous tests.

Mongolian tests:

Interactive test, When vertically-set Mongolian text contains a textarea element, the control will also be vertical. A preceding label will appear above the top right corner of the textarea box.

Interactive test, When vertically-set Mongolian text contains a text input element, the control will be vertical. A preceding label will appear above the box.

Interactive test, When vertically-set Mongolian text contains a select element, the control will be vertical, and multiple options will extend, vertically-set, towards the left.

The results of these tests are the same as for the CJK tests, except that the label appears to the correct side of a textarea control (because of the change in text direction).

Button tests:

Interactive test, When vertically-set CJK text contains an HTML button element, the control will also be vertical.

Interactive test, When vertically-set Mongolian text contains an HTML button element, the control will also be vertical.

Blink, Gecko, and WebKit pass the test.

Action taken

BlinkWebkit

Outcomes

Gecko, Blink and WebKit now all support vertical form controls. However, most tests show problems with alignment of the form controls.

Select element controls look suited to the vertical text flow in their default presentation, but when selecting an option the options are displayed horizontally. This is, of course, particularly problematic for Mongolian.

Metadata

Metadata

Assignees

No one assigned

    Labels

    doc:clreqUsed for gap analysis (only) to indicate target document.gapThe first comment in this issue is read by the gap-analysis document.i:interactionForms & user interactioni:writing_modeWriting model:zhChinesep:basics:haniChinese scripts:jpanJapanese scripts:koreKorean scripts:mongMongolian scriptx:blinkBlink needs to fix this.x:clreqThis affects the clreq group of languages.x:jpanThis affects the jlreq group of languages.x:klreqThis affects the klreq group of languages.x:mlreqThis affects the mlreq group of languages.x:webkitWebKit needs to fix this.

    Type

    No type

    Projects

    Status

    Browser bug raised

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions