Are the script requirements for vertically oriented text met? What about if you mix vertical text with scripts that are normally only horizontal? Do you need a switch to use different characters in vertical vs. horizontal text? Does the browser support short runs of horizontal text in vertical lines (tate-chu-yoko in Japanese) as expected? Is the orientation of characters and the directional ordering of characters supported as needed?
GitHub issue #367
Languages: zh 1
This issue is applicable to Chinese, Japanese, Korean, and Mongolian.
A common way to orient counters for lists in vertical text is to have an upright number with a dot alongside it.
The expected way to achieve this in HTML would be to use the following CSS: li::marker { text-combine-upright: all; }, however this cannot be used because browsers don't support text-combine-upright.
For more details, see this GitHub issue, which is being used to track this gap.
GitHub issue #250
Languages: zh 1
This issue is applicable to Chinese, Japanese, Korean, and Mongolian.
If you place the writing-mode property with a value of vertical-rl on an individual table cell, you would expect the text in that cell to be displayed vertically. This doesn't work as expected in all browsers: some don't apply vertical writing mode, or leave the text horizontal but rotate the CJK characters to the left.
For more details, see this GitHub issue, which is being used to track this gap. Please add any discussion there, and not to this issue.
GitHub issue #249
Languages: zh 2
This issue is applicable to Chinese, Japanese, Korean, & Mongolian.
In vertically set text, it is normal to display numbers with 2-3 digits and sometimes up 4 (and sometimes other things) horizontally within a one character space. This is particularly common for things such as day and month digits. This is often referred to using the japanese name, tate chu yoko.
In writing-modes CSS provides 2 solutions to enable tate chu yoko.-
text-combine-upright property with the all value makes everything within the element to which it is attached horizontal. It has to be applied to each location where the presentation needs to be changed.
-
digits <integer> identifies numbers with a given digit count within the element styled, and presents them horizontally. If the integer is omitted, the default is 2. This is much easier to use, because it can be applied to a paragraph or section, etc. and instances will be found automatically.
The CSS text-combine-upright property works with the all value in Gecko and Blink browsers, but not in Webkit. (Webkit supports the proprietary property -webkit-text-combine:horizontal.)No major browsers support the digits value, with or without a following digit, which is a shame since it is a better approach to the problem.
(The CSS digits value was supported by Legacy Edge with it's proprietary property name, but single digits were stretched to fit the width of the (vertical) line. The new (Blink-based) Edge no longer supports it.)
The unavailability of the digits value is an inconvenience, since more interventions and markup are needed when using the all value. Since the all value can be used with most browsers, this is classed as Advanced, but really it is probably close to Basic.
Interactive test, text-combine-upright:all will make up to 4 characters run horizontally in vertical text, and not exceed the line width.
Interactive test, text-combine-upright:digits set on a parent element will make up to 2 digits run horizontally in vertical text, without special markup, but not longer numbers
Interactive test, text-combine-upright:digits followed by a number from 2 to 4, set on a parent element, will make up to that number of digits run horizontally in vertical text, without special markup, but not longer ones
Browser bug reports: Chromium • Webkit • MozillaWebkit now supports text-combine-upright: all without a prefix. This means that Blink, WebKit, and Gecko browser engines now all support this property-value combination.Support is still lacking, however, for the more useful digits value.
GitHub issue #248
Languages: zh 3
This issue is applicable to Chinese, Japanese, Korean, and Mongolian.
By default, in runs of Latin alphanumeric text the letters are rotated 90º and run down the page. However, in some instances the alphanumerics need to stand upright. For example, this is important for acronyms.
Browsers need to allow content authors to indicate where alphanumerics should be rendered upright.
writing-modes The CSS text-orientation property has a value upright which is meant to produce this behaviour, but not all browsers support it.
Upright-oriented Latin text, especially, is used commonly for acronyms in Chinese, Japanese, Korean, & Mongolian vertical text, so this is a significant gap for general web content.
Interactive test, text-orientation:upright will make Latin characters and digits sit upright in vertical text.
WebkitAll major browser engines now support this feature!
GitHub issue #247
Languages: zh 1
This issue is applicable to languages that can be vertically set, especially Mongolian, since it has no horizontal setting. (Linked from: Chinese • Japanese • Mongolian)
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.
For more examples see the following. Note, especially, that the sideways direction differs for Mongolian.
Japanese • Chinese • Mongolian
The same vertical orientation needs to be applied to the display of buttons, progress bars, etc.
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.
Handling of vertical text in forms is a major gap.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:
- although the initial select control is vertical, the alternative options box is horizontal, and opens to the right.
- 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.
Blink • Webkit
Gecko, Blink and WebKit now all support vertical form controls. However, most tests show problems with alignment of the form controls. In addition, the surrounding text is now broken for Mongolian in both Blink and WebKit, and setting text-orientation:sideways no longer fixes it for WebKit.
