[css-values-4][css-writing-modes-4] Revisit decision to use 永 instead of 水 as the ic unit

[ziyunfei]

Chrome just implemented the ic unit this week, when I shared this news in Chinese social media, some people are confused about the chosen character 水(water), especially those people who had the handwriting practice experience, they think 永(forever; eternal) is the right choice.

See this Twitter thread: https://twitter.com/intenttoship/status/1555274307735285760

[tiye]

quote https://en.wikipedia.org/wiki/Eight_Principles_of_Yong

It was traditionally believed that the frequent practice of these principles as a beginning calligrapher could ensure beauty in one's writing.

[yisibl]

See #2798

[yisibl]

If CSSWG agrees to this change, I can amend the relevant specification and WPT.

[frivoal]

See #2798

In particular, this comment #2798 (comment) says:

Writing Modes uses 水 as well (used when scaling down the tate-chu-yoko to 1em). If switching to 永, I kinda want to see two specs refer to the same character.

[tabatkins]

And note also in #2798 that the reason we stuck with 水 rather than switching to 永 is solely because it would have been annoying to update Writing Modes, and in practice the two should be roughly identical in font coverage anyway.

But if people keep getting confused about it, it's probably worth going thru the effort of switching the character.

[ziyunfei]

Filed bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1783937
https://crbug.com/1351509
https://bugs.webkit.org/show_bug.cgi?id=243746

[VaJoy]

Using 永 is the better choice cuz it is a standard of Asian calligraphy.

I promise almost every devloper in China, Japan, Korea would be confused while using 水 as the unit of ic so please switch to 永 to avoid this disaster.

[gongpeione]

IMO using 永 as the ic unit makes more sense in Chinese and also looks more professional.

[myakura]

Although I'm not strongly against about it, I don't think it's worth the change to the specs and implementations.

#7577 (comment)

and in practice the two should be roughly identical in font coverage anyway.

Speaking of font coverage, they are not the same in web fonts. I don't know how things are going on in #3135 , but if ic requires implementations to download the font, then 永 (U+6C38) has higher chance to cause extra font download compared to 水 (U+6C34):

• In Noto Sans Japanese, 水 (U+6C34) is placed in the 5th most used characters bucket, whereas 永 (U+6C38) is in the 22nd
• In Noto Sans Traditional Chinese, 水 is in the 2nd bucket, and 永 is in the 5th
• In Noto Sans Simplified Chinese, 水 is in the 3rd bucket, and 永 is in the 6th
• In Noto Sans Hong Kong, 水 is in the 2nd bucket, and 永 is in the 5th
• In Noto Sans Korean, 水 is in the 16th bucket, and 永 is in the 39th

[Naeemo]

IMO, using 永 would be a more natural choice.
I would be confused by 水 and try to find out why, but not with 永. 永 is the first thing to practice for properly Chinese handwriting cuz its structure, it's kind of common sense here.

[yisibl]

In fact, the 永 is used in CSS Inline L3. It should also be modified to be consistent from the point of view of consistency of the specification.

The bounding box of 永 (U+6C38) can be used to find the ideographic character face edges.
https://drafts.csswg.org/css-inline-3/#baseline-synthesis-fonts

[foolip]

Is the issue here the belief that 水 was picked by accident because someone conflated it with 永?

@fantasai disconfirmed that in https://twitter.com/fantasai/status/1555385335663759360, and I wonder if the same issue would be raised if the chosen character was instead 口 or something.

I'm not a member of the CSSWG, but the fact that 永 is a kind of reference character in calligraphy doesn't by itself make it a good choice for the ic unit. The kind of analysis that @myakura did in #7577 (comment) seems like a better ground for this kind of decision.

[yisibl]

@myakura @foolip

I'm sorry, but I don't endorse the reasons related to font slicing in Google Web Fonts.

The same problem would exist in the ch unit, which should be proposed to Google Fonts to change to put the characters that are CSS units (0 or 永) further ahead.

I think #3135 about downloading fonts is a separate issue, not related to the proposal of this issue.

---

I'll reproduce Dr. Ken Lunde's(小林剣) suggestion from Twitter: https://twitter.com/ken_lunde/status/1555736774436986880

The reasons why U+6C38 永 is a near-ideal example in this context are because this ideograph 1) includes all of the basic stroke types; 2) is included in the most basic character set for each East Asian region; and 3) is rendered the same regardless of the East Asian region.

[tiye]

@bnoctis to be accurate, this character is also used by some other Asian countries although they do speak Chinese in daily life.

[azbo]

Support rewriting to "永"

[cxh194311]

Support rewriting to "永"

[woeoio]

The word "永", more in line with Chinese culture then "水"

[vicdf]

As a chinese, I think 永 is way more representative compare to 水 due to its structure, etc. so I hope it is the best to change that.

[dufemeng]

I agree with the above statement, support rewriting to "永"

[aaron-ai]

"永" is better.

[wlbksy]

When used in calligraphy, "水" does not make any sense. "永" is the right choice for it represent the basic skills of calligraphy, "Eight Principles of Yong" https://en.wikipedia.org/wiki/Eight_Principles_of_Yong.
Almost every calligrapher knows this as beginner.
It is the essential sound of "mama/papa" to babies who are learning how to speak.

[hingbong]

I think "永" is better, too.

[linrf]

I think "永" is better.

[Rvtea]

"永" is better.

[volcanicll]

Support rewriting to "永"

[ziyunfei]

Guys, please stop posting similar comments unless you have more informed thoughts. you can click the 👍🏻 button to vote on it.

[DreamOneX]

As a Chinese who has studied calligraphy, I know Eight Principles of Yong has extraordinary meaning. It is the basic skill of calligraphy. I believe every developer from China, Japan and Korea will support using 永 instead of 水.
If you know Chinese, even if you haven't learned calligraphy, You can also find that the character 永 contains all eight Chinese strokes. So it can make more sense.
What's more, as @bnoctis said, after all we are Chinese speakers, our culture should be respected and we should also decide how to render our characters.
All in all, I support rewriting to 永.
thanks.

[bobwxc]

In most cases, 永 is the first example character of traditional ShuFa Art. And it also be the simplest example character of much fonts. Like 'n' in many Latin fonts.
It is a good traditional custom.

[sunhaitao]

but if every typeface follows the aforementioned principle

I'm afraid this cannot be assumed for the following reasons:

1. In the history of computing, it is rare that many vendors all follow a specification strictly. People (and maybe all beings with general intelligence) just made mistakes here and there.

2. Although translated as 'Eight Principles of Yong' on Wikipedia, '永字八法' is actually 8 mostly-used stroke-drawing techniques demonstrated with the 'forever' glyph. And it is mostly for the regular script (楷体). More ancient scripts such as the Clerical script (隶书) have their own rules. Of course, many (if not most) typefaces used today are based on the regular script for readability. But artistic fonts are different stories.

'永' is the good old choice to show strokes. But representing measurements is a new problem, picking another character is also okay. Since '水' is neither found dysfunctional nor associated with something unjust or distasteful, we are not in a hurry to abandon the current work. Let's resolve this cautiously.

[faceless2]

Please remember we are exclusively discussing the OpenType glyph advance here, not any other aspect of font metrics, not calligraphy or aesthetics. Specifically the values for these glyphs from the OpenType hmtx and vmtx tables.

In practice the advance will be the same for both glyphs, in both the horizontal and vertical directions.

[CoelacanthusHex]

In practice the advance will be the same for both glyphs, in both the horizontal and vertical directions.

Since they are the same in practice, why not choose the one that respects the tradition of the language more.

[sunhaitao]

@bnoctis
According to my understanding of the Chinese culture, 'where the heroes are from' does not matter' (英雄不问出处). Anyone with enough domain knowledge is eligible for making design decisions. In this particular problem, a typography expert studying Chinese as a foreign language may have more domain knowledge. Cultures have ambiguous parts that only native users of associated languages can handle well. But measuring a glyph is not that hard.

On the other hand, foreign users are also stakeholders in layouting characters. People do publish materials in their foreign languages (this page is an example). And mixing native and foreign characters in the same sentence is a valid use case (this page is also an example). Problems in such practices (some are hard to imagine for native users) also need to be addressed.

By the way, as far as I know, '水' is picked by @fantasai while working on writing modes, not a random Googler.

[sunhaitao]

@faceless2
You are right. Given that 'ch' only needs to be an approximation, any CJK characters in a font should be representative enough. There may be fonts that do not give each CJK character exactly the same measurement, but it is safe to assume that their sizes do not vary too much.

In that case, maybe we could just use the measurement of the first CJK character in the current font to avoid any confusion or download.

Using the measurement of ideographic space (全角空格, U+0300) is also a good choice. East Asians use it to arrange characters for quite a while.

Of course, just keep using the current work is also fine. It works, and it is real.

[jtyjty99999]

I prefer '永' instead of '水'. Eight_Principles_of_Yong is the rule of Chinese Calligraphy.
Therefore, rendering with this text will more comprehensively conform to the rendering of Chinese characters.

[tiansh]

Speaking of font coverage, they are not the same in web fonts. I don't know how things are going on in #3135 , but if ic requires implementations to download the font, then 永 (U+6C38) has higher chance to cause extra font download compared to 水 (U+6C34):

Web fonts for special using (brand name for example) won't include either one regardless what is chosen. As 永 is a common used character, any web fonts for general using could easily include it if they want. And whenever the specification switched into 永 and people get use of it, web fonts creators would/could/should change their fonts by including 永 in the most common "bucket". So that wont be a trouble here, IMO.

[chrishtr]

I discussed this issue with @xiaochengh, @kojiishi, @wangxianzhu and one other expert. We concluded that there should be no significant compat or interop risk with changing the spec text to use 永 instead of 水, since in basically all CJK fonts the characters have exactly the same width and height.

Given that, and since 永 makes much more sense to Chinese speakers (including those I consulted), I recommend changing the spec to use that character.

Note: In the Chromium implementation, we plan to still use 水 for the moment, because of issues like those mentioned in this comment. But again, that is just an implementation detail and will have no difference in the dimensions observed by web developers, and should not be how it's described in the spec or developer documentation. (I just mention it because otherwise there might be a performance concern with the change. We could change the implementation easily in the future if font buckets change.)

[fantasai]

@chrishtr I would rather not have the spec and the implementations randomly diverge, so we should only change the spec if implementations are also committed to change. This would not be a difficult change in the implementations, actually: most of the work is in updating the W3C Recommendation and writing proper tests for it, which @yisibl has volunteered to do. (Note that the tests need to be subtle enough to account properly for non-square CJK fonts and for proportional fonts, which some designers are starting to experiment with.) Updating a W3C Recommendation involves a lot of tracking across time as various requirements (testing, review, implementation) are fulfilled, so if @yisibl is willing to follow through on all stages of the spec update, that will help a lot.

But again, the entire point of having specs is to define implementations, and in fact the W3C Recommendation process requires demonstration of conforming implementations, so unless we're willing to update the implementations we cannot update the specs either.

---

I appreciate @myakura's analysis in #7577 (comment) ; as @foolip notes in #7577 (comment) the choice of 水 over 永 was intentional due to the frequency of usage, some practical effects of which we are seeing in the way font files are broken down.

There's also some subtle effects in the way characters are drawn and measured for optical alignment that mean 水 and 永 will yield different results in cases where we might need to measure the actual glyph ink area as a fallback for the ICFT baseline for fonts that don't have one specified. We should investigate this, and consider which is better. See @yisibl’s note about CSS Inline Layout L3.

@gongpeione wrt “using 永 as the ic unit makes more sense in Chinese and also looks more professional”: You will never actually see this character, except in the specifications. And unless you have a font where each character is drawn in a different size, you will not know which character is used in the implementations. We only measuring its width and height to find the size of a typical CJK character.

@sunhaitao Appreciate your comments thinking through the issues with each character. The reason we're not using U+3000 IDEOGRAPHIC SPACE is because in some proportional fonts, it does not match the full width of a Han character. Most CJK fonts are not proportional, and so measuring any character is the same; but some few are not, and we need to accommodate them properly. This is why we can't use just any character.

@CoelacanthusHex They are the same in practice in most cases, but we have to gracefully handle proportional fonts and degenerate situations such as incomplete font metrics...

---

I've rephrased the definition of the ic unit in the specs to emphasize the conceptual definition over the implementation method, it now reads:

ic unit
Represents the typical advance measure of CJK letters, and measured as the used advance measure of the “水” (CJK water ideograph, U+6C34) glyph found in the font used to render it.

It was never the intention that the definition of which CJK character we measure would be in user-facing documentation, as the main idea is that we are providing a measure that approximates the measure of a typical CJK character. In most fonts, this should be equal to the measure of any CJK character.

---

Anyone commenting on this issue: there are etiquette guidelines to commenting in bug reporting systems, the first and foremost of which is, don't spam the system with duplicate reports or comments. In order for groups to work effectively in public, bug reporting systems need to efficiently collect and represent relevant information. If you want to +1 this issue, add a thumbs-up to the existing comment. It is only worth commenting if you have additional relevant information or analysis to add, or if you have a question that is not already answered here.

(Also, don't insult people. This is also against etiquette.)

I want to emphasize that our goal in making decisions here is to make things work as well as we can, in as many cases as we can. Each decision we make is for some functional reason. We should correct mistakes, but keep in mind: we don't want the specs to be beautiful, we want the web pages that browsers render when following them to be beautiful.

[css-meeting-bot]

The CSS Working Group just discussed Revisit ic character.

The full IRC log of that discussion

<TabAtkins> Topic: Revisit ic character
<TabAtkins> github: https://github.com//issues/7577
<TabAtkins> astearns: So issue is whether the change the current "water" character used as the ic reference to the "eternal" character.
<TabAtkins> astearns: I propose we make this change, don't see a reason not to.
<TabAtkins> heycam: It generated a surprising amount of confusion.
<TabAtkins> heycam: Just because it looks so similar to the typical one used for calligraphy
<TabAtkins> [looking for Myles]
<TabAtkins> [reviewing elika's comments in the thread]
<TabAtkins> astearns: My take on her input is that it would be fine either way; we did have reasons for that particular character, but there aren't reasons not ot use the other one
<TabAtkins> TabAtkins: One reason in the thread is that the water character is prioritized higher in CJK split fonts, so it's more likely to have been loaded already, versus the eternal character
<TabAtkins> astearns: It was noted that this isn't necessarily problematic, fonts can change
<TabAtkins> TabAtkins: Sure, they could put any char there. But it's not there now.
<TabAtkins> heycam: I think we should change; I think it's unlikely we'll encounter situations where fonts have different glyph coverage that is an actual problem.
<TabAtkins> heycam: And without the change we'll likely get a slow trickle of people asking why we're using that character.
<TabAtkins> [fills in myles on context]
<TabAtkins> myles: I think approximately zero people will notice either way
<TabAtkins> astearns: A decent number of people seem to have noticed our current value and would welcome the change.
<TabAtkins> astearns: And the only technical argument against the change is the bit about it being more quickly loaded in many situations.
<TabAtkins> astearns: But it's been argued convincingly to me that it's an artifact of current font subsetting.
<TabAtkins> astearns: And something that could change.
<TabAtkins> [fills in fantasai]
<TabAtkins> fantasai: Depends.
<TabAtkins> fantasai: First, do people actually want to implement this?
<TabAtkins> fantasai: I heard someone say they want to change the spec but won't change their implementation; that's not going to fly.
<TabAtkins> astearns: Is it testable?
<TabAtkins> fantasai: yes
<TabAtkins> myles: you make a font with different characters
<TabAtkins> astearns: is it testable with current existing fonts?
<TabAtkins> heycam: in a subsetting situation and you forget a later one that has the eternal in it, but seems unlikely
<TabAtkins> myles: I think it's fine to change and see if problems arise
<TabAtkins> fantasai: Second reason is there is the ideographic character face top line and bottom line, which are two metrics we need for alignment of CJK characters
<TabAtkins> fantasai: If those metrics aren't in the font, we might ahve to measure them.
<TabAtkins> fantasai: So if you have to measure, is it better to measure water, eternal, or does it not matter?
<TabAtkins> fantasai: It will matter, since they have different heights
<TabAtkins> fantasai: WHich is better? We should ask Ken Lunde or someone at Adobe
<TabAtkins> fantasai: bc that's a practical implementation
<TabAtkins> fantasai: It would be great symbolically if we use eternal, but if it objectively gives us worse results we shoudln't use it
<TabAtkins> myles: what were the metrics?
<TabAtkins> fantasai: ICFT line
<TabAtkins> fantasai: [describes the ICFT]
<TabAtkins> fantasai: The characters are drawn in teh box, slightly inside the em square
<TabAtkins> astearns: For this issue, the character we use for ic extent doesn't necessarily specify what the UA would use for this purpose
<TabAtkins> fantasai: Right but if we used a different character for each usage, that's not amazing
<TabAtkins> astearns: My point is there might be an even differnt character better for that, as it's more close to the edges
<TabAtkins> astearns: So is one or other of these chars more or less likely to hit what the browser will use for this approx?
<TabAtkins> fantasai: I looked at a bunch to look at this, and a lot you'd think would be good are actually *smaller* than water
<TabAtkins> fantasai: Like the one that's just a box, due to optics it's actually smaller than the ink extent of water and eternal
<TabAtkins> fantasai: So I tried to find a char that used as much space as possible, and was reasonably frequent, that's how I got water
<drott> q+
<TabAtkins> fantasai: Dont' ahve a problem with eternal, just want ocnfirmation this won't give us worse results for othe rpurpose
<astearns> ack drott
<TabAtkins> drott: In trying to figure out this change, it seems like one of the concerns is people coming across the spec and taking issue with the char.
<TabAtkins> drott: So maybe being less specific and just saying "a representative character"
<TabAtkins> fantasai: We want interop, and dont' want people to pick a bad char without giving thought
<TabAtkins> fantasai: Same as for ch unit, we didn't say a representative char, we said 0
<TabAtkins> myles: Unsure how interop measuring ink is in reality because browsers can use diff points
<TabAtkins> myles: Also in OT, some points can have semantic meaning beyond just glyph bounds, which browsers would want to use
<TabAtkins> fantasai: Yeah point is just you don't want the CJK “one” character, for example, bc it's a horizontal line. And want every browser to use the same char.
<TabAtkins> fantasai: It's definitely not very much difference. But I want somebody who knows how they're typically drawn to confirm it won't be a regression.
<heycam> q+
<TabAtkins> myles: So 2 options are character that's representative of ic and the other metrics we're interested in, or use separate characters for each.
<TabAtkins> astearns: We're not speccing the char for the box dimensions if the info's not available in the font.
<TabAtkins> fantasai: We're using representative CJK char for ic unit, for text-combine-upright, and for ideographic-ink baselines.
<TabAtkins> fantasai: Better to use one char for all of these, rather than diff for each.
<TabAtkins> astearns: But right now we only specify ic, right?
<TabAtkins> fantasai: No, WM uses a char to specify width of tatechuyoko
<TabAtkins> myles: interested in knowing what browsers follow those specs right now
<TabAtkins> fantasai: If we want to change it bc people are mad, we can do that and I won't object, but I think it would be good to actually find out if this would be practically better or worse.
<TabAtkins> myles: This topic isn't urgent, so I don't think we need to push to resolve it right now if we want extra info.
<TabAtkins> astearns: I'll action myself to talk to Adobe fonts people about metrics, particularly when they're not in the font.
<TabAtkins> astearns: One clarifiction, fantasai asked explicitly about willing to implement
<drott> q+
<TabAtkins> astearns: myles you said we should try it and see?
<TabAtkins> myles: If the spec changes we're willing to try
<heycam> q-
<TabAtkins> astearns: So no change to the spec today, I'll see what info I can get, perhaps someone with Google Fonts connections?
<TabAtkins> drott: Yeah, we have some perf concerns of bracketing of CJK fonts.
<TabAtkins> drott: We haven't done a lot of investigation about this yet, so we'll have to look at this more closely.
<TabAtkins> drott: But we do currently expect water to be in the first bucket.
<TabAtkins> drott: And can see if Google Fonts is willing to make a change to keep eternal in the first bucket
<astearns> ack drott
<drott> s/bracketing/bucketing/

[LIXiangChen]

I'm not sure if it's too late, but I believe it's more reasonable to use U+3000 than "水" or "永".

I've read the comments above about why U+3000 is not used, but it's not convincing enough. Here are my thoughts after actually using the ic in live commercial projects.

1. Representative of the width

The comment above said: in proportional-width fonts, U+3000 does not match the width of Han characters. It is true, but please don't overlook that in proportional-width fonts, "水" or "永" also cannot match (or represent) the width of all Han characters.

The special status of "永" is that it contains the eight most basic stroke types of Han characters. This is for calligraphy and type design, but its metric width is not representative. Regardless of "水" or "永", their strokes are too few, in proportional-width fonts they are almost certainly narrower than characters with more complex strokes.

Let's look at U+3000. In ideographic equal-width fonts, it has the same width as Han characters; in proportional-width fonts, it has the most suitable width specified by the creator, which represents the creator's will (I know that in some older fonts, the width of U+3000 may not have been carefully set, but this is improving). It is conceivable that if there is an attribute called Typical ideographic metric width inside the font, its value will definitely same as the width of U+3000 — this is exactly the same as the purpose of the ic.

Also, the number of proportional-width CJK fonts is increasing, which is important.

2. Applicability

"水" or "永" only exists in fonts containing Han characters, that is Simplified Chinese, Traditional Chinese, and Japanese. The fonts containing U+3000 are wider, such as, the modern Korean font commonly does not contain Han characters, but contains U+3000. In this way, the scope of application of the ic will cover more scripts.

3. Font subsetting

ic is used for fonts containing Han characters, such fonts are large in size, so for non-local fonts, it is often pre-cut the font into slices, or download only the required characters' data, and dynamically build.

In such cases, to make ic work correctly, have to specifically load the reference character it needs. If it is U+3000, since it is a blank glyph, this is very easy to implement and is unlikely to cause unexpected consequences. But if it is "水" or "永", firstly, downloading their data will take extra traffic; secondly, if they are added to each slice, when used in combination, it may cause some weird conflicts; finally, for some special fonts that use special character sets, they may not contain "水" or "永", so if we add a blank "水" or "永" to the font, this may cause serious consequences (but for U+3000, we can do like this).