textInfo.direction is a very simplified model of reality

[Manishearth]

filing at the request of @sffc cc @iwsfutcmd

In the current model (proposed in https://github.com/tc39/ecma402/issues/205), textInfo.direction determines ltr vs rtl, likely for the HTML dir tag. Overall; writing system directionality is a far more complicated concept; many writing systems have multiple directionalities, and many are vertical inline.

For example, Chinese can either be written as a horizontal-tb LTR script (like Latin), or a vertical-rl script. Occasionally, one may see vertical-lr in some embedding cases, and shop signs sometimes use horizontal-tb RTL, though we can probably consider these to be stylizations (similar to vertical neon signs in Latin). Either way, there are multiple writing directions on roughly equal footing.

CSS took a lot of time to get out of the rut of privileging horizontal scripts, and I'm worried that direction being a simple property from the start will come and bite us in the future where vertical scripts don't get handled properly.

For the purposes of figuring out HTML dir info perhaps we should have .defaultHorizontalDirection or something more explicit, and/or have direction return something more detailed.

Thoughts?

[iwsfutcmd]

Agreed, with one small correction: Chinese (and Japanese, and Korean but uncommonly) can be written in vertical-rl.

rtl-horizontal-tb is accepted, but marked. The two places where one might find it would be in shop signs or other primarily non-running-text display environments, and in the very niche usage of text on the right-hand-sides of vehicles, where characters are typically laid out starting at the front of the vehicle and go towards the end.

I'm not sure if vertical-lr is accepted; I've never seen it, and I'd bet most readers would interpret a text laid out in vertical-lr as if it was vertical-rl and quickly become very confused (much like how an English reader would be similarly confused by text set horizontal-bt). W3C's jlreq and clreq make no mention of it.

[FrankYFTang]

To throw our more fun, read the following I collected over the year of modern bidirectional usage of Han script https://docs.google.com/document/d/15t-uhbsFl3aaXPlA8j0XeSF1hdm0hKKbC8eJDw4Oyvs/

[Manishearth]

@iwsfutcmd ah I mixed up lr and rl. vertical-lr Chinese shows up super rarely as a layout trick iirc, and is not really worth considering but I felt the need to mention it for completeness

[FrankYFTang]

We know the complexity of directionality, if you consider writing system of ancient Egyption Hieroglyphic and Native American, there are circile direction and rtl in odd line and ltr in even line kind of direction. The question is how practicle for us to put that into ECMA402 standard in 2021.

About vertical writing, there are many example of such and we are aware of it. The current proposal does not support the expression of them and if you have a good suggestion how to improve it for a reasonable use case we can improve it later.

Example of website support vertical writing (Mongol version of Chinese Communist Party daily news website - vertical left to right http://mongol.people.com.cn/

[sffc]

I think we need to focus on the use case for this property.

My impression is that the primary motivation for this feature was determining whether a site should use a left-aligned or right-aligned layout. In this case, would the coarse textInfo.direction be sufficient?

[FrankYFTang]

We probably should look at https://www.w3.org/TR/css-writing-modes-3/#vertical-modes about this.

[FrankYFTang]

one possibility soluton to addressing the need for vertical writing is in additional to textInfo.direction add yet another property textInfo.writingModes to return a list of values in <"horizontal-tb", "vertical-rl", "vertical-lr">

• For Chinese, Japanese and Korean return ["horizontal-tb", "vertical-rl"] to indicate they could be written in horizontal line top to bottom, or verically line from right to left (ex links from https://www.quora.com/Are-there-any-Chinese-or-Japanese-websites-that-use-vertical-text) and by default horizontal line top to bottom
• For "mn", "mn-MN", or"mn-Cyrl" (Mongolian, Mongolian used in Mongolia, or Mongolian written in Cyrlillic script) return ["horizontal-tb"] to indicate only be written as horizontal line top to bottom (Example web page https://mig.mn/ )
• For "mn-Mong" (Mongolian writtein Mongolian script), "mn-CN" (Mongolian used in China) or "mnc" (Manchu language) return ["vertical-lr"] to indicate only be written as verically line from left to right ( Example webpage http://mongol.people.com.cn/15962133.html )
• For all other locales return ["horizontal-tb"] to indicate only be written as horizontal line top to bottom

[FrankYFTang]

I would suggest we leave the textInfo.writingModes out of the Intl Locale Info API since it is already in Stage 3 and I don't think it is a good idea to add additional property to it to enlarge the scope. I am willing to propose a new proposal after it go into Stage 4 to add the writingModes to make it easier to be used with CSS https://www.w3.org/TR/css-writing-modes-3/#vertical-modes

[zbraniecki]

I agree we should leave it out, but i'd like to have a conhesive vision between writing mode, orientation and direction.

In particular, I'd like to make sure we're not going to add direction and immediatelly obsolete it with orientation.

[FrankYFTang]

as long as CSS keep direction around, there are no need to obsolete it, right? I would perfer we keep the API align with the terms / model used in CSS.

[FrankYFTang]

In a sense textinfo.direction is AS SIMPLE AS as direction in CSS and anything CSS solved by writing-mode should NOT be solved by textInfo.direction but rather something else (say adding a new textInfo.writingMode in v2 to align with CSS writing-mode) It does not solve the vertical writing issue just like direction in CSS won't solve the vertical writing issue, and something else we could later could solve what CSS solve with writing-mode .

[Manishearth]

This makes sense, I'm then a bit worried about calling this direction, perhaps it should have a more specific name to avoid overuse in cases where it's not about the css direction?

[sffc]

Why not call it dir to align with the HTML/CSS dir ?

[Manishearth]

That might work. I still think that the HTML/CSS dir naming was a mistake as well, but consistency does feel good here.

[zbraniecki]

Is writing-mode a strict superset of direction? I.e is everydirection.rtl a writingMode.rtl and direction.ltr a writingMode.ltr? And then writingMode.ttb|btt have no equivalents?

[Manishearth]

The tricky thing is that technically languages can have multiple writing-modes, and writing-mode can also be horizontal or vertical, so yes, it's a superset, in the way that direction = rtl can mean horizontal-rl and there is no equivalent for vertical-tb, and also some writing systems have multiple.

[FrankYFTang]

Is writing-mode a strict superset of direction? I.e is everydirection.rtl a writingMode.rtl and direction.ltr a writingMode.ltr? And then writingMode.ttb|btt have no equivalents?

Please read my comment carefully, there will be NO writingMode.rtl, writingMode.rtl, writingMode.ttb nor writingMode.btt That is now howt he writing-mode in CSS specified.

https://www.w3.org/TR/css-writing-modes-3/#block-flow

There are only 3 values of writing mode

Value: | horizontal-tb | vertical-rl | vertical-lr

horizontal-tb Top-to-bottom block flow direction. Both the writing mode and the typographic mode are horizontal. vertical-rl Right-to-left block flow direction. Both the writing mode and the typographic mode are vertical. vertical-lr Left-to-right block flow direction. Both the writing mode and the typographic mode are vertical.

These work WITH dir, not superset dir

[sffc]

2021-11-04 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2021-11-04.md#textinfodirection-is-a-very-simplified-model-of-reality

[FrankYFTang]

I am going to close this issue since textInfo support the information for horizontal line to work with CSS for horizontal and does not preclude future support of vertical line w/ CSS which support that.