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?

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?

• javascript
• internet-explorer
• html-parsing
• offsetwidth

• do you have any samples to demonstrate this? – lincolnk Commented Aug 23, 2010 at 4:06

2 Answers 2

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.

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