"getUnComputedStyle" of element

Question

I found differencies between browsers how they report computed style dimensions when browser window is zoomed. The JSBIN example is in http://jsbin.com/pilohonevo/2/. The code is as follows:

$(window).resize(function()
{
  var width1=$(".class1").css("width");
  $(".class1").css("width",width1);

  var width2="200px";
  $(".class2").css("width",width2);

  var width3=$(".class3").css("width");

  $("#width1").html(width1);
  $("#width2").html(width2);
  $("#width3").html(width3);

  $("#overflow1").html($(".overflow1")[0].scrollWidth);
  $("#overflow2").html($(".overflow2")[0].scrollWidth);
  $("#overflow3").html($(".overflow3")[0].scrollWidth);
});

When you zoom to minimum by pressing CMD- few times and then back to 100% by pressing CMD+ few times, in Chrome (Mac Version 38.0.2125.111), you get the following values:

The white DIV 1 reports its width as 203px, although DIV 2 and 3 reports 200px. Also scrollWidth is 203, which is wrong as well. This means that you cannot use getComputedStyle or jQuerys .css() to get dimensions if you are not sure that browser window is not zoomed. And because zooming is not cancelable you can never be sure and you can never trust to those dimensions. I tested also $(elem).scrollLeft() and $(elem).scrollTop() and those are unreliable as well when zoomed.

So a workaround can be to use "raw" values, not "computed" values.

Is there a cross-browser javascript or jQuery method to get something like getUnComputedStyle() which determines dimensions using raw values from stylesheets and/or style attribute, because they are the only ones that are zoom-safe?

Determining zoom level and make corrections based on that is unreliable according to my tests, because there are browser differencies and error levels in different style properties are not consistently related to zoom level.

(Firefox Mac 33.1 and Safari Mac version 7.1 (9537.85.10.17.1) and IE 11 Win and emulated modes down to version 7 report correct values.

Opera Mac 25.0.1614.68, Safari Win 5.1.7 and the above reported Chrome report wrong values.)

Answer 1

I've reproduced this with Chrome 49 and JQuery 1.11, not in FF and not in Internet Explorer.

However, I believe this to be an artifact of the code as well. The only divs that show this problem are div1 and overflow1, which both use the same system of setting the width to the computed width, repeatedly. What happens is that for some zooms the computed value is 201. You set the width to 201, so for some zooms the computed value becomes 202 and so on. I got 204, for example.

In the Chrome debugger, at zoom 67%, the reported width appears as 199.981, but the values available to Javascript are integers. scrollWidth is 199 while clientWidth and offsetWidth are 200. All of the jQuery width methods return 200 (width, innerWidth, outerWidth). At zoom 33%, scrollWidth and jQuery widths all return 201, althought the debugger reported width is still 199.981.

My assertion is that the problem is a bug in Chrome and probably related to rounding.

As described here: Getting the actual, floating-point width of an element you can get the actual floating point value reported by the debugger with .getBoundingClientRect(). If you want to be completely safe, try using that one.