CSS3 ch unit inconsistent between IE9+ and other browsers

Question

IE9+ claims to support the ch CSS unit. By the definition, this unit is 'Equal to the advance measure of the "0" (ZERO, U+0030) glyph' of the current font, or, in simpler words, the width of the character box for the glyph for “0”. This interpretation seems to be right for Firefox 10+ and Chrome 27+: <div style="width: 10ch;"></div> and <div>0000000000</div> have exactly the same width given they have the same font of the same size. But in IE9+ the ch unit seems to mean something slightly different.

Here is the fiddle demonstrating this issue: http://jsfiddle.net/CNsPg/6/

What is the logic of the behavior of IE with this unit? Or is it just a bug? Is it possible to make IE treat ch unit like other browsers (probably with some IE-specific text rendering "magic")?

Riddick

Answer 1

According to caniuse.com, IE interprets 1ch as the width of the 0 glyph, without the surrounding space. This makes 1ch shorter in IE compared to any other browser.

Sacrilege

Answer 2

You have to create a IE-specific CSS that overrides all rules including ch units and multiply them by 1.162 for a monospace font.

This value may change with another font so you may have to calculate the ratio by measuring the actual width in pixels for 100x0 and a div with width: 100ch.

Normal browser (default) :

input[type="text"][size="10"] { width: 10ch }

IE11 :

input[type="text"][size="10"] { width: 11.62ch }

Nicolasanicolau

I suppose this constant should be font-specific? – Riddick

Yes. This is for monospace font. I tried with Arial, Comic Sans and the ratio is not the same. – Nicolasanicolau

Answer 3

Looking at the fiddle, it's an interesting case of differing interpretations of the spec.

The spec itself is somewhat .... uh.... brief; I can see room for both interpretations.

The spec says:

ch unit
Equal to the advance measure of the "0" (ZERO, U+0030) glyph found in the font used to render it.

So 'ch' is the width of an "0". The question that isn't answered in the spec is whether that should include the spacing around the character:

• Should it be consistent with the 'em' unit (which is the width of the 'm', including font spacing)?

• Or should it be consistent with 'ex', which is the height of the 'x' character (without any spacing considerations; ie just the actual glyph)?

I think I know which one I'd pick if I was writing a browser, but as I say I can see an argument for both cases given the lack of clarity in the spec.

I guess in the face of that kind of ambiguity, and with two clearly different implementations between browsers, the only sensible option is not to use the 'ch' unit at all until there is better consensus.

Thankfully 'em' and 'ex' are available and consistent, and also provide font-relative sizing. I guess under the circumstances, the best advice I can give is to stick with them.

The only way I can think of to work around it would be to have a custom font with a default of zero letter spacing. My thought process is that this should remove the ambiguity between the interpretations, but would mess up other aspects of your font rendering somewhat. I guess you could then set the letter spacing manually, but you'd still probably have other issues. Not a solution I'd reall suggest trying, to be honest.

Milling

CSS does not define 'em' as "the width of the 'm', including font spacing". That's the traditional typesetting definition. CSS defines 'em' as the computed value of font-size, etc. – Centner

In my opinion, "advance measure" (advance width) is a well-defined metric of the font, as well as x-height. Advance width seems to be a mandatory part of of the TTF font. There shouldn't be such ambiguity, I suppose. – Riddick

hmm, yeah, you're right. that probably is enought to clarify it. :-/ – Milling