Issues with the intrinsic size of text-entry input elements

[jfkthame]

What is the issue with the HTML Standard?

The Rendering section of the spec:

https://html.spec.whatwg.org/multipage/rendering.html#the-input-element-as-a-text-entry-widget

refers to a converting a character width to pixels algorithm to resolve a requested size or the default of 20 to an actual pixel width:

The converting a character width to pixels algorithm returns (size-1) × avg + max, where size is the character width to convert, avg is the average character width of the primary font for the element for which the algorithm is being run, in pixels, and max is the maximum character width of that same font, also in pixels. (The element's 'letter-spacing' property does not affect the result.)

I have a couple of concerns about this:

(1) It seems odd that it ignores the letter-spacing property; as an author, if I style a text field with letter-spacing: 1ch and give it size=10, I'd expect it to be large enough to accommodate 10 characters with the given spacing.

Example: data:text/html,<input style="letter-spacing:1ch" size=10 value="1234567890">

In both Firefox and Safari, the text field does indeed have room for all 10 characters. In Chrome, only 5 are visible; this matches what the spec says, but I believe is surprising and undesirable. Was there a compelling reason for this detail of the spec, or did it simply capture the behavior of Blink without considering the fact that the other engines differ?

(In the case of Firefox, at least, the sizing of text fields has respected letter-spacing since https://bugzilla.mozilla.org/show_bug.cgi?id=252783, so this has been established behavior for two decades.)

(2) My second concern is that there does not seem to be a clear definition of what "the average character width of the primary font" means here. Does it simply refer to the xAvgCharWidthfield (https://learn.microsoft.com/en-gb/typography/opentype/spec/os2#xavgcharwidth) in OpenType fonts? If so, this should be made more explicit (though note the caveats in the OpenType spec about its potential unreliability). And what of non-OpenType fonts where such a metric may not be present at all: should there be some kind of guidance as to what "the average character width" means there?

Some testing in https://bugzilla.mozilla.org/show_bug.cgi?id=1906016 suggests that the current behavior of Firefox and Safari is fairly close to what the specification describes here (using xAvgCharWidth as the basis for computation), but Chrome's behavior is very different: with CJK fonts that have quite a large xAvgCharWidth, it ends up computing a much smaller-than-expected intrinsic width. Should this be regarded as a bug in Blink, or is it merely using a different but legitimate interpretation of "average"?

[annevk]

Can we entirely rely on a CSS concept instead of depending on OpenType directly? E.g., https://drafts.csswg.org/css-values-4/#ch?

As for blame, this was introduced in 78f593b and tweaked a few times, but it's essentially unchanged since 2009 and doesn't have a lot of context. It's probably good to have a closer look at it and add some tests.

cc @pxlcoder @nt1m @josepharhar @mfreed7 @emilio