Bug 95743 - WebKit doesn't honor MVO and SVO properties
Summary: WebKit doesn't honor MVO and SVO properties
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Myles C. Maxfield
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2012-09-04 06:41 PDT by Johnny(Jianning) Ding
Modified: 2022-07-13 10:57 PDT (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johnny(Jianning) Ding 2012-09-04 06:41:59 PDT
In Unicode spec, the Stacked Vertical Orientation (short name SVO) property is intended to be used for vertical lines in those parts of the world where characters are mostly upright. The Mixed Vertical Orientation (short name MVO) property is intended to be used for vertical lines in East Asia, and more specifically in Japan, China and Korea. (See http://unicode.org/reports/tr50/)

In the section 5.1.1. Vertical Orientations, it says:
If the orientation value is ‘R’ then the simple value is ‘R’. If the orientation value is ‘U’, ‘T’, ‘Tu’, or ‘Tr’ then the simple value is ‘U’. The UA must render a character upright if the value is ‘U’, or sideways (90° clockwise from horizontal) if ‘R’.

However seems current webkit implementation doesn't completely honor MVO and SVO properties. For example, see the following HTML code (You can also try the attached test case)
<span style="-webkit-writing-mode:vertical-lr;">①汉②字③</span>
The default text-orientation is mixed-right, which applies MVO rule, that means all five characters (two CJK Unified Ideographs and 3 circled digits) inside <span> should be all upright. But in current webkit implementation, the 3 circled digits are showed with sideways orientation.
Comment 1 Johnny(Jianning) Ding 2012-09-04 06:43:30 PDT
Forgot to mention the section 5.1.1. Vertical Orientations is a part of CSS Writing Modes Module Level 3 Draft.(Please see http://dev.w3.org/csswg/css3-writing-modes/#text-orientation)
Comment 2 Glenn Adams 2012-09-04 18:57:48 PDT
(In reply to comment #1)
> Forgot to mention the section 5.1.1. Vertical Orientations is a part of CSS Writing Modes Module Level 3 Draft.(Please see http://dev.w3.org/csswg/css3-writing-modes/#text-orientation)

Yes, please refer to the CSS3 WM spec for any action on this bug. There has been considerable discussion of this matter in the CSS WG in recent months. See the detailed minutes from the recent F2F [1]. Also, keep in mind that UTR50 is in flux, so any early action addressing this bug will need to track the status of these discussions and make changes accordingly.

[1] http://lists.w3.org/Archives/Public/www-style/2012Aug/0899.html
Comment 3 Johnny(Jianning) Ding 2012-09-05 00:05:55 PDT
(In reply to comment #2)
> Yes, please refer to the CSS3 WM spec for any action on this bug. There has been considerable discussion of this matter in the CSS WG in recent months. See the detailed minutes from the recent F2F [1]. Also, keep in mind that UTR50 is in flux, so any early action addressing this bug will need to track the status of these discussions and make changes accordingly.
> 
> [1] http://lists.w3.org/Archives/Public/www-style/2012Aug/0899.html

Thanks for quick and detailed reply, Glenn.
Yes, I understand that it will take times to stabilize the specs (both CSS3 WM and UTR50) before having final implementation among WebKit and other layout engines.
This bug is just for a track record and I think current workaround to let circled digits show in right orientation in WebKit is to manually specify the -webkit-text-orientation for the characters we want to change.
Comment 4 Koji Ishii 2013-01-16 21:52:54 PST
SVO is now gone, and CSS WM spec uses forced-upright (all glyphs rendered upright regardless it's right to do so or not) for upright now.

For MVO, current UTR#50 proposed draft 6
http://www.unicode.org/reports/tr50/tr50-6.html
is referred from CSS WM spec. On Unicode site, there're proposed draft 7 and 8, but data do not change since 6. Unicode expects it to change in future drafts, but that will be only data change, and there are good amount of existing contents that assume proposed draft 6. Some guidelines from Japan also recommends proposed draft 6 for now.

I think it's good to go to implement proposed draft #6, and then update the table when the UTR#50 is finalized.
Comment 5 Radar WebKit Bug Importer 2022-07-13 10:57:32 PDT
<rdar://problem/96962010>