On a dynamic site of mine I faced a problem that consists in the following:
In Internet Explorer 6 after changing the size of the div element with the help of JavaScript, its child elements that are 100% in height do not refresh right away (ie. do not stretch to their new size) but only when the parent div is clicked. It seems to me that the document needs some update. I'd like to ask if there is sort of a command (like that in Flash) that updates the document after some dynamic changes get happened? In brief, how can this problem be settled?
Requiring reflow in IE6 is a very common problem with a massive CSS/JS base. Usually all you have to do is change a parameter on the element that requires a reflow, like, for example, set display:none and then back. This will cause browser to reflow objects in and around current object. Most of the time you will have to do it from JavaScript. If you don't want to do display, try changing height/width or add/remove flow or clear parameters. They all will cause reflows of the page.
However, most of the time if you are running into reflow issues in IE6 it usually means that either you have way too much CSS on the page, or you are using CSS for things it shouldn't be used for (like laying out elements on the page that in HTML go in a wrong order, i.e. element1, element2, element3 in HTML; element2, element1, element3 in display). I would suggest cleaning up your CSS and most of the times, reflow problems will go away.
If you have to click on it to refresh, then why no try to simulate a click, after the size update. Simulating mouse clicks in JavaScript
I know that I have been burned (more than once unfortunately) to have returned invalid xml for an ajax response. IE in particular is very non-forgiving in this respect. It might be worth validating the response just to be sure. In some of my cases, the bad XML caused JS to fail and not "seem to work".
Related
I'm working on some code I inherited that uses jQuery to generate some DIV blocks containing text and images. It generates the blocks, appends them to the page, then calls outerHeight() on the blocks' inner text elements and uses those heights to calculate how big the accompanying images should be.
In all browsers except Safari, things work fine.
In Safari, when outerHeight() is called, sometimes the just-appended elements aren't fully rendered, so the measurement returned is not accurate, and the resulting page doesn't look right. I can see this in the debugger - my breakpoint is hit just after an incorrect outerHeight() is saved, after a second or two I see the rendering catch up, and calling outerHeight() again gives the correct value.
I've tried to serialize this sequence more explicitly using setTimeout and to call outerHeight() a bit later in the code. This made the issue happen less frequently, but it still happens sometimes.
I feel like this has to be a common pattern - get the dimensions of just-appended elements. Has anyone dealt with this before?
Experimenting with various delays, I saw that most of the time, Safari would finish rendering the appended elements after no more than 250ms or so. To deal with this issue, I use setTimeout to run a function after a delay to check whether the previously measured heights match the current ones in the DOM. If they don't, then I know that the rendering has changed, and I re-do the layout of these elements.
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 a function that positions an element in my Firefox extension, and I need that function to be called whenever an event causes the window/chrome layout to change.
Events would be:
When a new window is created, after the chrome is rendered.*
When a window is re-sized.
Any other event that might cause the chrome layout to change size or shape?
(*) Right now, the function runs when a new window is created using:
window.addEventListener("load",myfunction);
But this runs before the chrome is rendered, and element sizes have wonky values. I need it to run after Firefox determines the actual size and placement of the chrome elements.
What are the events I would need to bind to, and how do I bind them?
I was in a similar situation, and didn't really find a good solution. However, the non-standard MozAfterPaint event may help, but comes with a somewhat sizable performance penalty however (so make sure you remove it once you don't need it anymore).
The resize event should do the trick.
There are tons of things that may cause things to change. New CSS/Images loading, toolbar customization, etc. 1. and 2. should cover most (all?), however.
The devtools layoutview ("Box Model") seems to use MozAfterPaint as well.
If possible, you should try to avoid having to calculate sizes yourself, however, by making use of the XUL/HTML flexbox model and CSS without fixed sizes (or min/max sizes only).
Our site uses Websocket, so it already requires late-model browsers. Given that, how can I be notified when an element resizes? We may have canvas and svg child elements that need to resize in response to the parent DOM element resizing.
Elegant method would be to hook 'onresize' but, alas, it does not get called on elements (at least not in Chrome 18). Would prefer to not be offered an answer to periodically fire a timer to test for a change in element size.
Also, please understand that the reflow may not be caused by the window or body being resized, so please don't go there.
Any brilliant, simple, elegant ideas would be hugely appreciated.