Created attachment 219589 [details] test case In RenderBlock::baselinePosition the baseline value is calculated as follows: font baseline + (lineHeight - fontHeight)/2 return fontMetrics.ascent(baselineType) + (lineHeight(firstLine, direction, linePositionMode) - fontMetrics.height()) / 2; The font metric values are CSS pixel values, lineHeight() returns LayoutUnit. While calculating the baseline, the CSS pixel values (font metrics) get converted to layout units and at the end the result gets floored to CSS pixel value (return value). The floored return value can end up being different, if the /2 operation results in a negative value with fraction. subpixel on: ascent: 9px + offset: -0.5px = 8.5px -> 8px subpixel off: ascent: 9px + offset: -0.5px -> 0px = 9px observed on cnn.com
<rdar://problem/15694755>
Created attachment 219605 [details] screenshots adding anim gif to demonstrate the off-by-one rendering.
Created attachment 219692 [details] screenshot (apple.com) RenderInline::baselinePosition has the exact same calculation as RenderBlock and the missing rounding shows up on apple.com (screenshot attached)
Created attachment 219694 [details] test case (apple.com)
And by flooring, I meant bias vertical centering similar to bug 101848
The current subpixel rendering is closer to FF's rendering than it would be with the rounding (supbixel off in practice)