Better APIs Positioning Styling
From RuntimeWiki
NOTE: This feature is the merger/replacement for an older feature, Computed_Box_Model_and_Style, which is now inactive.
Contents |
Title
Better APIs about positioning and styling
Detailed write-up
Description
See related issue Better_UI_Layout.
Many Ajax toolkits provide a rich set of user interface widgets. To create these widgets, the toolkit developers often have to resort to heroic JavaScript that navigates around browser limitations (not to mention bugs). This feature request is about one area of browser limitations: weak APIs for information about current position and styling on particular elements in the DOM.
Also, there are performance issues. 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.
Sometimes Ajax toolkits are unable to deliver particular user interface features because there is no way that heroic JavaScript can overcome browser limitations.
Sometimes Ajax toolkits require large downloads and run slower due to the heroic JavaScript which works around things that browsers could provide.
Possible Solutions
Some APIs that provide positional information about particular elements, in a few useful coordinate systems. It would be nice to have coordinates that are relative to the top/left of the current document, the top/left of the current window (exclusive of document scrolling), and perhaps to the top/left of some arbitrary ancestor element. For things that are rectangles, we need the location of all four edges. (Do we care about irregularly shaped things, such as text that wraps around an image?). For CSS boxes, would be nice to have margin widths, border widths, and padding widths. For elements, would be nice to have good APIs to determine the computed style (and probably the actual style).
W3C is working on a spec that might address the requirement for better positioning APIs:
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
In this section, the contributors should express their opinions about this feature request, such as providing particular technical analysis or describing in prose why this feature is important (or not). It is recommended that each contributor create his own level-3 sub-section (e.g., === Jon Ferraiolo Comments ===).
It is OK for others to insert comments within other people's sections, but as a courtesy please make sure that it is clear which part of the section is original and which section are annotative comments. For example, perhaps annotative comments would be colorized (e.g., enclosed by <span style="color:red">JON: Here is what I think about what you are saying.</span>).
Bertrand Le Roy's comments
How is that different from http://www.openajax.org/runtime/wiki/Computed_Box_Model_and_Style? Should both issues be merged?
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.
