It seems less experienced developers may be linking to jQuery in ways that are not optimal and could cause problems down the road.
In this post, I’ll cover some reasons why you should always link to a specific version of jQuery and avoid using CDN references that link to ‘latest’ versions.
“Determining whether two variables are equivalent is one of the most important operations in programming.” That’s according to Nicholas Zakas in his book JavaScript for Web Developers.
In other words, throughout your scripts you’ll probably have lines comparing values. JavaScript beginners who try to adhere to best practices may be using triple-equals and not double-equals, but might not fully understand what the difference is or why it’s important to stick to triple-equals.
If you’re fairly inexperienced with JavaScript but you’ve used jQuery, then its likely you’ve used callback functions. But maybe you don’t fully understand how they work or how they’re implemented.
In this post, which is based on what I’ve learned about callback functions, I’ll try to enlighten you on this fairly common JavaScript technique. And maybe some of our JavaScript experts can chime in and let me know what I’ve omitted or oversimplified.
On a current project, I was trying to find a way to auto-resize a textarea according to some content that would be loaded in dynamically via Ajax. I didn’t know the height of the content and the textarea element doesn’t resize naturally like other HTML elements, so I needed to update the height of the element with JavaScript each time the content changed.
It seemed like a simple task. After doing a search to see what types of plugins and scripts were floating around to do this, the examples I found seemed a little overly complex. While most solutions seemed to incorporate some complex math calculations, I thought of a better way.
Earlier this month, Chris Coyier posted an article discussing a way to deal with the empty elements that are often needed when doing CSS3 animation.
Chris’s solution is interesting. He basically suggests (and I’m paraphrasing here) that we can give the empty elements semantic value by adding some text in each one to describe what each animated element does, or what mood it conveys. Then, the text in those empty elements can be moved off the page with CSS.
Some people got in a tizzy over the potential SEO penalties that could arise (which I kindly pointed out is probably not an issue) while others seemed to have a problem with Chris’s use of the word “semantic”.
Okay, admittedly, this is a pretty crazy and virtually useless tip. But it’s just one of those things that illustrates the flexibility of our craft and how sometimes solutions to problems can be found from some really outside-the-box thinking.
Back when I worked for a Toronto web design agency, we often had to update sites that were written in straight HTML, with no server-side programming at all. So every year, clients that owned such sites would ask us to update all the pages to display the current copyright year. That was pretty lame. Not exactly the kind of work we wanted to be doing.
So we wanted to create a way that the current year would be printed on each page automatically. But we didn’t want to include a JavaScript library, we didn’t want to use Ajax, and we wanted the year to come from the server, not the client.
At the beginning of this month I wrote a post accompanied by five demo pages that showed that CSS3 transitions could be triggered with a number of different events/states in CSS.
That alone should help you see how these types of simple animations work. But let’s take this a bit further.
CSS pseudo-classes and media queries (which I used in that other post to trigger the transitions) represent certain states for certain elements. These states occur after specific events on the page. So naturally, CSS3 transitions can also be fired using any JavaScript event. Let’s try a simple click event that toggles a class name.
I have a wide monitor and I like my windows to be maximised (I’m on Windows 7). I also like when Chrome is maximised, because I usually have about 7,623 tabs open at any given time, so the bigger the window, the better.
Thus, when I visit a page on Wikipedia, it’s unreadable — because Wikipedia’s layout is fluid and it fills the whole monitor. It normally looks like this:
Here’s something interesting I came across while reading Introducing HTML5 by Bruce Lawson and Remy Sharp, which I recently purchased.
In one of the early chapters, Bruce mentions that when tags are not nested properly, the resulting generated DOM will be seen differently in different browsers. Of course, when you “view source”, the code will be the same in all browsers. It’s when you inspect the page (or view the “generated source”) using developer tools that the results can differ.
After some testing, this is indeed the case. Here’s the code that I tested:
When coding JavaScript, I find myself using the for loop fairly often. Recently, when I coded, then re-coded these drop-down menus, during the re-code I ran my JavaScript/jQuery through JSLint using the option called “The Good Parts”.
I don’t know a whole lot about JSLint, but I figured that would be a pretty good way to ensure the code was efficient, relatively future-proof, and easy to maintain (i.e. it uses best practices).
The info JSLint provided, as well as other stuff I’ve read in the past, got me thinking about the simple JavaScript for loop and how it’s customarily written.
