Hi. Another way to think of it is:
1. Develop a site that works without JS 2. Work out ways to enhance each page using JS 3. step 2 may result in JS users not seeing whole classes of pages, but you have a fall back at any point. This discipline may result in a better application design and may result in a faster site and may give better options for performance enhancement. Or not. It's almost certain to be more accessible and to provide a better no-js experience. ---->Nathan > -----Original Message----- > From: jquery-en@googlegroups.com > [mailto:[EMAIL PROTECTED] On Behalf Of Rick Faircloth > Sent: Tuesday, April 24, 2007 8:18 PM > To: jquery-en@googlegroups.com > Subject: [jQuery] Re: Best way to determine if a user has > Javascript enabled? > > > 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 > > > > > >
