NEW65917
Applying writing-mode:vertical-rl to td does not make the table cell vertical 
https://bugs.webkit.org/show_bug.cgi?id=65917
Summary Applying writing-mode:vertical-rl to td does not make the table cell vertical
Koji Ishii
Reported 2011-08-09 06:44:24 PDT
Created attachment 103355 [details] Table cell with writing-mode:vertical-rl applied Applying writing-mode:vertical-rl to td does not seem to be working. I have attached a sample HTML file that reproduce the issue with the Nightly build. I then tried to put <p> inside td and applied writing-mode:vertical-rl, which made the text vertical but its position isn't correct. Both rows renders as I expect in IE9. I tried this on Safari and Nightly build on Lion, and also on Safari and Chrome on Windows. All resulted the same. This is my first try to put a bug in webkit, so please excuse me if I made something incorrect, and I apologize in advance for any troubles I may have caused. I tried to look for dup bugs, 46997 may be related but I couldn't figure out if this is dup of the bug or not.
Attachments
Table cell with writing-mode:vertical-rl applied (495 bytes, text/html)
2011-08-09 06:44 PDT, Koji Ishii 		no flags
Details
writing-mode:vertical-rl test on td and th tags. (1.20 KB, text/html)
2012-01-07 20:47 PST, rasamassen 		no flags
Details
testcase with variations and visual reference (390 bytes, text/html)
2025-06-04 13:13 PDT, fantasai 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
rasamassen
Comment 1 2011-12-29 06:50:04 PST
<td> with writing-mode:vertical-rl fails in Windows on Chrome 16 as well. <td> with writing-mode (old IE lingo) works in IE9, but renders the <td> with the wrong height (if the <tr> is taller than the writing-mode cell needs, it shortens the cell - easily revealed by putting a border on cells and making a tall <td>); please make sure the <td> maintains the same row height as other cells when writing mode is changed.
rasamassen
Comment 2 2012-01-07 20:47:10 PST
Created attachment 121566 [details] writing-mode:vertical-rl test on td and th tags.
rasamassen
Comment 3 2012-01-07 20:58:00 PST
writing-mode should work on <th> and <td> elements, per http://www.w3.org/TR/css3-writing-modes/#writing-mode and http://dev.w3.org/csswg/css3-writing-modes/#writing-mode (working draft and editors draft), which excludes table row groups, table column groups, table rows, and table columns, but not table header cells or table data cells.
rasamassen
Comment 4 2012-12-12 12:53:24 PST
Blocks 46123
Christian Biesinger
Comment 5 2013-03-26 10:45:37 PDT
*** Bug 113325 has been marked as a duplicate of this bug. ***
Christian Biesinger
Comment 6 2013-03-26 14:14:12 PDT
Note, IE supports this. http://jsbin.com/ayeyag/4
Gérard Talbot (no longer involved)
Comment 8 2017-10-28 19:15:04 PDT
2 additional tests (testing a table with realistical tabular data; both border-collapse models tested): http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s73-orthogonal-vrl-table-cells-004.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s73-orthogonal-vrl-table-cells-006.xht The tester must have "Liberation Sans" font or Arial font installed on his/her system. Note that Firefox fails to render 'text-align: left' correctly for cells in orthogonal flow.
Theresa O'Connor
Comment 9 2021-08-04 09:38:55 PDT
This is being tracked at W3C in a JLREQ issue: https://github.com/w3c/jlreq/issues/171 Note that this has been fixed in Blink recently (June 2021).
Radar WebKit Bug Importer
Comment 10 2021-08-04 09:39:14 PDT
<rdar://problem/81518948>
Gérard Talbot (no longer involved)
Comment 11 2021-08-04 12:27:07 PDT
More tests: http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s73-orthogonal-table-cell-003.xht http://test.csswg.org/harness/test/css-writing-modes-3_dev/single/orthogonal-parent-shrink-to-fit-001/ is 24 sub-tests on shrink-to-fit inline-blocks, floats, table-cells, block boxes with an orthogonal child.
Kent Tamura
Comment 12 2022-07-20 01:18:41 PDT
*** Bug 201096 has been marked as a duplicate of this bug. ***
Kent Tamura
Comment 13 2022-07-20 01:18:51 PDT
*** Bug 240418 has been marked as a duplicate of this bug. ***
Myles C. Maxfield
Comment 14 2023-07-19 09:12:33 PDT
This is important for klreq. See https://w3c.github.io/klreq/gap-analysis/#issue52_vertical_text
Ahmad Saleem
Comment 15 2023-12-29 22:35:01 PST
@Alan - Will this be fixed by? https://github.com/WebKit/WebKit/commit/0d695812f5b0daef531a9760903457364d2265ff
alan
Comment 16 2023-12-30 06:07:38 PST
(In reply to Ahmad Saleem from comment #15) > @Alan - Will this be fixed by? > > https://github.com/WebKit/WebKit/commit/ > 0d695812f5b0daef531a9760903457364d2265ff Sadly no. this looks like a mess now. Will look into it.
fantasai
Comment 17 2025-06-04 13:13:30 PDT
Created attachment 475483 [details] testcase with variations and visual reference
ayagawap
Comment 18 2025-11-30 21:53:52 PST
I can confirm that this issue is still reproducible in the latest version of Safari. Chrome renders the layout correctly according to the specification, so this is clearly an Interop issue.
Note You need to log in before you can comment on or make changes to this bug.