Does $('#idOfLememt').outerHeight(); yield same result for all browsers? Any thing different for IE7?
Just go to http://api.jquery.com/outerHeight/ with the different browsers you want to test and see for yourself (on Mac OS X so can't check IE for you). It looks like the DOM in the demo has all possible styles that would affect this included.
Most of the time you can rely on jQuery to do it's thing and give you consistent results across browsers, that's one of it's main reasons for being after all.
Edit: Of course this won't be the case if the browser messes up with something else, for example if your container isn't fixed height and IE renders something inside your container with a different height for whatever reason then the result would be different. You are however pretty much guaranteed to always get the same result as the amount of pixels used on screen.
Like SLaks said it should work fine.
There is one downfall you might run into though if you aren't explicitly setting margins and padding in your CSS. outerHeight() will include padding and border always and if includeMargin is true than it will also include margins. With some padding/margin discrepancies across browsers... ahem... IE... you may get different calculations unless you've explicitly set the border, padding and margin on the element in question.
It should work fine. (Unless you have other layout issues)
Related
Im experiencing an IE bug. The CSS counter property doesn't work in IE9 for elements that are hidden on page load (eg tabs).
css counter not working in internet explorer for hidden content - how to fix?
As I posted above, I've been able to fix this by setting some inline CSS with JavaScript. I set padding-left to 0 (even though the element already had no left padding) when its unhidden. This makes IE 'redraw' the element and the CSS is then applied correctly.
This isn't and ideal solution however. If the design changed to have left padding on the element then my JavaScript fix would break the layout. What other method can I use to make IE 'redraw' the element? Is there a standard way to do this?
Paul Irish has compiled a list for you
What forces layout / reflow. The comprehensive list.
All of [the properties or methods found at this link], when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
I don't want to post the entire list here to avoid plagiarizing, since I am essentially adding nothing to the answer; I am simply pointing you to it.
However, I will say that while Paul Irish warns that using these is a "common performance bottleneck", they can be used strategically to force reflow when desired. This is especially useful in browser-specific scenarios.
If you want to limit the reflow to just IE9, you will want to wrap your layout-thrashing calls inside a feature detection check.
Inputs like textboxes and checkboxes work extremely slow in the bootstrap modals. When user types some text, cursor is moving but the letters appear only in several seconds. The same behavior with checkboxes, checked/unchecked state changes only in several seconds.
Can be reproduced only IE8 and Vista machine.
does anybody has an idea why it happens.
here is a video with an example.
you can try it here in the login dialog.
not 100% why, but ie8 has extreme problems rendering sites using position:fixed in their layout process. on random element(s), position:fixed shouldn't be too much of a problem, but typically when this issue arises it is because it is being applied to elements that are used as wrappers or containers, that usually are full of content.
for whatever reason(s), ie8 has a mighty difficult time rendering here...its best described as delayed response(s), where the user isn't sure if they actually interacted with the site, because nothing happens after their action(s).
changing fixed to absolute is the best answer in these cases, most of the time. i know there are situations where this will not apply, but everytime i've faced this issue, the element(s) had wrapper element(s) with position:relative set, and swapping out absolute for fixed could not have been easier.
ideally for me, is to serve up the different setting in conditional comments, which also is quite useful just in case changing from fixed to absolute breaks something(s)...you can target them in ie(s) and ie(s) alone with the cc's.
I have the following webpage:
A tall webpage with only a vertical scrollbar and no horizontal scrollbar. The document and window therefore have the same width.
When I ask IE8 for $(document).width(), it returns the viewport width including the vertical scrollbar. FF returns the right answer.
I cannot use $('body') for this, because it returns the same width as the window object (it is set to 100% somehow, so it doesn't work when the page gets smaller).
How can I make IE8 output the right value? Thanks in advance.
UPDATE
I actually did some more testing to my problem. and I found that when the horizontal scrollbar becomes visible as well (because of a smaller window), IE8 DOES get the right size. So this makes my problem even more complicated because I can't set an ugly if(IE8)-hack.
UPDATE2
The problem lies in my CSS and jQuery.
The actual case seems to be the problem:
My css says:
body
{
overflow-y:scroll;
}
IE8 doesn't count this as part of the body, but IE7 does. How to fix this? Call jQuery for a fix?
I put this problem to the jQuery crew: http://bugs.jquery.com/ticket/8048.
They don't think it's a bug. Their advice is to use $('body').width(). And this does indeed the job for me.
I still find it strange that the body in IE8 is adjusted to the scrollbar, but the $(document).width() stays the same. I used this jsFiddle for testing. It results in the same glitch, but jQuery thinks it's ok, because W3C doesn't say anything about it... Or something like that.
In IE7, this code isn't working properly:
myJqObj.css("height", DEFAULT_HEIGHT);
When it runs, it seems to set the height of myJqObj to 0; However, if I query the height immediately after setting it, everything works fine:
myJqObj.css("height", DEFAULT_HEIGHT);
myJqObj.height();
This also works:
myJqObj.css("height", DEFAULT_HEIGHT);
myJqObj.width();
I'm sure if you run the previous code on its own, things will work fine. This is all happening in the midst of some fairly complex page building. There's obviously something in my js environment that's causing a bug. Anyone seen anything like this before? Any ideas where to start looking?
I would check specificity. Have you verified your "myJqObj" object is specific enough for IE7?
When I set CSS that takes in FireFox and not in IE7, it's usually because I've set CSS for an element such as the <div id="mydiv"><p> element, and my <div id="mydiv"><p class="myclass"> height definition is being overridden by the first definition.
You might be looking in the wrong place.
Have you set myJqObj to float in the CSS? If so the height will actually be 0 since a floated element collapses.
Same problem setting height in IE7
Solved it too by just querying the height after setting it.
Is this a bug???
In the code for Bootstrap collapse, in the hide() method, I see the following line:
this.$element[dimension](this.$element[dimension]())[0].offsetHeight
I don't understand what the point of the .offsetHeight at the end is unless it has a side effect, because it's not being assigned to anything. Does it have a side effect?
Some old browsers like old versions of IE had the problem of sometimes not reflowing (re-rendering the presentation) after you performed some actions.
Mearly querying some properties like offsetHeight forces the DOM to recalculate and redraw the objects on the screen.
So, the side effect is forcing a reflow (redraw) of the screen. Quirky, but an old trick for old browsers.
Here is a question where this is suggested as a solution for an old version of Google Chrome where it did not work properly without it.
here is a useful comment from bootstrap team:
if (doAnimate) this.$backdrop[0].offsetWidth // force reflow