Computed Box Model and Style
From RuntimeWiki
NOTE: This feature has been moved to the inactive list because there were two feature requests that were largely redundant. Please refer to Better_APIs_Positioning_Styling instead.
Contents |
Title
API Support for Calculating Computed Box Model and Style
Detailed write-up
Description
See related issue Better_UI_Layout.
Getting computed box model calculations out of IE is not for the faint of optimization. According to reference How IE Mangles The Design Of JavaScript Libraries, when Dojo folks profiled Dojo Dojo 1.0 widgets, they noted very quickly that getting box-model data out of the browser for any element is hugely costly on every browser, but on IE the cost was not just big… it was enormous. Their best guess is that the properties on the currentStyle property are re-calculated when they’re requested from script and not cached in the bound object when layout happens. The resulting performance penalty requires that developers nearly never manage layout in code, severely constraining the layouts which are attempted by toolkits like Dojo.
Several tasks such as drag and drop require the pixel-precise detection of the absolute position of an element relative to the top-left corner of the document. Implementing such a function in JavaScript is very complex and requires a lot of testing (see Getting absolute coordinates from a DOM element).
Internet Explorer has getBoundingClientRect which is also getting implemented in Firefox 3 and apparently also in Opera 9.5. WebKit has a stale bug on this, which we could try to lobby for.
Why Is This Important?
Current browsers provide limited support for layout management. A lot web sites use “table” for managing layout, while some others use CSS for doing layout. Though both table and CSS are capable of serving the purpose of layout, layout support is not a first class citizen. There is not out-of-box support for common layout managers (such as docking, border layout). There is no layout object and there is no programmatic API for layout management. As a result, providing better layout management has been a task undertaken by JavaScript toolkits. Calculating the computed box model and style is essential for JavaScript toolkits to be able to manage layout.
To solve the challenge, Browsers do not have to re-invent their model to add first class support for layout management. As long as browsers provide good API support for calculating computed box model and style, JavaScript toolkits can implement very efficient solutions for addressing this problem.
Possible solutions
W3C is working on a spec that might help address in this area:
Background material that request this feature
- Why Are Ajax Applications Slow?
- How IE Mangles The Design Of JavaScript Libraries
- Getting absolute coordinates from a DOM element
Discussion
Phase I Voting - Vote for Your Top 5 Features
NOTE: PHASE I VOTING IS NOW OPEN. (2008-04-01) We have now changed the voting procedure. Instead of putting votes on each separate wiki page, we are asking people to cast their Phase I Votes on the following wiki page:
Phase II Voting
More about this later.
