Table cells don't handle vertical direction properly

[r12a]

This issue is applicable to Japanese, Chinese, Korean, and Mongolian.

If you place the writing-mode property with a value of vertical-rl/lr on an individual table cell in a table that overall has a horizontal direction, you would expect the text in that cell to be displayed vertically, but in some browsers it isn't, unless the height of the td element is specified.

This appears to be because the text is wrapped character-by-character (cf. Mongolian, where words are wrapped rather than characters).

Tests & results:

Interactive test, Adding writing-mode:vertical-rl to a td element produces vertical text, with lines stacking RTL.
Interactive test, Adding writing-mode:vertical-lr to a td element produces vertical text, with lines stacking LTR.

This works as expected in Gecko and Blink browsers, as well as in legacy Edge and Internet Explorer. However, Webkit browsers, leave the text horizontal but rotate the Japanese characters to the left.

Interactive test, Adding writing-mode to a span inside a td produces the expected directionality

Wrapping the text to be made vertical in a span inside the cell, and applying writing-mode:vertical-rl to that gives the expected result in Blink, but in Safari it's necessary to also apply a height setting for the text to display properly.

Browser bug reports:
Blink • Webkit

Priority:
Correct behaviour here is a pretty basic expectation for handling directionality in tables, but since it only occurs when the direction of the td element is different from that of the overall table, this can probably be marked as advanced.

Updates:
June 2021: This gap was fixed for Blink.

[r12a]

The first comment in this issue contains text that will automatically appear in one or more gap-analysis documents as a subsection with the same title as this issue. Any edits made to that comment will be immediately available in the document. Proposals for changes or discussion of the content can be made in comments below this point.

Relevant gap analysis documents include:
Chinese • Japanese • Korean • Mongolian

[xfq]

There's a question from #155:

In https://www.w3.org/International/tests/repo/results/writing-mode-vertical#rl_tables , Chrome and Safari also passed the tests and they seem to work as expected. Should the gap analysis be updated?

[r12a]

I updated the initial comment to be clearer and take into account tests discussed in #155. (Select 'edited' to see the changes.)

[xfq]

Thanks @r12a!

[xfq]

• Chromium Issue: https://bugs.chromium.org/p/chromium/issues/detail?id=409155
• WebKit Bug: https://bugs.webkit.org/show_bug.cgi?id=65917

[r12a]

Thanks @xfq ! I have added this information to the top comment (so it now appears in the gap-analysis doc), and i'll do the same for all the other items for which you provided links. Thanks for your help.

[r12a]

Rewrote the gap text to:

1. apply new template, so it can be moved through the pipeline
2. indicate that Blink has now closed this gap

[r12a]

Clarified that this is only a problem if the height of the td element isn't specified and the td appears in a table with overall different direction. Changed the priority to advanced, since that's a less common combination. (If the table is vertical overall, this is not an issue.)

[r12a]

I updated the tests and the text of this issue, and applied the latest template.

[xfq]

Added a test for vertical-lr.