"
ic unit
Equal to the used advance measure of the “水” (CJK water ideograph, U+6C34) glyph found in the font used to render it.

This measurement is a typically an exact measure (in the few fonts with proportional
fullwidth glyphs, an approximation) of a single fullwidth glyph’s advance measure,
thus allowing measurements based on an expected glyph count.

In the cases where it is impossible or impractical to determine the ideographic advance
measure, it must be assumed to be 1em.
"
CSS4 Values and Units, 6.1.1. Font-relative lengths section, ic unit
https://www.w3.org/TR/css-values-4/#ic

9 Tests

In horizontal-tb writing-mode:
http://w3c-test.org/css/css-values/ic-unit-001.html

With text-orientation: upright; and writing-mode: vertical-rl;
http://w3c-test.org/css/css-values/ic-unit-002.html

With text-orientation: mixed; and writing-mode: vertical-rl;
http://w3c-test.org/css/css-values/ic-unit-003.html

With text-orientation: sideways; and writing-mode: vertical-rl;
http://w3c-test.org/css/css-values/ic-unit-004.html

In horizontal-tb writing-mode:
http://w3c-test.org/css/css-values/ic-unit-008.html

With (initial) text-orientation: mixed; and writing-mode: vertical-rl;
http://w3c-test.org/css/css-values/ic-unit-009.html

With text-orientation: mixed; and writing-mode: vertical-rl;
http://w3c-test.org/css/css-values/ic-unit-010.html

With text-orientation: upright; and writing-mode: vertical-rl;
http://w3c-test.org/css/css-values/ic-unit-011.html

With text-orientation: sideways; and writing-mode: vertical-rl;
http://w3c-test.org/css/css-values/ic-unit-012.html

• Right now, no browser supports any of these 9 tests
• I searched for duplicate and did not find any.

FWIW, there was a discussion in https://github.com/w3c/csswg-drafts/issues/2798 about whether 水 was the right character to use or we should use 永 instead. We stuck with 水.

Correspondent Webkit Bug report
https://bugs.webkit.org/show_bug.cgi?id=195176

Browser support for the 9 tests:
https://wpt.fyi/results/css/css-values?label=master

Correspondent Blink Bug report
https://bugs.chromium.org/p/chromium/issues/detail?id=937101

As well as ic, there is a cap unit that corresponds to "the used cap-height of the first available font" that we can add at the same time.

Backed out for causing failures at gfxFontEntry.cpp.

Backout link: https://hg.mozilla.org/integration/autoland/rev/c8a0068de76255c66ce856879377180120465062

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=dXErzqyRR7abxwL9GDHiYw.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=145c64b7ac1705eeed1a8ac7d01b1ebd2c33ea91

Failure log:
https://treeherder.mozilla.org/logviewer?job_id=360248837&repo=autoland&lineNumber=2757
https://treeherder.mozilla.org/logviewer?job_id=360249463&repo=autoland&lineNumber=3213

Hmm, so the ic unit is a bit problematic here: to evaluate it, we need to find the "advance measure of the “水” ... glyph in the font used to render it". Which means we have to do a font-list search to find what font would be used to render it, potentially initializing all the fonts in the font-family list (so that we can check character coverage) and then -- if none of them support 水 -- moving on to fonts from prefs, and potentially to global fallback.

Besides it being potentially a bit expensive to search so many fonts, this may lead us into prefs and font-list initialization code that is main-thread-only, e.g:

https://treeherder.mozilla.org/logviewer?job_id=360248315&repo=autoland&lineNumber=2653
https://treeherder.mozilla.org/logviewer?job_id=360248344&repo=autoland&lineNumber=2609

I looked into what Safari Preview (the only implementation so far, afaik) is actually doing here, and it turns out they don't fully support what the spec calls for. If the content is styled with something like font-family: LatinFont, CJKFont, serif, where (obviously) the 水 is supported by CJKFont but not by LatinFont, they only look for 水 in LatinFont (and when it is not found, fall back to 1em), rather than moving on to CJKFont and measuring its 水 glyph.

The spec includes some hand-wavy language that allows this:

In the cases where it is impossible or impractical to determine the ideographic advance measure, it must be assumed to be 1em.

So they seem to be taking the view that if the first available font doesn't support 水, it is "impossible or impractical" to determine the true value according to "the font used to render it", and just punt.

Given this, I'm inclined to do the same in Gecko at least for the time being: implement ic as "the advance of the 水 glyph in the first available font, if present, otherwise 1em". This will give us compatibility with Safari's implementation, and avoids the complexity of executing a full font-matching/fallback search here.

Beyond that, I think we should discuss with other implementers whether there is in fact any interest in supporting a more thorough implementation of ic, or if the spec should be updated to just refer to the first available font.

Jonathan,

If you provide me with adequate, reasonable font names (in place of LatinFont and CJKFont) which exist on the MacOS X 12 (Monterey) platform, then I can and will create and submit a test accordingly.
I have searched and found
https://en.wikipedia.org/wiki/List_of_typefaces_included_with_macOS#Font_appearances
Would
font-family: "Liberation Serif", "Times New Roman", Beijing;
be adequate?

FWIW, I don't think that list is at all authoritative -- e.g. I don't see any font "Beijing" on my macOS system.

I don't know offhand if there are any fonts installed as standard where the ic unit would differ from 1em. I tested the Safari behavior by creating a couple of custom fonts with modified 水-width, so that it becomes easy to confirm whether it is in fact being used as the basis for the ic unit. My testcase can easily become a WPT test if there's agreement that the behavior is desired, but given the "opt-out" clause in the spec, it's not clear that it is rigorously testable. I think it should be brought back to the CSS WG for consideration; I'm intending to open an issue there in due course.

Ah, I see there are some (recently-added?) items in tests/css/css-values/resources that I think could be used to test this; see the IcTest{Full,Half,Zero}Width.woff2 fonts. If you put a font that doesn't support U+6C34 ahead of these in the font-family list, it should be possible to verify whether the ic unit respects the metrics of the font that would be used to render 水, although it's not the first font in the list, or falls back to 1em.

https://hg.mozilla.org/mozilla-central/rev/01f0300c5ce1

FF97 docs work for this can be tracked in https://github.com/mdn/content/issues/11592#issuecomment-1008472095 - it is fairly minimal: mostly just a release note and an update to browser compatibility data.