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.
I know jQuery can be used unobtrusively, but in some cases that just doesn't seem to be a workable approach. 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. Thoughts? Rick -----Original Message----- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Young -X (natyoung - Artizen at Cisco) Sent: Tuesday, April 24, 2007 3:48 PM To: jquery-en@googlegroups.com Subject: [jQuery] Re: Best way to determine if a user has Javascript enabled? Hi. There is another surefire solution to getting a site that works with JS and non-js usage, and that is to bifurcate the experience quite early on and send the two sets of users down very different paths. In that case, JS users see one set of pages and non-js users see another. ----------->Nathan > -----Original Message----- > From: jquery-en@googlegroups.com > [mailto:[EMAIL PROTECTED] idea "pages shouoglegroups.com] On Behalf Of Rey Bango > Sent: Friday, April 20, 2007 7:35 AM > To: jquery-en@googlegroups.com > Subject: [jQuery] Re: Best way to determine if a user has > Javascript enabled? > > > Hi Rick, > > Let me summarize what everyone is saying before this turns > into a long thread. > > Basically, there's no easy and surefire way of determining if > JS is enabled on the browser. You need to code your forms and > pages in the traditional way that you would any non-JS > application. Once you have those pages working correctly with > proper server-side validation and handling, then you can look > at progressive enhancement to extend the functionality of > your pages by leveraging JS, DOM-manipulation and Ajax. > > I realize that you're trying to find a way of doing this from > a server-side perspective but you're going to end up building > a hodge-podge solution that will not be effective. You have > some really sharp people giving you the right advice and > since I want you to be successful, I highly recommend that > you follow their suggestions. > > This is the *only* surefire way of ensuring that browsers > that have JS disabled will work properly on your site. > Otherwise, its a shot in the dark. > > Rey... > > Rick Faircloth wrote: > > That's what's motivating the question. > > > > I'm trying to take Progressive Enhancement, as I see it, one step > > further by integrating the enhancement into the server-side > process, > > where possible and applicable. > > > > This part concerns return validation result messages back > to the form > > page, or rather back to the page itself, since I'm > currently posting > > the form back to the page its own. > > > > If JS is disabled, then I would simply have to refresh the page. > > If JS is enabled, then I could use <taconite> to place > messages on the > > page without refresh...if I'm understanding everything correctly. > > > > Rick > > >
