Turn off auto-logon to voice-mail AOP Survey
Feb 23

JavaScript Enabled

HTML, JavaScript, Tech, UI / UX Add comments

I remember, back in the day, having to write a lot of <noscript> areas, and making sure that the application that we are working on works perfectly for those that choose to turn off JavaScript in their browser (or don’t have a JavaScript enabled one).

Has the tide turned now? Of course, you wouldn’t want to abuse JavaScript just for the hell of it, and when you can give a ‘backup’ to non-enabled peeps it should be done.

But, with the likes of Google Maps, maybe we are seeing the start of the JS/dHTML revolution.

Enable JavaScript to see this site. Enable JavaScript else you will have a poor experience.

5 Responses to “JavaScript Enabled”

  1. Todd Huss Says:

    I work for a pretty large website and our QA dept no longer tests our site with javascript disabled. The percentage of our users with javascript turned off is so small that it’s no longer worth the additional cost required to test new functionality with javascript disabled.

    I’m sure there are some diehards who turn off cookies and javascript and want every site to work in lynx but it’s my feeling that the economics are not compelling enough for a small to medium sized subscription based website to justify the cost of testing that functionality in those configurations.

    From a programmer/web designer perspective on the other hand I think it makes sense to support non-javascript and lynx users because it promotes good design/programming practices such as separation of content/presentation (html/css) and server side validation with optional client side validation.

  2. Todd Huss Says:

    I work for a pretty large website and our QA dept no longer tests our site with javascript disabled. The percentage of our users with javascript turned off is so small that it’s no longer worth the additional cost required to test new functionality with javascript disabled.

    I’m sure there are some diehards who turn off cookies and javascript and want every site to work in lynx but it’s my feeling that the economics are not compelling enough for a small to medium sized subscription based website to justify the cost of testing that functionality in those configurations.

    From a programmer/web designer perspective on the other hand I think it makes sense to support non-javascript and lynx users because it promotes good design/programming practices such as separation of content/presentation (html/css) and server side validation with optional client side validation.

  3. Jonny Axelsson Says:

    While it can be hard to have a fallback for a JavaScript application, where the whole point is the application, for other pages JS should work well if you do your content/presentation/behaviours right (in HTML/CSS/JS respectively). If for some reason the style sheet is unavailable or the browser is inferiour the page will be ugly but the content is still there. Similarly if JS is off you will lose some behaviours and conveniences (like client-side validation to avoid roundtrips to server) but the page will still be there.

    However ‘noscript’ is mostly gone. It may have made sense at the time of DHTML and document.write(), but in this day of DOM it is just in the way.

    Working with browsing on less common devices (phones, TVs, voice) JavaScript is rarely the problem. Having wrong assumptions on behalf of the user is.

  4. Jonny Axelsson Says:

    While it can be hard to have a fallback for a JavaScript application, where the whole point is the application, for other pages JS should work well if you do your content/presentation/behaviours right (in HTML/CSS/JS respectively). If for some reason the style sheet is unavailable or the browser is inferiour the page will be ugly but the content is still there. Similarly if JS is off you will lose some behaviours and conveniences (like client-side validation to avoid roundtrips to server) but the page will still be there.

    However ‘noscript’ is mostly gone. It may have made sense at the time of DHTML and document.write(), but in this day of DOM it is just in the way.

    Working with browsing on less common devices (phones, TVs, voice) JavaScript is rarely the problem. Having wrong assumptions on behalf of the user is.

  5. jim Says:

    alert(”Welcome to my site”)

    <a target=”_blank” JavaScript Free Code

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'cricket'

Loading...