I'm trying to test for something's visibility with
$(this).css('display')=="none";
The problem is, it works in chrome, FF...but not in IE. I've tried IE 8 and 9 so far.
Does anyone know a work around? This is very frustrating as a bunch of people still use IE and I don't want to lose that bunch of people.
Use $(this).is(":visible") for a cross-browser solution.
From the docs:
Elements are considered visible if they consume space in the document.
Visible elements have a width or height that is greater than zero.
Elements with visibility: hidden or opacity: 0 are considered visible,
since they still consume space in the layout.
Read more: http://api.jquery.com/visible-selector/
and How to tell if an element is visible
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.
I need to get a reference to the physical location of my canvas element in relation to the document (not the viewport). My problem is that in Chrome document.body.scrollTop returns the correct scroll position and in FireFox document.documentElement.scrollTop returns the correct position. Obviously Firefox just uses a different element to calculate scroll position, but this is really a pain.
This seems like it would be a common issue. Does anyone know if there's a way to force compatibility with a CSS rule? Like, force scrolling to happen on the body or on the html element? I've tried setting the overflow property various ways on each, but it doesn't seem to do it.
I'm open to JavaScript solutions, but I'm trying to avoid "if firefox use this value, else if chrome use this one." CSS would be so much nicer.
Thanks!
You could simply:
document.documentElement.scrollTop || document.body.scrollTop
In Chrome the first expression always returns 0 then the second part is adopted.
In Firefox if, however, the first expression returns 0 (page at the top), the second expression returns 0 as well.
This solution also works in other major browsers.
In Chrome DevTools, under Rendering, there's an option to "Show potential scroll bottlenecks".
When I enabled this, some div elements I have on the screen with overflow:scroll show a flag at the top saying "repaints on scroll."
I can't find a lot of documentation on this feature, and I don't know whether it's something I can actually fix or improve upon, or just a statement of fact - the divs have content, and they do indeed scroll.
You can apply this CSS on the div with overflow: scroll or overflow: auto that create scroll bottlenecks.
transform: translateZ(0);
-webkit-transform: translateZ(0);
That will force the browser to create a new layer to paint this element, and sometimes fix scroll bottlenecks (especially with Webkit).
Although the accepted answer solves the problem, it is worth looking at the CSS will-change property. This is preferred over transform: translateZ(0); in recent times. Here is an that article explains the difference in detail - https://dev.opera.com/articles/css-will-change-property/
.scroll-container {
will-change: transform;
}
This amazingly took me multiple days to track down what was going on, and only because I saw the one side-comment at the end of a bug report at
Chromium bugtracker Issue 514303. Here's what's going on and how to fix it:
There exists a concept called "LCD text", which I believe means subpixel antialiasing, i.e. "crisper sharper text". Unfortunately, this feature is mutually incompatible with compositor-accelerated scrolling.
LCD text is enabled by default (at least on Blink/Webkit?) on all platforms which are not high-DPI (most normal monitors; i.e. you can check console.log(devicePixelRatio)). On the other hand, LCD text is DISABLED by default on high-DPI devices (think Retina display, or most mobile devices and tablets) since you don't really need a "crisper sharper text" feature on high-DPI platforms.
Therefore the opposite is true for compositor-accelerated scrolling: it is only possible on high-DPI platform where LCD text is disabled.
However, you can force compositor-accelerated scrolling on most monitors by promoting the overflow:scroll element to its own layer, by either adding will-change:transform to that element, or any hackish equivalent which will force the overflow element to be the parent of its own layer (such as transform:translateZ(0)). (Do note that vendor prefixes are being removed.)
tl;dr: Chrome doesn't suppose both subpixel antialiasing AND gpu-assisted scrolling; pick one or the other. Subpixel antialiasing is the default pick on Chrome (except on cellphones and retina displays, because their text is so small you don't need the feature, so you won't notice this issue on those platforms). Override this by forcing the element into its own compositor Layer with will-change:transform (but note that maybe your text won't look crystal perfect).
Nope, you cant modify that, it is a Chrome function to allow you to know, what's painted each update in the window.
Updates can be a lot of different things (scroll, mousemove, interval, requestanimationframe,...).
But, now you know that, you can enhance your code.
If (I dont know), the browser alway re-paint a div if it is set to overflow scroll you maybe can do some JS to set to overflow hidden when out of screen...
This post talk about different Browser layout
Have come across this problem when testing some older stuff in IE 11. Example here:
http://codepen.io/Samih/pen/zaqjA
Basically, when you have a display: table-cell element which has contents positioned absolutely, it works fine until you modify the content of that absolute container. You can see this by clicking one of the table cells in the example.
In Chrome, Firefox and even IE 10 this does not cause a problem, but in IE 11 you can see that the table cell height disappears to 0 and does not come back until you do something like resize the window.
I have tried a hack solution that involved using javascript to alter the cell size and then change it back, but it proved unreliable in the place I applied it. I'd much prefer a CSS based solution if anyone can come up with one.
I found an answer myself. Applying display: inline-block to the position: relative element fixes the problem in IE 11. I've no idea why, mind - but it works!
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.