Re: [csswg-drafts] [css-values-4][css-writing-modes-4] Revisit decision to use 永 instead of 水 as the ic unit (#7577)

@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.

<hr>

I appreciate @myakura's analysis in https://github.com/w3c/csswg-drafts/issues/7577#issuecomment-1210082393 ; as @foolip notes in https://github.com/w3c/csswg-drafts/issues/7577#issuecomment-1210495600 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 probably make 水 slightly better than 永 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. See @yisibl’s [note](https://github.com/w3c/csswg-drafts/issues/7577#issuecomment-1210493671) 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... 

<hr>

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.

<hr>

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.

-- 
GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7577#issuecomment-1235944071 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 2 September 2022 22:32:07 UTC