The self-adjusting intervals are something I've been thinking of for a year now. The JavaScript powered animation on my site is supposed to run in about 1-1.5 seconds, but can take 1.5 minutes on older systems with no graphics card. I don't care in my case, because I'm not trying to sell widgets online, and most of my site is HTML5 anyway (not too long ago I met a woman who was using a donated Mac from the early 1990s as her internet connection! She said she only reads email, though). I was thinking of only using setInterval, and waiting for maybe three interval calls to run, then checking the real-time that has passed, and clearing and resetting the adjusted the interval as necessary. I figure I want to wait and start to get an average, at least, but also since it runs at page-load, there are other things holding up the interval from firing. While I can't say I know this as a fact, it SEEMS that interval 'ticks' are only counted in free-time, that is only when all threads waiting on a stack to be run are completed; ticks are not ticked in-between, so if you set a 1-second timeout and then 5 seconds of threads run (that were waiting on the stack: other intervals, events, etc) after your thread that sets the said timeout, then it will take 6 seconds to start that timeout. If we adjust our animation based on that 6-seconds, we will run it way too fast. Even during the animation, other events may slow it for a moment before occasional interval threads throughout the animation process, and we don't want to simply respond like a reflex. Beyond adjusting the interval, in cases like my website's animations, instead of browser-sniffing and trying to make a determination if the browser can handle the animation, instead let it run a few frames, and if adjusting the interval doesn't help enough, then start adjusting frame positions, skipping frames more and more, perhaps even exponentially, until you reach the end. the key is to write the code and then spend a lot of time tweeking the algorithm that adjusts the intervals/frames so it responds smoothly under all circumstances. Several interruptions by other timeouts/events could severely impact the calculated run-speed, so weight would have to be added to more recent interval-delays and be quickly dropped as more time progresses. The idea is to present a smooth, not jerky, animation that adjusts in real-time to other events AND the speed of the machine.
And I'll take you up on the table-bashing!
Regarding the grid-layout vs tables, my understanding is that the real difference is that not every grid-cell must be filled for the layout to work. Am I wrong?
With a grid, my HTML is content, not presentation. For instance, I just created a tool for Komodo Edit users (see komodo-edit-keys on Mr. Lemos' sister site: PHPClasses.org). I was tempted to have the output in an HTML table at first, especially as this really is tabular data. But then I realized the display limitations this presented. By not using table-based HTML I can write CSS that displays this data as a matrix-table with columns and rows, or "in flow", so the cell-data can all be read, since it would overflow a table-cell, cram the contents vertically and make it nearly unreadable, or demand a large table. I could have written additional CSS to convert the "flow" layout to tables (if you see the HTML, CSS **classNames** on elements are are actually "tr", "th", and "td" to hint at this purpose), and then had a set of radio-buttons powered by a bit of JavaScript to change the presentation to the user-selected format.
A grid layout frees your HTML to do what it is supposed to do: define your content. "Text-Markup" not "presentation-markup." Since I started writing my HTML-CSS pages the way Andy Clarke (of the Web-Standards project) recommends, With HTML that defines the content including **semantic** CSS classNames that further define the **content**, NOT the **presentation**, the faster and easier my pages develop, and the easier they are TO __MAINTAIN__ in the future. I used tables for my MasterColorPicker project (on this site) and not only is it a pain to keep track of what bit of HTML goes in which table-cell, it's a pain to keep track of which cell you are styling with CSS. Building a whole complex page using tables that way? In a word, in-efficient. And once you understand what Mr. Clarke is saying, using table-based-layouts is near insane. Using them in the MasterColorPicker project stretched the limit of what a "table" is. The pickers ARE tables of colors; just not a row-column matrix of them... But although using tables this way skrews-up the layout in Firefox (I'm hoping if Firefox does grids, it allows relativity!), it does offer me a way of presenting the info the way I want it in one of the pickers, where using CSS alone may have been harder, I think. This is an exception.
And as mentioned, tables in eMail would be an exception. But eMail is not a web-page.
With Grid Layout, sure I can define columns and rows that "adjust" like a table, but I can also just define a basic W*H grid and then place my elements where I want to using CSS. Want to change the presentation? No problem to quickly change the CSS. If I had tables, I would have to CAREFULLY rewrite the HTML tables as well.
That would also mean that the presentation cannot be dynamic based on the user's choice (without a stupid amount of JavaScript to parse and re-write the page or sections of it, or a call back to the server...). Grids may offer a table-based-layout, because, yea, it's great! But maintaining HTML tables, in a word, sucks. Grids are NOT equivalent to tables. Even IF every grid-cell MUST be filled, your HTML is still freed to be what it wants to be - a description of the content free of presentation limitations. With table layouts that have several columns, and lots of content per cell, content in neighbor rows is a long-way away from each-other. If your content naturally associates in columns, then it is much easier to write and **MAINTAIN** HTML that groups column data together, and uses CSS to present it. Of course, then each cell must have an ID, and CSS per cell would need to be written, whereas with a table this is not necessary. Note I'm talking about hand-written HTML involving sections of page-content, not programatically-generated truly-tabular data.
And then we can talk about handhelds and their little screens. Stick your content in an HTML table for desktops, and the handheld chokes it. Free your content into semantic HTML markup, and only rewrite the CSS for handhelds (to some extent, of course). Blah blah blah...
Peace and Aloha to all! |
Stumble It!
Bookmark in del.icio.us
