Initially, I believed the problem lay in your search for element instead of element-7, which is what is visible under your mouse cursor. It seemed like you were getting confused by Chrome displaying inline CSS information through element.style. Perhaps ensuring that your image corresponds with your code would help clarify things.
However, after testing in jsfiddle, it became evident that this was not the issue. The real dilemma arises from the fact that the two methods you are using to examine things involve computed values. The user agent converts your font size to an integer, and once those computed values are in place, there's no flexibility.
Essentially, the Chrome developer tools were directly inspecting what you input into the DOM, rather than the computed values. (If you look at that div in the fiddle or run your own test, you'll notice that the computed value for font-size differs from element.style's value.) Therefore, mimic this behavior and avoid relying on the computed values:
alert(labelElement.style.fontSize);
This will yield the desired result. While jQuery can achieve the same outcome, the process is more convoluted - you'd have to extract the style attribute and then decipher the string –
alert($("element-7").attr("style");
as a starting point, but obtaining the font-size would require additional effort.
There doesn't appear to be any indication in the CSS or HTML specifications mandating that a user agent should handle floating-point pixels. All examples I've encountered regarding font-size in the spec implement integers when using pixels. Furthermore, I came across a blog post by John Resig asserting that floating-point pixels aren't practical. This explains why computed values consistently return integer values - float pixels are simply not standardized.