The Return of the <noscript>

by keif on November 23, 2008

As a web developer, you’re constantly approached with pulling off zany schemes. In the words of Ian Malcolm:

Yeah, but your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.

Replace “scientists” with “designers” and you see the dilemma. They know you can pull off some funky effects in flash, so they opt to flash. However, flash is still not quite as easilly accessible and searchable that we all would like – and please, you can try to argue this point, but the majority of flash efforts I’ve seen tend to bypass the accessibility and searchability because it’s just easier to do the cool animations/sounds/effects/transparencies in flash (or flex) than it is to do in javascript.

Internet Explorer be damned!

The unholy bastion of a front-end developers existence tends to fall on IE6 – which is at 24% and dropping in its market share. This is always the what I end up falling on when talking to a fellow developer, and it usually goes like this:

Me: We could totally pull off that flash effect! We can do multiple animations using mootools, and it’d be indexable and still be applicable without javascript if we code it right!

Him: You mean those large transparent PNG images that would be sliding into place?

Me: Right! We could..totally… pull it off… in everything except IE6….

Him:

Me: …shit.

I mean, this isn’t too far from the truth, but the point is – accounting for IE6 is a bitch. I recently had to redo someone else’s code that used a PNG script I had rewrote because the alphapng filter was hitting multiple images on the page (dozens of images had a filter alpha opacity of 1). A quick audit of the code and reorganizing the javascript (ahhh… another blog post for the future, me thinks?) and suddenly IE6 was back in action, faster than ever!….not really, but it was at least usable.

So you see a lot of our ideas rely on javascript being utilized – or flash, which still will rely on javascript to be embedded – again, because of IE and other cross-browser issues – so we need to keep in mind that hankering feeling…

What if they don’t have javascript?

No doubt, some people with disabilities may still be able to use a site that utilizes javascript. It’s possible that they may have some ability to use a browser, but if they don’t turn off javascript, it may make it a more difficult browsing experience. Don’t forget, there are a plethora of mobile browsers that may/may not do javascript well, if at all.

This falls into a certain realm of uncertainty – and as I ran through a gamut of big e-tailers sites (American Eagle, Anthropologie, L.L. Bean, amongst others) L.L. Bean was the only one that I could purchase from (well, reach a point where they ask for payment).

The inherent problem of this, they rely on AJAX calls to do their server side form validation – so it’s possible that if you don’t have javascript, you could still enter bad data and find out your Christmas order is incorrect, maybe too late when they call to tell you why your credit card was declined, or that it was sent to a non-existant address.

Understandably – from a SEO perspective, they only need to index up to the product pages. If they’re smart, they don’t have any “highly relevant, high-traffic” content in their shopping cart pages or payment pages (it seems that those are generic, so it should be moot). The dilemma occurs in how they handle that percentage that is browsing without javascript. Maybe it’s a small percentage. Maybe it’s corporate users, or users from the large assortment of mobile devices. The point is – why should you neglect a sale just because they’re on webTV?

Enter the Dragon <noscript>

PPK on quirksmode wrote about the use of <noscript> and it’s use in helping point out (to the majority of browsers) that we can throw a little message stating that “hey – you need javascript.” I’ve looked at L.L. Bean’s source code, and they’re littered with <noscript>. But really, this shouldn’t be a concern as…
You shouldn’t be catering to a rich experience.

Really. You should be presenting a website that works – period. I should be able to hit it in lynx. In Safari. My iPhone. His blackberry. IE6. IE5. We shouldn’t be relying on javascript to pull off effects and basic, fundamental functionality. Javascript is an enhancement, not a requirement. If it’s required, you’ve failed.

I’m not saying I’ve got all the answers – but I do know that if we want to code in a way that no matter what crap happens in the near future, we need to focus on the basics and get them executed as cleanly, and simply as possible.

There may be a point that we finally say – okay, you’ll need javascript to get these cool “up to the minute” updates, live editing, in place context editing, etc. But that’s really at a point when you have to decide – who is this website for? Who am I catering to? Why do I care if the degraded expeience means things pop instead of fade in? More than likely, this same day will be when you say…

Shit, a fraction of a percent of people visit my site on IE6. I might want to tell them to upgrade.

  • George Walters

    Keith,

    I completely agree with you on this one with one caveat. There are valid uses of the noscript tag but most sites definitely use this tag for purposes it should not be used for. The most obvious use of this tag would be for tracking analytic data. Even if you cannot get all of the good details you can by using JavaScript, you at least get a small portion of information to know a page hit had occurred by use of the noscript tag and, in most cases, a simple image call.

  • http://ikeif.net keif

    I’m inclined to agree – the

Previous post:

Next post: