I am, too. The same font rendered by Core Text, FreeType, and Direct2D/DirectWrite will not have the exact same dimensions every time despite coming from the same exact file.
Say I render a font with no anti-aliasing on an embedded device, because it's marginally more expensive to do so. If I did anti-alias it, you have to account for possibly growing the bitmap size to do so. If I did, am I no longer compliant with web standards? No, because the web standards don't specify dimension requirements for text nodes from source fonts.
Further, there are multiple different types of ways to anti-alias. Should the web standards dictate how?
The annoying aspect to me isn't the change in dimensions, but the inaccurate baselines. If we could reliably align text based on its baseline it wouldn't be an issue. "align-items: baseline" would be brilliant if it actually worked cross-browser.
It's pretty telling that Github doesn't even bother to solve the issue in their redesign, they've seemed to write off Firefox text alignment idiosyncrasies.
It would have been great had I known details like this much earlier in my career, but when people talked then about "pixel perfect" designs, I don't think most people understood then what sacrifices you have to make to do so! Box size calculations should be the same, I think, surely. But text specifically has no such requirements for equal precision.
In truth, that type of work would require you to know the output sizes across every supported browser.
Say I render a font with no anti-aliasing on an embedded device, because it's marginally more expensive to do so. If I did anti-alias it, you have to account for possibly growing the bitmap size to do so. If I did, am I no longer compliant with web standards? No, because the web standards don't specify dimension requirements for text nodes from source fonts.
Further, there are multiple different types of ways to anti-alias. Should the web standards dictate how?