I am in the process of converting my application to use XHTML strict mode (it didn't have a DOCTYPE before). However, I noticed a significant degradation when getting offsetHeight/offsetWidth. This is very noticeable on pages with large number of DOM elements, let's say a table with 1 column by 800 rows, the cells only have a piece of text. Visiting each descendant element in that table to obtain their offset dimension is way slower than when IE renders the page in Quirks mode. Why is that the case? and does anybody know tips to help IE calculate those offsetValues?
+2
A:
I would suggest to force IE to render you page in standards mode not in quirks. This can be done by adding a meta tags on the head of your html document or setup the web-server to add X-UA-Compatible headers.
<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />
Also, use built-in javascript frameworks such as jquery,prototype, yui, etc, most be of them already addressed the issues on different rendering engines.
jerjer
2010-08-23 04:22:00
I agree that frameworks help a lot. I did note in a project recently that IE 8 was still reporting the wrong `$().outerHeight()`. It drove me nuts! It seemed that IE was trying to grab the height while elements were resizing, so I had to implement some synchronization. This was only a problem on IE 8, so it took some time to track down.
sidewaysmilk
2010-08-23 18:28:33
My issue is not being able to render in standards mode. The issue is performance once my page renders in standards mode. I actually isolated the issue to one line of code. The problematic line was:<code>element.absoluteHeight=element.offsetHeight;</code>I erroneously assumed it was getting the offset dimension where the problem was, since I was reading so much about browser reflow. However,once I broke down that line it turns that setting the property on the DOM element is where there is a huge performance difference between quirks and IE8 standards mode, being the latter mode much worse.
Paul
2010-08-23 18:45:21
@Paul: can you make that an answer? I can reproduce this: most operations are much faster in IE8 Standards Mode, including reading the offsetDimensions. However, expandos are slow.
bobince
2010-08-26 11:07:17
@jerjer: `FF=3` doesn't exist and `OtherUA=4` makes no sense. They were only included as potential examples in Microsoft's `X-UA-Compatible` proposal. The other browser implementors have refused to take up this header/meta, as they don't have the built-into-the-OS problem that requires preserving complete bugward compatibility: only IE pays attention. `IE=8` also means you'll get less of an improvement when IE9 is released; consider `IE=edge` instead to always use the latest version.
bobince
2010-08-26 11:13:11
+1
A:
@bobince: The issue I believe is around reflow. The logic in my JavaScript tries to figure out if children are overlapping each other (since they get dynamic content that I can't predict) in an absolute layout container and then adjusts the parent's css dimensions and sibbling's css that need to shift down. Changing the css dimensions trigger reflow and this happens in the middle of my iteration, this scenario seems to be much slower in IE8 standards than in IE8 Quirks for very large tables. I know that I should hide or use documentFragment when doing this type of operations, however because I need things to move and then look at the new offset dimensions I was getting inaccurate values.
Paul
2010-08-28 02:11:17