We Keep Coding

"getUnComputedStyle" of element

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.)

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.

If I understand what you are trying to accomplish correctly (and if I don't please say so and I'll try to improve my answer), and assuming you have already managed to catch the zooming event some how (which is not a given), you could:
Clone the div you are trying to get the CSS styles from;
Append the clone to the dom in an unobtrusive way (ie, a way in which it will not cover any other elements on the document);
Remove it's style attribute (just in case it was set by other scripts or functions);
Get all the styles you need from it;
Finally, remove the clone from the dom when you are done.
This demo works for me, regardless of page zoom.
jQuery(function($) {
function getRawStyles(sel, styles) {
sel = $(sel);
var clone = sel.clone().removeAttr("style").attr("class", "cloneDiv").insertBefore(sel);
$.each(styles, function(index, style) {
console.log( style + ": " + $(clone[0]).css(style) );
});
$(".cloneDiv").remove();
}
$(document).ready(function() {
$("button", this).on("click", function() {
getRawStyles("#myDiv", ["height", "width"]);
});
});
});
#myDiv {
background: grey;
height: 50px;
width: 200px;
}
.cloneDiv {
left: -10000;
opacity: 0;
top: -10000;
position: absolute;
z-index: -1;
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
<div id="myDiv" style="height:200px; width: 100px"></div>
<br/>
<button>Log Computed Styles</button>

jquery .scrollTop() screen height

I have been writing a small script that shortens documents that are being output on a JSON feed of mine.
I realised that with longer messages, on minimising it could skip a few and you'd have to scroll back to find where you were and so added a scroll function to take you back to the top of the message on minifying. This turned out to be quite annoying when it fired every single time - so I thought, why not make it fire only when the top of the element is above the screen?
And this is where I am stuck --> $(window).scrollTop(); simply doesn't want to output the screen height for me, it's infuriating. I tried with different browsers and the only one .scrollTop() worked for correctly was Internet Explorer.
Here is the function below:
function jexpand(id){
var elm=$('#d'+jdesc[id].i); // element
var ofs=elm.offset().top; // element height - works fine
var top=$(window).scrollTop(); // Y U NO WORK?!!!
if(jdesc[id].e==true){ // boolean to check whether to expand or contract
jdesc[id].e=false; // change boolean flag
if(ofs < top) $('html').animate({scrollTop:($('#'+jdesc[id].i).offset().top)-(20)+'px'},'slow'); // animate to top minus 20 pixels
elm.html(jdesc[id].d.substring(0,347)+'...<br><div class="readmore"><span id="'+id+'">Show More</span></div>');
}else{
jdesc[id].e=true;
elm.html(jdesc[id].d+'<br><div class="readmore"><span id="'+id+'">Show Less</span></div>');
}
$('.readmore span').click(function(){jexpand(this.id)}); // reset click trigger
//alert(top+' <-> '+ofs);
}
When I uncomment the alert() at the bottom in a browser other than IE (I tried chrome, mozilla, chrome android, boat browser android) I get a message akin to:
[object Window] <-> 1077.5625
[object Window] is obviously not a number that can be greater or less than the element height! So what does this mean, is there another flag I need to ask of it? At first I assumed it might be the wrong element I was refering so tried top=$('body').scrollTop();, html, etc, I even tried using div wrapper elements but to no avail.
I am using jquery 1.11.0 and with 1.9.1 I had the same issue.
Am I trying to return the screen top in the wrong way or have all my browsers gone loopy?
EDIT:
Weirdly I've found an issue which may explain things a little, when I typed $(document).scrollTop() into a console it gave me the correct screen height however if I make a var top; outside of the function I get this error 'window.webkitStorageInfo' is deprecated. Please use 'navigator.webkitTemporaryStorage' or 'navigator.webkitPersistentStorage' instead..
I am using a webkit borrowed from html5up and this is somehow interfering with the code. Now to find out what it is....
Sorry for the confusion, without this script everything works fine grr...

Try this way
JS CODE:
$(window).scrollTop(0); // this will scroll to top of the page
LIVE DEMO:
http://jsfiddle.net/dreamweiver/fZrz7/6/
Happy Coding :)

What about $(document).scrollTop()? It always worked for me.

Try smth like this..
if($(window).scrollTop()>500){
elm.html(jdesc[id].d.substring(0,347)+'...<br><div class="readmore"><span id="'+id+'">Show More</span></div>');}
else{
elm.html(jdesc[id].d+'<br><div class="readmore"><span id="'+id+'">Show Less</span></div>');
}
If work try next with
var ofs=elm.offset().top;

Try this:
$(document).height(); //returns window height
$(document).scrollTop(); //returns scroll position from top of document
$(selector)[0].scrollHeight;
$(document).prop('scrollHeight');

jQuery: how to make css('line-height') work cross-browser

I'm supporting IE8 and up.
$(something).css('line-height');
In Chrome this returns 32px but in IE8 it returns normal
How do I get around this? Maybe a native javascript variation?

Seems like this is a webkit vs. IE issue. Not sure about FF, but there are a couple options for how to fix it. Overtly specifying a pixel value will work. But I don't like doing that because it's harder to keep things in proportion if you scale the text, etc with media queries. I was able to get it working by overtly specifying the line-height in ems (rather then letting it inherit). It's also relevant that it was previously set to rems which IE8 doesn't recognize.

function lineHeight(element){
var tmp=$("<div>test</div>");
element.append(tmp);
tmp.css({"padding":"0","margin":"0","border":"0"});
var height = tmp[0].clientHeight;
tmp.remove();
return height;
}
jsfiddle in FF and Chrome return 20px but on IE8 18px

clientWidth and clientHeight always returns zero for ie7

I have no idea why, but clientWidth and clientHeight are always returning zero when I run this from IE in IE9 compat View, or IE7. It works for everything else.
Very simple code snippet with problem (so that you can try it too):
http://jsfiddle.net/nz2DA/
The code snippet found above is as follows...
I have a page containing the following HTML snippet:
<div id='aaa'>aaaaaa</div>​
And my javascript to test the clientWidth and clientHeight functions are as follows:
var el = $('#aaa')[0];
alert('Client width and height: '+ el.clientWidth + ' X ' + el.clientHeight);​
This always pops up an alert with "0 X 0" when I run in IE7 or IE9 Compatibility mode.
Any help or explanation would really be appreciated. Thanks!

This is happening because of the "hasLayout" property in IE, and your div on its own does not "have layout". For more information, see http://www.satzansatz.de/cssd/onhavinglayout.html
Luckily you can trigger an element to have layout, which is why adding the "float:left" style works in the answer above. There are other triggers you can use too though that don't change the page. This one gives me proper values for clientWidth and clientHeight:
<div id="aaa" style="zoom: 1">aaaaaa</div>
The article says that setting "min-width: 0" should also work but it didn't for me. Setting "display: inline-block" worked OK but that might change your page. You can set these triggers in CSS so that the HTML doesn't need to change at all.

I tested your code and following are the observations.
in IE(sucks!), if you didn't apply any styles for the "aaa" element IE won't calculate any width and height. So JS simply give you 0. But if you look at the box model from the IE dev tool bar you will see some value. So if you use float:left to that element JS will return a value, which is correct and all browsers will give you the same output.
Since you are using jQuery why don't you use width() or outerWidth() or innerWidth(). These methods are generelaized for the every browsers. Simply if you use width() you will see a very large width since you didn't apply any styles. In IE if element doesn't have an float value it gets it's parent width.In your case it's window width.
So if I modify your code to get correct width and height would be:
HTML:
<div id="aaa" style="float:left;">aaaaaa</div>
JS:
var el = $('#aaa')[0];
alert('Client width and height: '+ el.clientWidth + ' X ' + el.clientHeight);
Please let me know if you need more clarifications...
cheers!

Try offsetHeight property of internet explorer.

Firefox and Chrome give different values for offsetTop

I am trying to position an span element (let us call it "the tooltip span") relative to a input field. To do this, I am wrapping the tooltip span and the input field in another span element (let's call it "the wrapper span") that has position: relative. Then I set position: absolute on tooltip span. This makes the tooltip span position itself relative to the wrapper span but not being part of the page flow - not taking up any space. This is exactly what I want.
Then, using javascript, I set the position of the tooltip relative to the position of the input element. Since the input element can be shaped differently on different pages (script should be globablly applicable), I am using its offsetTop and offsetLeft properties to calculate its position relative to the wrapper span.
However, I am noticing inconsistencies between browsers here. In Firefox, IE6, 7, 8, it works as expected. But in Chrome and Safari the reported offsetTop seems, well, incorrect.
To prove this, I created the test page below:
<html>
<head>
<style type="text/css">
span { font-size: 8px; position: relative; top: 0; left: 0; border: 1px solid red }
</style>
</head>
<body>
<span id="wrapper">
<input id="foo" name="foo" type="text">
</span>
<script type="text/javascript">
document.write("<br>Offset parent: " + document.getElementById("foo").offsetParent.id);
document.write("<br>Offset top: " + document.getElementById("foo").offsetTop);
</script>
</body>
</html>
and loaded it in Firefox and Chrome. Both browser report the wrapper span as its offsetParent, but for Firefox the offsetTop is -8 and for Chrome it is 2. Visually the page renders the same in both browsers.
This gives me a headache, because I cannot just hack in a different offset that I always apply when someone is using Chrome, because if I change the font size, the offsetTop will not change, and my script will break.
Is this a bug? Can I solve this differently?

You Can try using
$(window).load
instead of
$(document).ready
because Explorer and Chrome sets proper offsets only after images have been fully loaded.

I've been having the same problem as you and I realized that (in my case) the thing that was messing up the offset().top value in chrome, was having one or more images without the "height" attribute above the element.
Before
<img src="/images/foo.jpg" />
offset.top() was 100 in Chrome
offset.top() was 150 in Firefox and IE7 (beleive or not, it worked just fine in IE!)
After
<img src="/images/foo.jpg" height="50" width="50" />
offset.top() is 150 in both Firefox, IE7, AND CHROME.
Notice the the difference was 50px, which is actually the same as the image height.
Since I was developing a JQuery plugin, i tryed to collect all the images that had their width and height attributes undefined, and manually setting their size with .width() and .height(), but it didn't work, because Chrome returned 0 for both functions. So, i guess the problem with offset.top() actually relies on that. If JQuery is triying to get te offset.top() value by accumulating the "above" element's height, and one of those elements it's an image with no specified height, "0" will be added to that sum, and therefore the top value will be missing those "ignored" heights.
PS: Sorry for my english, it's been a long time since i wrote such a long text in this language!

Use jQuery. DOM differences between browsers is one of the things it excels at.

Put you code into a window.onload function. I recall having issues when attempting to work with the dom directly from a <script> during page load in firefox, and webkit tends to be slightly more willing to give a sane DOM at such points.
This is just based on prior issues i've encountered, i'm not sure if it's applicable to your case.

I ran into the same problem, and jQuery's position() function was reporting the same as the offset() function. Ultimately it turns out that even waiting for the document to be ready didn't work for me. I had to check offset() later in the flow (in my case, in my handler that is fired on a window.scroll event).
When I try this test code below, on page load, I get different figures for Firefox + Chrome. Once it loads, however, I can press 'd' and I get the same figure for both browsers.
// this produced different results on Chrome + Firefox (Chrome was wrong!)
$(document).ready(function () {
var x = $('#some-div-on-your-page').position().top;
alert("On load, offset is "+x); // Chrome + Firefox report diff figures
$(window).keydown(function(e, r) {
k = e ? e.keyCode : event.keyCode;
if(k == 68) { // press 'd'
var x = $('#some-div-on-your-page').position().top;
alert("Now the offset is "+x); // ...but this is consistent
}
});
}
Hope this helps.

I was experiencing the same problem, and tried adding to my function
$(document).ready(function(){});
and it worked in both Chrome and Firefox

If you get "0" in chrome, see if you are targeting an empty element like "a". It needs to wrap something in order to return the correct offset.

It could be related to the different border/margin values for the HTML and body elements that browsers set by default.