Rick Faircloth wrote:
As much as I dislike the idea of having to develop two different sites or, sometimes, just different pages, it seems like that is the only way to accommodate both JS and non-JS users.
Things can get complicated enough that this is the best bet. But you can generally go pretty far with unobtrusive approaches.
For instance, one use I plan for jQuery is with calendars I develop. These are calendars which have one row with columns for date, time, event, and location. Usually, I put a "details" link on the row for the page to refresh and reveal the details beneath the main row. That works well, but would be much better with a slide and show jQuery effect. However, if JS isn't working, the details for every row in the calendar will be showing and that's a no go. Perhaps there is a way to cause the calendar to default back to its original functionality with a page refresh. Or the alternative is to develop two pages and send the user with JS to the JS page and the non-JS user to the non-JS page.
I can think of three different approaches that would work here. The differences have mainly to do with how you would want the page seen in a non-CSS environment and how you would prefer to balance page size per server hit against the number of server hits it takes to view your data.
The simplest approach is to include the detail data inline in table rows following the summary rows, but have the CSS turn off the display of this information. Then use JQuery to convert the detail links to triggers that will show and hide the relevant detail rows. This is fairly easy to do with JQuery. There are several disadvantages: Non-JS users are downloading large amounts of data they can't see (although if they click the link it will be available on the next page.) If users are likely to want to see only a small portion of the details, there is again a lot of wasted bandwidth, although it is a single server hit for all the data, which can also be important. And users without CSS may have large amounts of detail mixed together with your summary, which could be good or bad depending upon your use-case.
A second approach doesn't change the bandwidth problems, but avoids intermingling the details with the summaries. Put all the details further down the page, in divs that the user jumps to via the detail links. Then use JQuery to transform these divs to appropriately placed table rows and convert the links as before. This technique is a little more complicated from the JQuery perspective, and has a different feel for non-CSS users, but is pretty similar overall.
The third approach would be to AJAX the details in. If you do it real-time when the user clicks the detail link, you don't waste bandwidth, and for the JS-enabled user, you save bandwidth. There will be more of a delay for the JS user though, than in the earlier techniques. If you AJAX these at page load, you gain much of the responsiveness at the cost of increased bandwidth. Either way, this AJAX also increases complexity server-side, as you now have to respond to page request and component requests. Well designed, it's not a huge burden, but it's more complex than simple pages.
I'm sure there are other good approaches too. Cheers, -- Scott Sauyet
