Related Spec: https://www.w3.org/TR/css-fonts-5/#valdef-font-size-adjust-ic-height
Related Issues: #6288, #6384

Since #6288, the ic metric split into ic-width and ic-height. And the latest draft describes them as follows.

"ic-width"
Normalize the horizontal wide pitch of the font, using the advance width of “水” (CJK water ideograph, U+6C34) divided by the font size.
"ic-height"
Normalize the vertical wide pitch of the font, using the advance height of “水” (CJK water ideograph, U+6C34) divided by the font size.

While implementing these metrics in Blink and WebKit, it was questionable whether having these two metrics for the ideogram is worth it. Here is my rationale:

1. Many fonts shape “水” in a square. Even if that is not a perfect square, the difference in height and width is small. So, I doubt if we have a practical use case that we should differentiate ic-height and ic-width for font-size-adjust.
2. Many fonts often omit vertical metrics, so we cannot get the advance height of “水” in a reliable way. The draft does not clarify a fallback behavior for the absent case. Interestingly, I found Gecko uses an average character width for the fallback [1, 2], although using ic-width instead makes more sense to me. We can consider approximating the advance height from the rendering result, but that is not preferred because different rendering systems could incur another flaky difference in layout. In any case, the spec document needs to clarify it. Otherwise, the web designer would be hard to figure out why ic-height does not work as expected.

Proposed solution:
I propose removing ic-height from the spec as its merit of keeping ic-height seems low for now.

[1] https://searchfox.org/mozilla-central/source/gfx/thebes/gfxDWriteFonts.cpp#345
[2] https://searchfox.org/mozilla-central/source/gfx/thebes/gfxFont.cpp#1058