Six JavaScript features we do not need any longer
Modern JavaScript can get rid of some bad practices from the past. Christian Heilmann lists Six JavaScript features we do not need any longer. Are you still using document.write and href="javascript:"? Time to stop.
- Previous post: Customising custom corners and borders
- Next post: Accessibility vs BlindSurfer
Information, sponsorship, and externals
About the author
Roger Johansson is a Swedish web professional specialising in web standards, accessibility, and usability. More about me and this site.
Latest articles
- Validation statistics from Nikita the Spider Comments off
- An analysis of the sites crawled by the bulk validation tool Nikita the Spider during March 2008.
- Authentic Jobs API and Affiliates program Comments off
- The Authentic Jobs job listing service now has a public API and an affiliate program.
- What does Acid3 mean to you and me? Comments off
- Opera and Apple have announced that their web browsers pass the Acid3 Browser Test, but how will that help web designers and developers?
- Designing Web Navigation (Book review) Comments off
- Learn the fundamentals of navigation design and design better navigation systems for large and small sites as well as for web based applications.
- DOMAssistant bundle for TextMate Comments off
- To save keystrokes and speed up development I have created a DOMAssistant bundle for TextMate.
- First impressions of Internet Explorer 8 Beta 1 Comments off
- My impressions after trying out Internet Explorer 8 Beta 1 for a couple of days.
Comments
There are times when this stuff is still needed, mostly when maintaining existing code.
I recently converted a web application to use DHTML messaging (pseudo pop-ups) to communicate with the user, this was to replace ugly and illegible Javascript alert() statements.
Personally, I would have loved to re-write this entire application from scratch, making nice user-friendly error messages and everything, but that was quite out of the project scope.
It's easy enough to sit there and accuse web developers of writing bad mark-up or not meeting the current web standards and such, but is that reality? How do you justify to your manager the need to spend X more hours more than expected on a project just because "the markup is bad"?
The percentage of web developers working in the professional sector (by that I mean large companies) that actually care about web standards, usability and accessibility are extremely low (at least from my experience) and therefore these concepts are not always readily accepted.
What are your thoughts on this?
Justin,
I myself work in a company like that and I am very much aware of time and budget constraints. Rather than complaining about that and seeing it as a given, I see it as an opportunity for us to show at least in our freetime projects that you can work differently. Retrofitting is always a problem; it doesn't matter if it is a web site or a house. I don't see plumbing companies advertising leaky pipes and dripping faucets as a given, and adding a new rubber ring as the solution so why should we?
It is hard to get business buy-in, all they care about is money and the deadline. However, if you can prove that an old application breaks in newer browsers and fails in accessibility tests (although automated tests are not a good measurement for accessibility) you might get a chance to re-code the app. It works on the backend, companies dish out a lot of money when you mention .NET instead of their old frameworks.
Roger,
While I agree with you about
document.write(),href="javascript:"on the other hand, is usefull. While I don't advocate its use, it's that that functionallity which allows bookmarklets to work and alows you to type JavaScript into the location field.Thanks for your comments Chris. I should clarify that I am certainly not complaining, just stating a fact when working in a bottom dollar deadline environment.
I bet when rubber rings first came out they were all the rage with plumbers ;)
Another point to consider is the team environment, where I am but one of many people maintaining a large website. Say you have 20 or so stand-alone mini-applications running on a primary website, you cannot just go in there and convert everything you touch to standards-based, accessibility minded design...consistency and ease of maintainability need to be respected.
Justin, Web standards and clean code awareness is is certainly not counterproductive in teams. My job is to define the coding guidelines in our company (20 developers, distributed in 5 locations around the globe), and so far it made development a lot smoother. Mind you, I am fully aware that systems in place cannot or should not be changed easily (never change a running system), but this is a problem of maintenance and redesign, not of primary design. They are two different things. Much like web applications follow different rules than web sites. I will follow up on that. It is once again the measuring of following standards or following them down a cliff.
Mordechai,
that is javascript: though, not href="javascript: :-) Things that work as a bookmarklet or in the JS debug console don't necessarily work in HTML documents. I can also browse my harddrive in MSIE, but it'll be scary if everyone on the web could.
brilliant post!
We have been saying for years now that application developers need to wake up and stop using insecure, and potentially, dangerous snippets of code.
document.cookie document.write href="javascript found on a sep server"
Those are all valid attack methods and are used ALL the time when im testing for insecure apps
Daniel http://owasp.org
Chris, I'm not saying designing with standards is counterproductive in teams...I wholeheartedly believe in web standards and am a huge advocate of them.
I am saying that when the existing developers in a company primarily use the built-in WYSIWYG editor of our IDE, which generates table-based layouts of course. Then I come along and upgrade the various apps I have worked on to CSS-based layouts sans tables, problems arise when another developer has to work with your code.
That's not to say it cannot be done, but it does take time. You've got to ween these folks off of tables and non-standards based development, going cold turkey would kill 'em ;)
For all it's worth, you can just about add ".innerHTML" to the list as well. You really should use the DOM for stuff like that, even thouh it's an order of magnitude slower.
I couldn't agree more with not using document.write, except I haven't found a way of dynamicaly adding a script element to a page. And when you are having to deal with external ad systems you need to be able to do this.
It sucks and if anyone can detail a crossbrowser method for adding (and parsing) a new script element to a page please go ahead.
Simon, I wondered about that, too. You can generate script elements like any other elements, and I think it could be ammended for the google ads. However the idea of these trackers is that when JS is not available, then they write out a one pixel image linked to a cgi instead, and that is where the separation fails.
Chris,
I realize that there are differences in which objects are exposed, but the basic functionality is the same: JavaScript instead of a URI.
Simon,
It's simple; you either you use a lambda function or the
Function()constructor. The syntax (examples taken from David Flanagan's JavaScript: The Definitive Guide, 4th Edition.) is:or
In both cases you now have a function called
square().Mordechai, Closures are wonderful but not what I'm talking about here. What we want to be able to do is import a script dynamicaly.
One area this is done is with adverts, the current ad system I'm using at work (phpAdsNew) uses dynamicaly created scripts to load the ads. The problem with using the DOM to add a script element Chris is that certain browsers (I think it's Safari) will add the script but not parse it. Making the whole thing a bit pointless.
Leaving document.write the only godforsaken option.
Mordechai, How does that solve the problem of dynamically including external scripts?
In the ad world, one would typically include a little bit of Javascript from an advertiser and that Javascript in turn would dynamically (through document.write) write out more script tags to the page, there by including any Javascript needed. I'm not getting the connection between creating new functions and dynamically including external scripts.
I didn't realize we were discussing loading external scripts. In that case, as is the case with AdSense, where Google uses
document.write(), just hold your nose and load it with an object tag. Roger had a post about it some time ago about it.Ok, I'm going to have to show my ignorance here and ask the question -- what do you do in place of the href="javascript(..."?
I'm thinking of the situation where I want to run a javascript just to get a user to confirm an action before the action happens. For example, if a user is reviewing a record in a database in his/her browser, and I want to give the user the option to delete the record -- but I want to use a confirm() in javascript BEFORE I go to the link that will do the deletion -- how do I do it?
Bart, You give the link an HREF that will actually delete the record (without Javascript) and then use the DOM to add some onclick behavior to give the pop-up warning before the actual delete occurs.
Bart,
To add to what Justin said, if the click event handler (onclick) determins that the link shouldn't be followed (i.e., stay on current page), it needs to return false. Otherwise it should return true to leave the page by following the link's href.
Justin: Maintaining existing code can be an issue, but if we don't push forward and aim high we'll never get anywhere. Your point about maintainability within an organisation is also (unfortunately ;-)) valid. With most of the people working in web development not actually being interested in what they do for a living and certainly not in evolving their skills, that can be a problem.
Mordechai: Yes, I would agree that bookmarklets are an exception. Not that I use them a lot.
That post about AdSense you're thinking of is Content negotiation, AdSense, and comments. Ugly, but it works.
As I wrote over at quirksmode.org:
When it comes to ad content, wouldn't it be possible for ad providers to tell the web developer that's going to incorporate their ads to set a string variable with the ID of the element where they'd like the ad content to be added (the name of the variable should be specified by the ad provider)?
Then the ad provider's script could be proper DOM scripting and instead use appendChild to insert their ads to the element identified through above mentioned variable.
That would be great Robert, but it sounds like wishful thinking. Advertisers do not care about this stuff and their developers are not typically the most forward thinking individuals (from my experience anyway, not trying to offend) in the web developer sphere.
I use <noscript> so that on "automatic go-to dropdowns" people without javascript still have a button to press. Is that so bad?
Justin,
Yes, you're probably right.
Maybe I'm just dreaming, but I really do hope it'll happen.
Peter Bengtsson,
It's not so bad, but an alternative approach might be to first include the button in the HTML code, and then use unobtrusive JavaScript to hide/remove it for those who have JavaScript enabled.
Robert,
The problem is that you want to host their ads more than they want to advertise on your site. Sure, they want to advertise on sites, but in most cases, on any one site they don't care much either way.
Peter,
The problems with "automatic go-to dropdowns" aside, it's a good example of the proper use of a noscript tag. An alternate way though, would be to have, for example,
class="noscript"and have JavaScript set on page load:It should be noted that the noscript tag has a major flaw: if the JavaScript was striped by a firewall, the browser won't display the noscript because JavaScript in enabled, and won't run the script because it didn't receive it.
Peter: Yes, automatic submit dropdowns are bad for keyboard users since some browsers (IE/Win, Opera, maybe others) trigger the onchange event as soon as you move focus from one option to the next, meaning you can never get further than the second option.
Including a submit button with noscript does not help in this case since JavaScript is enabled.
Mordechai (what a cool name!),
You're probably right.
I just wish for once that major players (ad providers etc) would take some initiative to deliver good and valid code together with the business factor of delivering ads to many web sites.
Sorry, comments are closed for this post.