Better APIs Positioning Styling
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
See related issue Better_UI_Layout.
Why Is This Important?
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?
- Getting absolute coordinates from a DOM element
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?
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
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.