Phase2Results.php" ); ?> Better APIs Positioning Styling - RuntimeWiki

Better APIs Positioning Styling

From RuntimeWiki

Jump to: navigation, search

NOTE: This feature is the merger/replacement for an older feature, Computed_Box_Model_and_Style, which is now inactive.



Better APIs about positioning and styling

Detailed write-up


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


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 Should both issues be merged?

Carl Dombrowski's 2 cents No. 1

I think it should be easier to get more device independent pages. Right now, different screensizes basically demand different layouts and therefore different pages - whole websites need to be written several times to accustom mobil devices and the likes. Or the programming gets so complex that it's a drag on performance. XML theoretically allows parsing the page according to the device's specs, but as we all know, no-one does it, for performance, cost, and other reasons. Lots of websites can only be accessed with at least 1024x768 pixel resolution, because of that. Many pages are unable to make use of 2000*1500 or higher resolutions in a useful way, not to mention 3D. RSS and similar technologies won't change that, as it is too much effort for most page designers and users. Even I, as a tech enthusiasts, so far only adapted an rss feed to fit into a homepage of mine, with a few issues which I can't resolve due to no useful parsing options if you don't parse yourself, which no-one does.

A simple solution would be to create a version of html which avoids overloading tags with functions that aren't needed - why for instance do block level elements include a carriage return? If tables and other elements could be shoved around like images (may be possible in some ways - I don't know), then a page could easily be created which has text blocks besides and/or below each other, depending upon screen width. Ideally, one tag has only the functions needed for what it is used for, while additional extras are done in separate tags (including things like borders, maybe spacing, and so on). Also, both images and other elements should be placeable at exactly the location they are supposed to be at, not just approximately or bitwise (which is complicated with text) - they should basically behave like single letters, if wished.

While at it, it should also be possible to make text and other elements "flow" within groups of other elements. I'd like for instance a pretty stable layout like a newspaper where the content (not only text) constantly changes and automatically finds a suitable place, by flowing from one container (like TD) to another, in a predefined order (by first opening the "space" like a header and then parsing the text). Priorities might also help to decide which elements wrap first when the screen resolution doesn't allow displaying everything besides each other, and it might include removing elements if they don't fit easily, maybe resolution dependent - many pages for instance have additional menus, quick finding options, and the likes, and those aren't really needed.

Carl Dombrowski's 2 cents No. 2

Generally, it should be usual to include everything which is often done with Javascript or the likes with according HTML tags instead - it should be a constant adaption process, which might also include analysis of Flash, graphics, 3D-activities, and so on.

Carl Dombrowski's 2 cents No. 3

I don't really like the dogmatic separation of text and formatting. While separation is a good idea, it should be left to the web designer what's separated and what not. As it is now, many designers simply make up names for layout elements, thus defining the layout twice - once as css, once in the text. That doesn't improve anything, imo. Also, I find it funny when people labouriously separate the two in static or semi-static pages - obviously not understanding that the main use of this is to automate content changes via a database or the likes, while the semantic options aren't used by anyone (for good reasons).

Carl Dombrowski's 2 cents No. 4

Another separation also only creates unnecessary difficulties without any advantages: That of text and non-text elements (bitmap graphics, sound, objects...). Like an email, it should be possible to easily include binary information in any webpage, to embed graphics and other elements as needed, probably limited to standard formats which can easily be read by standard web page editors (as emails are read and edited by standard email programs). That would also (maybe in the long term) allow other fun, like for instance editing graphics in a browser window without putting too much strain on the server. Generating mixed content from databases and server side programs would also become much easier, as no file system commands would be needed to shove around the non-html content.

Carl Dombrowski's 2 cents No. 5

HTML should be extended with options to directly handle user input - like keys, like directing sound (from a microphone for instance) or video (from a webcam, among others) to a server, and more (security prompts provided). With device independence, that would also allow things like saying "nine" instead of pressing "9" to select an option, among many others.

Carl Dombrowski's notes

If any of this should be put into other pages, feel free to do so.

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.

Personal tools