Comments (19)
Is
writing-mode
a strict superset ofdirection
? I.e is everydirection.rtl
awritingMode.rtl
anddirection.ltr
awritingMode.ltr
? And thenwritingMode.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
from proposal-intl-locale-info.
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/
from proposal-intl-locale-info.
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?
from proposal-intl-locale-info.
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.
from proposal-intl-locale-info.
@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
from proposal-intl-locale-info.
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/
from proposal-intl-locale-info.
We probably should look at https://www.w3.org/TR/css-writing-modes-3/#vertical-modes about this.
from proposal-intl-locale-info.
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
from proposal-intl-locale-info.
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
from proposal-intl-locale-info.
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
.
from proposal-intl-locale-info.
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.
from proposal-intl-locale-info.
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 .
from proposal-intl-locale-info.
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?
from proposal-intl-locale-info.
Why not call it dir
to align with the HTML/CSS dir
?
from proposal-intl-locale-info.
That might work. I still think that the HTML/CSS dir
naming was a mistake as well, but consistency does feel good here.
from proposal-intl-locale-info.
Is writing-mode
a strict superset of direction
? I.e is every direction.rtl
a writingMode.rtl
and direction.ltr
a writingMode.ltr
?
And then writingMode.ttb|btt
have no equivalents?
from proposal-intl-locale-info.
The tricky thing is that technically languages can have multiple writing-mode
s, 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.
from proposal-intl-locale-info.
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
from proposal-intl-locale-info.
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.
from proposal-intl-locale-info.
Related Issues (20)
- Missing standard preamble for abstract operations HOT 1
- Change CharacterDirectionOfLocale and WeekInfoOfLocale to receive an Intl.Locale object? HOT 1
- CreateArrayFromListOrRestricted can be simplified HOT 1
- Canonicalise time zones in TimeZonesOfLocale
- Define behaviour when no time zone is used within a region HOT 5
- [[Weekend]] ordering HOT 2
- CharacterDirectionOfLocale doesn't handle top-to-bottom and bottom-to-top scripts HOT 1
- CharacterDirectionOfLocale doesn't take script and region subtags into account HOT 1
- Intl.Locale.prototype.textInfo is missing "lineOrder" information HOT 1
- "direction" property in Intl.Locale.prototype.textInfo is possibly ambiguous HOT 2
- The textInfo getter seems unwell HOT 5
- Reverse date creation HOT 1
- Add support for -u-fw and other Unicode extensions that could impact the result HOT 13
- `.getTimezones()` seems problematic HOT 3
- Consistent "region" subtag requirements for getTimeZones() and getWeekInfo()/getHourCycles() HOT 8
- Tc39 HOT 1
- Possible of addition of Intl.Locale.prototype.getCurrencies()? HOT 1
- Define fallback behaviour in {Calendars,Collations,HourCycles,NumberingSystems,CharacterDirection,WeekInfo}OfLocale HOT 6
- Locale with -u-fw- value other than 13 value will cause assertion HOT 15
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proposal-intl-locale-info.