Scripting

A common UI pattern for a range slider is to allow the user to move the slider and display the value of it somewhere on the page, changing the displayed value as the user moves the slider.

I think the expected behaviour in such a case is that the value should display instantly, as the user is moving the slider, rather than the page waiting for the slider to finish moving before the displayed value is updated. I suppose there could be cases where you prefer a delay over instant results, but I think the expected behaviour is to display the results instantly.

As you’ll see in the videos below and in your own testing, the behaviour of the input event compared to the change event is not exactly the same in different browsers when applied to a range slider.

A trackback on one of my previous posts (yeah, trackbacks aren’t just for spam) alerted me to an interesting point brought up by a blogger named Matt Pass. In his post entitled Walnut, Meet jQuery Sledgehammer he politely explains why he feels it’s overkill to use jQuery in a simple tutorial post.

His main point is summarized in this quote: “Do you really need a 90k JavaScript library (and thats the minified version) to toggle the size of a menu?”

This article was first published on June 1, 2010 and has been updated to include a few extra features and an improved code base.

I’m a huge baseball fan, so earlier this year, just for a fun side project, I recreated the MLB.com Flash content switcher using jQuery and CSS3.

My goal with this project was to try to recreate the switcher without any extraneous images or other non-essential elements that tend to make stuff less maintainable.

My version uses CSS3’s border-radius, RGBA colors, opacity, and a small use of a gradient, and still looks acceptable in non-supportive browsers (although the jQuery is not as smooth in IE6 & IE7). Be sure to look at the real version on MLB.com for comparison; there are a few small differences, but mine is basically the same.

While I fully support the use of unobtrusive JavaScript in all projects, I do find it has one weakness: Connecting the HTML element with the code that acts upon it.

If you’ve been coding JavaScript since the dark ages of the web, you’ll know that JavaScript used to be commonly implemented in an obtrusive fashion that mixed markup with behaviour, which made your code messy, and added extra code to every individual page rather than putting it in an external reusable file.

Although the lack of cross-browser CSS selector support has caused a number of useful CSS selectors to go almost unnoticed, developers can still manipulate styles on their pages using some of these little-used selectors through jQuery.

Below I’ve prepared a simple table that describes a number of CSS selectors that are not cross-browser compatible, along with the jQuery syntax for each. The syntaxes are exactly the same as they would be in CSS, save for the jQuery wrapper (just remove $() and the quotes to get the CSS syntax), so using these selectors in jQuery will provide somewhat of a practice ground to prepare you for when they’re fully supported by all commonly-used browsers.

Every week this website gets about 700 unique visits from Google searches, mostly from people searching for solutions to problems with JavaScript and CSS. I’m flattered, and I hope I can continue to publish useful articles that will assist people and help with the exchange of ideas and techniques. One search phrase that leads surfers to my site pretty much every day is something along the lines of “getElementById explorer 7”.

If you type this phrase into Google, Impressive Webs currently comes in at around result 115. Not to mention the fact that the article that comes up doesn’t really address this issue directly. That’s not a very good ranking for that search phrase — yet somehow people are still finding one of my pages through that search.

It is obvious that developers — likely beginners — are having issues getting the proper results when utilizing the getElementById method available in JavaScript, particularly in Internet Explorer versions 6 and 7. And since the users seem to be searching through dozens of web pages looking for a solution to their particular problem, then obviously the pages discussing this JavaScript method are either too confusing or don’t specifically provide a practical solution.

Many aspects of JavaScript code development are taken for granted, and scope is really no different. Of course, in many cases where minimal code is required, variable scope (or function scope) is a non-issue. But if you’re planning to get into larger application development with JavaScript, then you need to understand at least the basics on scope in JavaScript.

Using some simple code examples, I’m going to run through the basics of scope and try to give beginning to intermediate JavaScript developers a better grasp of this very important concept.

Recently, a few blogs and tutorial sites have posted some really good articles on JavaScript tips and best practices, and I thought that was a good topic that could easily be expanded upon. So I put together a list of 10 fairly simple JavaScript tips and best practices of my own.

I tried to include stuff that was not mentioned in those other posts, but I’m sure there is a little bit of overlap. Keep in mind that these are brief tips and recommendations, so I don’t go into great detail about the reasons and such, but I may go into some of them in depth in future articles and tutorials.

In the meantime, please enjoy this list of tips, recommendations, and best practices for JavaScript coding.

Whether you use a JavaScript framework, or you are a purist and always resort to coding your client-side scripts from scratch, there are certain DOM syntaxes with which you should be at least a little bit familiar.

It’s true that a library like jQuery or MooTools will perform these methods for you, behind the scenes. In fact, if you rely on JS libraries for virtually all your JavaScript code, you’ll rarely have to use any of these methods directly.

But the reality is that, whether we develop as freelancers or work for a development firm, we may not always have the luxury of working on fresh projects where we can pretty much do what we want; we may have to maintain sites that rely on “obtrusive” scripting methods, or, for one reason or another, we may not be permitted to use certain libraries.

Whatever your situation, the following review of various practical DOM methods will hopefully serve to bolster your JavaScript knowledge and possibly help you more readily see practical solutions to various client-side issues.

Although the days of long and tedious code branches to target specific browsers in JavaScript are over, once in a while it’s still necessary to do some simple code branching and object detection to ensure that a certain piece of code is working properly on a user’s machine.

In this article, I’ll outine 7 areas where Internet Explorer and Firefox differ in JavaScript syntax.