You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-text-4] Make ideograph-alpha and ideograph-numeric part of text-spacing: normal #6950
The baseline behaviour of text-spacing should always turn on ideograph-alpha and ideograph-numeric when in the horizontal writing direction. In the vertical direction, it should be turned on when the western text is rotated1 and turned off if the western text is not2.
Microsoft Word has ideograph-alpha/ideograph-numeric turned on by default. The iOS UI also has this spacing, but I'm not sure if it's done on the rendering level, or spaces are injected during string interpolation.
On other platforms, it is not supported out of the box. Authors end up adding spaces themselves inconsistently, leading to horrible UIs like this:
CSS should support this turned on as the default.
There may also need to be an additional property for authors to specify the width of the inserted space they want. The default 1/4 space is fine.
I believe you're right about what's good, but given that it is not the historical behavior and that plenty of content was written assuming it wouldn't happen, this is likely not to be compatible.
We could maybe write an informative note giving a suggestion of an algorithm for the UA-dependent auto value, which could do what you suggest, including the dependencies on writing-modes, but I suspect we cannot make that behavior the default. If you'd like to insist on it, it would take some evidence that this is web compatible.
I tried imagining scenarios where changing to more desirable defaults would make it incompatible with existing content, but I cannot come up with much.
Content which already has extra space characters injected wouldn't be affected, because ideograph-alpha and ideograph-numeric do not insert additional spaces between characters and spaces.
One case which may potentially be affected would be designs that emulate a terminal with mixed western/CJK text.
Since there's no guarantee that the browser font selected for CJK will be an integer multiple of the monospace font selected for western text, any site which wants pixel-perfect alignment will likely already be breaking characters into blocks with hard-coded widths and/or CSS grid. Ideograph-alpha and ideograph-numeric should not interact across blocks, so there would not be any impact if implemented that way.
About the behavior being turned off depending on the writing mode, I think I have approached it wrongly. It's more about the behavior of ideograph-alpha and ideograph-numeric itself, i.e. when turned on, spaces are only injected between characters in the same inline direction.
I tried imagining scenarios where changing to more desirable defaults would make it incompatible with existing content, but I cannot come up with much.
Content that used to fit within a element of a certain given size is now longer due to these inserted spaces, no longer fits, and now breaks into two lines.
If a paragraph of text goes from 7 to 8 lines, it's usually fine, but if a UI element like a button or a menu entry goes from 1 line to 2, there's not always room to fit that, and it can easily overflow.
Note the current specified value trim-adjacent and allow-end for normal also causes content to no longer align on character grid boundaries.
Quad space is not much, has been universally used in commercial printing (sometimes more than quad, so the western text takes up a whole number of CJK characters), and is still better for alignment than a full space.
Also it's quite unlikely for UI to have mixed script CJK & Western; it is usually considered bad style. The vast majority of script mixing would be in titles, slogans and prose.
English reader here who has a bare acquaintance with Chinese text. As a webmaster, I would prefer that the default behavior, not inserting automatic spaces on language switch between CJK and Western, not be changed and that any new behaviors, such as automatically inserting spaces, need to be explicitly stated through a non-default property. This would prevent breaking legacy content.
I checked with two colleagues who have professional experience in Chinese-language media and here are their responses on the proposal:
Jay Lu:
“When I worked for the Chinese media, our style book called for no-space. I would recommend no-space because 1) our local press (Sing Tao and World Journal) follows no-space guide; 2) it looks better.”
Jessie Liang:
“As for newspapers and online articles, it's better to have no spaces before and after the English words, which look better. However, as for the subtitle on TV, you may or may not use a space because when you read a subtitle with a limited time, having a space before and after the English words would be easier to catch each word.”
If autospacing is made the default, it's possible that some web text somewhere might grow a little, although it's not clear to me how many cases like that exist, and it may be a small number.
On the other hand, if spacing is preferred and the behaviour has to be applied manually to all Chinese and Japanese text in the future, that's a pain in the neck (for all web pages going forward, forever). Especially in cases such as where text is converted automatically from markdown, or where strings from a database or field-based input from users are integrated into a document that doesn't have styling for Chinese, and so on.
I raised a separate issue for the following comments. See #7183
But i also find myself wondering about a couple of other aspects of this.
[1] @CharlesBelov makes a case for no autospacing in some types of text. Of course, one possibility would be to have a value that turns default autospacing off, except that we don't appear to have one, and that leads to another thought. It suggests that it would also not be possible to have, say, autospacing set for the document as a whole (by default or by a style declaration), and then turn it off for some parts of the content.
[2] Another feature that might be useful is the ability to say, "If spaces have been used in an existing text between Han and ASCII alphanumeric text, rather than adding an even larger gap if autospacing is turned on (1/4 em plus the existing space character), replace the existing space with a 1/4em gap." That would make it easier to have consistent spacing when mixing text from different sources on the same page (especially including user input via forms, where they may add spaces). That would also allow content authors to apply autospacing without being concerned that existing text would wrap onto 2 lines, as @frivoal fears.
Which makes me wonder whether it's right to treat autospacing as just a value of text-spacing, or whether it's better to have an autospacing property with values such as on|off|override-space|<width>. (I seem to vaguely remember that this is more like what was implemented in Internet Explorer in times past.)
By the way, i think that separating out the autospacing we're talking about here – moving Han and alphanumeric inline runs apart – from the punctuation-related text spacing feels intuitively better, too. When writing this stuff up so that others could learn about it, i found myself doing that anyway (see https://r12a.github.io/scripts/jpan/#letterspace).
These "spaces" need special handling not normally found in Western typography, in that they compress more readily than Western spaces would in a tight justification scenario, and they would do so before any adjustments would be applied to U+0020 characters' widths. So, this is a new concept and has complexity. The Japanese case is more so, in that spacing around full-width punctuation is added to the prioritized list of spacing to be adjusted. These adjustment considerations need to be accounted for in the feature or it may not work well.
I'm not sure I've been understood. That Microsoft Word does autospacing when mixing CJK and Western text does not make it correct (or wrong, for that matter). My concern is that you appear to be proposing to implement something that changes default behavior whether a site wants it or not, resulting in breaking existing content, based on your perception that adding spacing looks better. I have had two professionals who come from journalism tell me that removing spacing looks better, with adding spaces being reserved for special use cases.
Again, I am not an expert in Chinese, so take my random search judiciously, but in visits to four Chinese newspaper websites, all four sites had examples of mixed content where it appears there is intentionally no spaces between CJK and Western text. No endorsement of the content is intended; these are merely examples of Chinese content with strings of Western text.
I acknowledge I did see in my searching discussions on this issue asserting that web designers like to add spacing in these cases. So I am fully in support of adding the automated capability. I am only concerned with the idea of making it the default behavior to the point where it breaks existing content or changes existing behavior to enforce a behavior that appears to not have agreement between designers and journalists.
I want to urge that when the CSS Working Group discusses the outcome of this issue, that they respect legacy content. If I misunderstood that you intend added spacing to be the default behavior, my apologies.
Edits committed. Florian and I went with specifying 1/8ic as the spacing, since we wanted to stay on the conservative side if we're inserting spaces by default. Please file follow-up issues about anything that needs further adjustment.
Also, there's a follow-up issue about replacing spaces with auto-spacing at #8263
normal -- Specifies the baseline behavior, equivalent to space-start trim-end trim-adjacent ideograph-alpha ideograph-numeric.
I am a little confused about the "baseline behavior.
Before ideograph-alpha and ideograph-numeric were added to normal definition, the meaning was clear to me, that is, the each value included in the definition of normal is the default value, so when we specify the text-spacing property partially changed from normal we can specify just changed values and omit values that are included in the normal definition.
For example, when just text-spacing: trim-start is specified, it implies omitted normal values, trim-end and trim-adjacent. i.e., text-spacing: trim-start was equivalent to text-spacing: trim-start trim-end trim-adjacent.
However, after ideograph-alpha and ideograph-numeric were added to normal definition, it is no longer that simple. Is text-spacing: trim-start equivalent to text-spacing: trim-start trim-end trim-adjacent ideograph-alpha ideograph-numeric? That will be useful when we want to change only trim-start/space-start/space-first behavior and keep other normal behavior, but if so, how do we change just ideograph-alpha/ideograph-numeric behavior from normal?
Then I decided to interpret it as follows:
text-spacing: trim-start is still equivalent to text-spacing: trim-start trim-end trim-adjacent. The omitted default *-start/first, *-end, and *-adjacent are kept but ideograph-alpha and ideograph-numeric are turned off.
ideograph-alpha and ideograph-numeric are turned on only when these values are explicitly specified, or normal (or auto, probably) is specified.
However this spec is not very clear and not very useful.
It would be better adding a new keyword, no-interscript-space, to turn off the interscript spacing.
The ideograph-alpha || ideograph-numeric part of the value definition becomes [no-interscript-space | ideograph-alpha || ideograph-numeric] and we can specify only this part to the text-spacing property when keeping other default (normal) behavior.
Or maybe it would be better to change the ideograph-alpha || ideograph-numeric value to ideograph-alpha <number> || ideograph-numeric <number> where the <number> represents the space width as a multiple of the fullwidth advance measure. The normal definition would contain ideograph-alpha 0.125 ideograph-numeric 0.125. Examples:
text-spacing: ideograph-alpha 0 ideograph-numeric 0 turns off the ideograph-alpha/ideograph-numeric spacing and keeps other normal behavior.
text-spacing: trim-start only changes the *-start/first part of normal behavior. i.e, is equivalent to text-spacing: trim-start trim-end trim-adjacent ideograph-alpha 0.125 ideograph-numeric 0.125.
Activity
frivoal commentedon Jan 31, 2022
There's a double question here:
I believe you're right about what's good, but given that it is not the historical behavior and that plenty of content was written assuming it wouldn't happen, this is likely not to be compatible.
We could maybe write an informative note giving a suggestion of an algorithm for the UA-dependent
autovalue, which could do what you suggest, including the dependencies on writing-modes, but I suspect we cannot make that behavior the default. If you'd like to insist on it, it would take some evidence that this is web compatible.hfhchan commentedon Jan 31, 2022
I tried imagining scenarios where changing to more desirable defaults would make it incompatible with existing content, but I cannot come up with much.
Content which already has extra space characters injected wouldn't be affected, because ideograph-alpha and ideograph-numeric do not insert additional spaces between characters and spaces.
One case which may potentially be affected would be designs that emulate a terminal with mixed western/CJK text.
Since there's no guarantee that the browser font selected for CJK will be an integer multiple of the monospace font selected for western text, any site which wants pixel-perfect alignment will likely already be breaking characters into blocks with hard-coded widths and/or CSS grid. Ideograph-alpha and ideograph-numeric should not interact across blocks, so there would not be any impact if implemented that way.
About the behavior being turned off depending on the writing mode, I think I have approached it wrongly. It's more about the behavior of ideograph-alpha and ideograph-numeric itself, i.e. when turned on, spaces are only injected between characters in the same inline direction.
frivoal commentedon Jan 31, 2022
Content that used to fit within a element of a certain given size is now longer due to these inserted spaces, no longer fits, and now breaks into two lines.
If a paragraph of text goes from 7 to 8 lines, it's usually fine, but if a UI element like a button or a menu entry goes from 1 line to 2, there's not always room to fit that, and it can easily overflow.
hfhchan commentedon Jan 31, 2022
Note the current specified value trim-adjacent and allow-end for normal also causes content to no longer align on character grid boundaries.
Quad space is not much, has been universally used in commercial printing (sometimes more than quad, so the western text takes up a whole number of CJK characters), and is still better for alignment than a full space.
Also it's quite unlikely for UI to have mixed script CJK & Western; it is usually considered bad style. The vast majority of script mixing would be in titles, slogans and prose.
hfhchan commentedon Mar 5, 2022
Would there be an update to this issue?
CharlesBelov commentedon Mar 25, 2022
English reader here who has a bare acquaintance with Chinese text. As a webmaster, I would prefer that the default behavior, not inserting automatic spaces on language switch between CJK and Western, not be changed and that any new behaviors, such as automatically inserting spaces, need to be explicitly stated through a non-default property. This would prevent breaking legacy content.
I checked with two colleagues who have professional experience in Chinese-language media and here are their responses on the proposal:
Jay Lu:
Jessie Liang:
r12a commentedon Mar 28, 2022
It's not an easy call, one way or the other.
If autospacing is made the default, it's possible that some web text somewhere might grow a little, although it's not clear to me how many cases like that exist, and it may be a small number.
On the other hand, if spacing is preferred and the behaviour has to be applied manually to all Chinese and Japanese text in the future, that's a pain in the neck (for all web pages going forward, forever). Especially in cases such as where text is converted automatically from markdown, or where strings from a database or field-based input from users are integrated into a document that doesn't have styling for Chinese, and so on.
I raised a separate issue for the following comments. See #7183
But i also find myself wondering about a couple of other aspects of this.[1] @CharlesBelov makes a case for no autospacing in some types of text. Of course, one possibility would be to have a value that turns default autospacing off, except that we don't appear to have one, and that leads to another thought. It suggests that it would also not be possible to have, say, autospacing set for the document as a whole (by default or by a style declaration), and then turn it off for some parts of the content.
[2] Another feature that might be useful is the ability to say, "If spaces have been used in an existing text between Han and ASCII alphanumeric text, rather than adding an even larger gap if autospacing is turned on (1/4 em plus the existing space character), replace the existing space with a 1/4em gap." That would make it easier to have consistent spacing when mixing text from different sources on the same page (especially including user input via forms, where they may add spaces). That would also allow content authors to apply autospacing without being concerned that existing text would wrap onto 2 lines, as @frivoal fears.
Which makes me wonder whether it's right to treat autospacing as just a value oftext-spacing, or whether it's better to have anautospacingproperty with values such ason|off|override-space|<width>. (I seem to vaguely remember that this is more like what was implemented in Internet Explorer in times past.)r12a commentedon Mar 28, 2022
See #7183
By the way, i think that separating out the autospacing we're talking about here – moving Han and alphanumeric inline runs apart – from the punctuation-related text spacing feels intuitively better, too. When writing this stuff up so that others could learn about it, i found myself doing that anyway (see https://r12a.github.io/scripts/jpan/#letterspace).macnmm commentedon Mar 28, 2022
These "spaces" need special handling not normally found in Western typography, in that they compress more readily than Western spaces would in a tight justification scenario, and they would do so before any adjustments would be applied to U+0020 characters' widths. So, this is a new concept and has complexity. The Japanese case is more so, in that spacing around full-width punctuation is added to the prioritized list of spacing to be adjusted. These adjustment considerations need to be accounted for in the feature or it may not work well.
r12a commentedon Mar 29, 2022
I think those features would be accounted for in the justification algorithm, no?
CharlesBelov commentedon Mar 30, 2022
I'm not sure I've been understood. That Microsoft Word does autospacing when mixing CJK and Western text does not make it correct (or wrong, for that matter). My concern is that you appear to be proposing to implement something that changes default behavior whether a site wants it or not, resulting in breaking existing content, based on your perception that adding spacing looks better. I have had two professionals who come from journalism tell me that removing spacing looks better, with adding spaces being reserved for special use cases.
Again, I am not an expert in Chinese, so take my random search judiciously, but in visits to four Chinese newspaper websites, all four sites had examples of mixed content where it appears there is intentionally no spaces between CJK and Western text. No endorsement of the content is intended; these are merely examples of Chinese content with strings of Western text.
https://std.stheadline.com/daily/article/2452186/%E6%97%A5%E5%A0%B1-%E6%B8%AF%E8%81%9E-%E5%85%A7%E5%9C%B0%E8%88%87%E6%B8%AF%E7%A7%8B%E5%AD%A3%E5%89%8D%E6%81%90%E9%9B%A3%E9%80%9A%E9%97%9C (Sing Tao Daily)
https://language.chinadaily.com.cn/a/202203/29/WS6242d221a310fd2b29e53fc5.html (China Daily)
https://www.zaobao.com.sg/lifestyle/columns/story20220328-1256766 (Zaobao Singapore)
https://www.chinatimes.com/realtimenews/20220330001102-260403 (China Times, Taiwan)
I acknowledge I did see in my searching discussions on this issue asserting that web designers like to add spacing in these cases. So I am fully in support of adding the automated capability. I am only concerned with the idea of making it the default behavior to the point where it breaks existing content or changes existing behavior to enforce a behavior that appears to not have agreement between designers and journalists.
I want to urge that when the CSS Working Group discusses the outcome of this issue, that they respect legacy content. If I misunderstood that you intend added spacing to be the default behavior, my apologies.
26 remaining items
[css-text-4] Use 1/8ic spacing for ideograph-alpha/ideograph-numeric w…
[css-text-4] Add ideograph-alpha and ideograph-numeric to normal (def…
[css-text-4] Do not apply ideograph-alpha/ideograph-numeric spacing t…
[css-text-4] Use 1/8ic spacing for ideograph-alpha/ideograph-numeric #…
fantasai commentedon Dec 30, 2022
Edits committed. Florian and I went with specifying 1/8ic as the spacing, since we wanted to stay on the conservative side if we're inserting spaces by default. Please file follow-up issues about anything that needs further adjustment.
Also, there's a follow-up issue about replacing spaces with auto-spacing at #8263
MurakamiShinyu commentedon Jan 7, 2023
The
text-spacing: normaldefinition is now:normal-- Specifies the baseline behavior, equivalent tospace-start trim-end trim-adjacent ideograph-alpha ideograph-numeric.I am a little confused about the "baseline behavior.
Before ideograph-alpha and ideograph-numeric were added to
normaldefinition, the meaning was clear to me, that is, the each value included in the definition ofnormalis the default value, so when we specify the text-spacing property partially changed fromnormalwe can specify just changed values and omit values that are included in thenormaldefinition.For example, when just
text-spacing: trim-startis specified, it implies omitted normal values, trim-end and trim-adjacent. i.e.,text-spacing: trim-startwas equivalent totext-spacing: trim-start trim-end trim-adjacent.However, after ideograph-alpha and ideograph-numeric were added to
normaldefinition, it is no longer that simple. Istext-spacing: trim-startequivalent totext-spacing: trim-start trim-end trim-adjacent ideograph-alpha ideograph-numeric? That will be useful when we want to change only trim-start/space-start/space-first behavior and keep othernormalbehavior, but if so, how do we change just ideograph-alpha/ideograph-numeric behavior fromnormal?Then I decided to interpret it as follows:
text-spacing: trim-startis still equivalent totext-spacing: trim-start trim-end trim-adjacent. The omitted default *-start/first, *-end, and *-adjacent are kept but ideograph-alpha and ideograph-numeric are turned off.normal(orauto, probably) is specified.(I implemented it in Vivliostyle.js as per this interpretation. vivliostyle/vivliostyle.js#1080)
However this spec is not very clear and not very useful.
It would be better adding a new keyword,
no-interscript-space, to turn off the interscript spacing.The
ideograph-alpha || ideograph-numericpart of the value definition becomes[no-interscript-space | ideograph-alpha || ideograph-numeric]and we can specify only this part to the text-spacing property when keeping other default (normal) behavior.MurakamiShinyu commentedon Jan 8, 2023
Or maybe it would be better to change the
ideograph-alpha || ideograph-numericvalue toideograph-alpha <number> || ideograph-numeric <number>where the<number>represents the space width as a multiple of the fullwidth advance measure. Thenormaldefinition would containideograph-alpha 0.125 ideograph-numeric 0.125. Examples:text-spacing: ideograph-alpha 0 ideograph-numeric 0turns off the ideograph-alpha/ideograph-numeric spacing and keeps othernormalbehavior.text-spacing: trim-startonly changes the *-start/first part ofnormalbehavior. i.e, is equivalent totext-spacing: trim-start trim-end trim-adjacent ideograph-alpha 0.125 ideograph-numeric 0.125.frivoal commentedon Jan 9, 2023
@MurakamiShinyu I raised your two comments above a a separate issue #8288, as I think it will be more easily tracked this way.
[css-text-4] Add ideograph-alpha and ideograph-numeric to normal (def…
[css-text-4] Do not apply ideograph-alpha/ideograph-numeric spacing t…
[css-text-4] Use 1/8ic spacing for ideograph-alpha/ideograph-numeric w…
[css-text-4] Redesign text-spacing