Browser Sniffing that Makes Sense
In web development there are many dos and don'ts, most of which are subjective. However, there are some practices that just make a lot of sense and some that do not. I do my best to implement those that make sense, because it's what I feel is the proper way to develop for the web.
One of the things that does not makes sense to me is to write a javascript that specifically checks for a certain browser and then react to it specifically. It's a short-sighted practice, really. The biggest problem a developer runs into is maintenance. Who is to say that the next version of a browser won't do something differently or behave worse? Who knows if someone using Safari will parade around in cognito fooling web sites into thinking it's Firefox? How many times will the developer have to update this script? Since there are so many unknowns, it's really just a poor practice to "sniff" for browsers.
Likewise, there has been much debate about where a hyper link should open. It's a popular move for web developers to make links to other sites (external links) open in new browser windows. Some people have come to expect this behavior, others scowl at it. The major argument against it is a usability argument: the user should have the option of opening new windows where the user wants, and not where the site wants. It's a compelling argument. So, I've decided to meet them halfway. I've written a javascript that generates a small icon next to each external link; clicking on the icon will open the link in a new window. The user now has the choice of where the link should open, and they needn't right-click the link or remember keyboard combinations to do it. Oh, and it is disabled for users of Microsoft Internet Explorer.
Most would find the decision to disable features for the most popular browser on the internet to be absurd, and most web developers would think that the practice of sniffing the browser is wrong. And they may be right, indeed, they are right. But this is an exception to the rule; it is not the rule itself. So why did I do it? Put simply: MSIE is unable to handle this particular feature. So why didn't I use "object detection" instead of "browser sniffing" to determine when the script should be run? I did! MSIE can handle all of the objects and methods individually, but it fails to handle them in concert. Sniffing the browser was a last resort.
It's not the first exception I've made, and it's likely not the last. I've used the popular sleight javascript to fool MSIE into rendering png files properly. I've also written scripts to use different style sheets for MSIE because it's unable to properly render the effects of certain CSS declarations (background-attachment: fixed, in particular).
In this scenario, I had decided that I want to offer visitors the option of where links open. With that decision made, I needed to choose how: Do I use a script that will exclude Internet Explorer users, or do I alter the page's content to pander to that browser's short-comings? I chose the former because altering the page's content to accommodate a browser makes less sense than calling it out in a script. It all falls back to what makes sense and what doesn't. It makes sense to offer a feature to a user who can use it, and it makes sense to ensure that the content of a web page is its most important feature. It makes no sense to alter the most important feature of a page, and it makes no sense to disable a feature for everyone just because some (most, in this case) people can't use it.
If you're using Internet Explorer and you want to see what you're missing, Get Firefox and check it out. This isn't the first site that offers advanced features to modern browsers, and it certainly won't be the last.
- under:
- about the site
- Posted on
- 2005-02-14
Comments:
Buuuuuut...
I definitely see the benefit of this script, but what might make a worth addition is to add a filter for designating exempt links.
Your sidebar now looks a bit crowded due to the added images next to the links. I can see the benefit of this technique used inline on the text but there should be a way to designate non-alterable links. Or do you?On topic though...
In some cases I wish some developers would sniff browsers. I tried to use a few online forms this past friday and all of them failed in one form or another. I can only assume that since they all failed in Safari, FireFox and MSIE Mac that there was some kind of Windows specific code in the form processing and tracking (they were all multi page forms).
In this case I would have appreciated a notice telling me that I was shit out of luck on a Mac instead of going through and wasting time on the forms.I'd really prefer that they get their shit together but in the absense of that I would have liked to have been told my browser wouldn't work.And
Your $_POST is showing.
Name
That is a sweet script.
Replies
Thanks, str!
Shawn, the $_POST was showing because I was debugging the slashes thing and I forgot to turn that off! That's pretty embarrassing! Thanks for letting me know!
In terms of having a filter, it will not crawl any link that is class="nocrawl ..." as long as nocrawl is in the beginning, it passes on that link. I will also not affect any link that has "window.open" in the onclick attribute.I agree that it does look a touch crowded over there on the sidebar, and I left it because I wanted to spend a little time with it to make sure it wasn't just me. I guess I thought that one would expect to see those icons if they were accustomed to reading this page. I could also change the script so it ignores all links in the sidebar. It's perhaps not as portable, but I think it would better suit this application.
added class nocrawl to sidebar links
They just look naked to me now.
This is going to be one of those things that eats away at me. Perhaps if they were aligned it would be better... I can do that with css.
shawn
I think I like the sidebar without them, but the sidebar deserves a bit of adornment with something. It is a bit naked even for a minimalist design.
I could actually make use of this in a variant - I'd like to see a version that instead of declaring "nocrawl ..." I'd like to delcare "crawl ..." and then have it rewrite those links, or give the script a config section in which you could define ".entry a, .comment a, .special, etc... " as links that are modified.
ndon't get me wrong, I dig the script.
not at all
That's easily workable as well. There's not a reason in the world the script couldn't be tweaked to meet that requirement.
It would get a little bigger, but it's possible. I'll play with it.
This article is closed to further commentary. But you can always contact me directly.