Tag Archives: javascript

Roger Black’s Advice for Young Designers

Posted on by
Reply

“On the skillset side, what you’ve got to do as a young person entering the field, is really equip yourself with some basic development skills. You have to be able to understand HTML and CSS. You have to know what JavaScript can do and what it can’t do. You don’t necessarily have to write cool JavaScript transitions, or even in CSS, but you’ve got to know what you can do in each. And you’ve got to be able to design so that if you have a more adept coder working with you, they know you know what you’re talking about.”
– Roger Black

How to use jQuery to open external links in a new window

Posted on by
1

A common request from clients is to open all external links on their website in a new browser window. (Leave aside for now whether this is a good idea or not, and just assume that you need to do it.) It’s easy enough to add target="_blank" to a link, but there are two problems. First, the target attribute is deprecated, so we don’t want to use it in our nice standards-compliant code. Secondly, on a large content-managed site, you might not have control over every link.

jQuery to the rescue! We can use $("a[href^=http://]") to select all links that start with http:// and then .attr("target","_blank"); to add the target attribute so they will open in a new window.

But now we have a new problem. In a content-managed system, the site will commonly render all links, even local ones, using a full URL. Now your jQuery is opening every link on the site in a new window. So we’ll write a few more lines of code to remove the target attribute from local links.

$(function() {
  $("a[href^=http://]").attr("target","_blank");
  $("a[href^=http://example.com/]").removeAttr("target");
  $("a[href^=http://www.example.com/]").removeAttr("target");
  $("a[href^=http://dev.example.com/]").removeAttr("target");
  $("a[href^=http://example.local/]").removeAttr("target");
  $("a[href*=.pdf]").attr("target","_blank");
});

As you can see from the example, I’ve removed it from any links that include the final domain name, both www and plain versions. I’ve also removed it from the dev site and from example.local, which might be a local installation of the site. You could add or remove any of these as needed, they’re just examples.

The last line is there because the client also wants all PDF files, whether on our site or elsewhere, to open in a new window, so we add the target attribute back on for any link that ends in .pdf.

How to use jQuery to target CSS at older browsers

Posted on by
1

On a recent project where I had to support Firefox 3.6, 3.0 and 2.0, I had to find a way to target a specific version of the browser due to differences in the rendering engine. It turns out the easiest way to do this is by using jQuery to detect the browser and add a class to the body tag.

// add a body class for firefox 2.0 only
if($.browser.mozilla && $.browser.version.substr(0,5)=="1.8.1") {
  $('body').addClass('ff2');
}

// add a body class for firefox 3.0 only
if($.browser.mozilla && $.browser.version.substr(0,5)=="1.9.0") {
  $('body').addClass('ff3');
}

The reason $.browser.version doesn’t appear to match is because for Firefox, jQuery actually detects the version of Gecko, the rendering engine. You can see which versions of Gecko line up to which versions of Firefox on this chart.

The dangers of browser detection have been covered in depth elsewhere, but in this case, I feel it’s acceptable because A) we’re detecting a browser version as well as a browser type, and B) we’re targeting old versions of the browser, whose usage in our stats are 5% or less (but for this particular client, we’re obligated to support them anyway). If someone has a better way, I’m open to it. In the meantime, this solved my problem nicely.

The Importance of Terminology

Posted on by
Reply

There are certain terms used in the web industry that most people think of as “industry-standard,” but are actually used in slightly different ways at different companies. For instance, I’ve run into several definitions for “alpha,” “beta,” “wireframe,” and “comp” at different shops I’ve worked at. Learning how a new company uses these terms isn’t that difficult, and the definitions are usually similar enough that it’s an easy adjustment.

I recently ran into a situation where my new manager’s definition of a term was different enough to radically change the situation. That term was “front-end.” Now, I think most people in our industry share a similar definition of front-end – it’s anything that the user sees through the browser, as opposed to back-end, which is anything that has to do with the server.

The problem arose from a gray area in our definitions with regard to javascript. In my mind, javascript can be used for both front-end and back-end work, depending on whether you’re using it for style and effects or more ajax-y stuff where you’re talking to the server. To my manager, however, since javascript is run in the browser, it’s front-end, no matter what you’re using it for.

Neither of us is wrong, the problem is that we were trying to describe two different things. I was describing intent and he was describing technology. I was arguing that javascript that talks to APIs on the server is back-end because of the work it’s doing, and he was arguing that it was front-end because it’s javascript.

In the end, I adapted the way I was speaking to clarify what I meant, and started talking about functionality vs. styling instead of front-end vs. back-end. Neither of us changed our minds, but at least we were talking about the same thing now, instead of using the same words, but meaning different things.