I am going to play a devil's advocate for a moment. I have been always wondering why browser detection (as opposed to feature detection) is considered to be a flat out as a bad practise. If I test a certain version of certain browser and confirm that, that certain functionality behaves is in some predictable way then it seems OK to decide to do special case it. The reasoning is that it will be in future foolproof, because this partial browser version is not going to change. On the other hand, if I detect that a DOM element has a function X, it does not necessarily mean that:
This function works the same way in all browsers, and
More crucially, it will work the same way even in all future browsers.
I just peeked into the jQuery source and they do feature detection by inserting a carefully constructed snippet of HTML into DOM and then they check it for certain features. It’s a sensible and solid way, but i would say that it would be a bit too heavy if i just did something like this in my little piece of personal JavaScript (without jQuery). They also have the advantage of practically infinite QA resources. On the other hand, what you often see people doing is that they check for the existence of function X, and then based on this, they assume the function will behave certain way in all browsers which have this function.
I’m not saying anything in the sense that feature detection is not a good thing (if used correctly), but I wonder why browser detection is usually immediately dismissed even if it sounds logical. I wonder whether it is another trendy thing to say.
It seems to me browser detection has been widely frowned upon since this post by Resig a couple of years ago. Resig's comments however were specific to libraries/framework code, i.e. code that will be consumed by other [domain-specific] applications/sites.
I think feature detection is without question a good fit for libraries/frameworks. For domain-specific applications however I'm not so sure browser detection is that bad. It's suitable for working around known browser characteristics that are difficult to feature-detect, or for browsers that have bugs in their implementation of the feature itself. Times that browser detection is appropriate:
sites/applications that are not cross-browser and need to show a warning/dialog/DifferentPage tailoring to that client's browser. This is common in legacy applications.
Banks or private sites with strict policies on what browsers and versions are supported (to avoid known security exploits that may compromise user's data)
micro-optimizations: occasionally one browser is ridiculously faster than the others when performing some operation a certain way. It can be advantageous depending on your user base to branch on that particular browser/version.
Lack of png transparency in IE6
many display/rendering issues (read: IE css support) that are only witnessed in specific browser versions and you don't actually know what feature to test for.
That said, there are some major pitfalls (probably committed by most of us) to avoid when doing browser detection.
Here's a good article explaining how feature detection is superior in so many ways to browser sniffing.
The truth is that sniffing is extremely fragile. It's fragile in theory, as it relies on an arbitrary userAgent string and then practically maps that string to a certain behavior. It's also fragile in practice, as time has shown. Testing every major and minor version of dozens of browsers and trying to parse build numbers of some of those versions is not practical at all; Testing certain behavior for quirks, on the other hand, is much more robust. Feature tests, for example, often catch bugs and inconsistencies that browser vendors incidentally copy from each other.
From my own experience, fixing Prototype.js in IE8, I know that 90% of the problems could have been avoided if we didn't sniff in the first place.
While fixing Prototype.js I discovered that some of the features that need to be tested are actually very common among JS libraries, so I made a little collection of common feature tests for anyone willing to get rid of sniffing.
The ideal solution would be to have a combination of both feature and browser detection. The former falls down because of the points you mentioned and the latter because sometimes browsers publish false information to "make things work" just so.
Mozilla has a great Browser Detection Primer that might be helpful to you as well.
From wikipedia
"At various points in its history, use of the Web has been dominated by one browser to the extent that many websites are designed to work only with that particular browser, rather than according to standards from bodies such as the W3C and IETF. Such sites often include "browser sniffing" code, which alters the information sent out depending on the User-Agent string received. This can mean that less popular browsers are not sent complex content, even though they might be able to deal with it correctly, or in extreme cases refused all content. Thus various browsers "cloak" or "spoof" this string, in order to identify themselves as something else to such detection code; often, the browser's real identity is then included later in the string."
Related
I was seeing the W3C Document Object Model and excited that different programming languages have to implement their interfaces accordingly. Like other languages, JavaScript also maintains the DOM.
So I'm curious to know about the following questions:
Which versions of javascript implements dom level 1, 2,3 and so
forth.
Are they all implemented in javascript?
Are they implemented by javascript or implemented by ECMAScript and
followed by JavaScript?
And what are the IDL definitions described in W3C DOM: Are they
needed to understand for javascript developers or is that the symbol
of implementation by HTML?
The pedantic answer is "none".
There is no formal mapping of JS iteration to DOM-specification.
In general, JS-versioning has all but been abandoned (save major overhauls), though can be seen as signposts of when you might start to consider feature-checking.
This is because...
Not really, no.
That is to say, yes, the APIs which you will use to interface with the HTML DOM are all implemented in JavaScript...
However, no browser has a stable, feature-complete implementation of either
JS or HTML DOM[1-4].
Because both specs are so large, and ever-changing, different vendors have prioritized different features at different times, leading to patches of incompatibility.
To further this actual answer, the JS spec says nothing of DOM or BOM ("Browser ...") APIs.
This is the reason #1 must be a "No", as different DOM/BOM combinations on different JS implementations leads to the fundamental inability to say "All JS1.7-compliant browsers are DOM3 compliant."
The truth is that no browser is wholly compliant with either spec, and neither spec is the latest, anyway. As for technical-implementation (the code behind the API), there are no rules, so long as the behaviour is well-defined. Some browsers defer to C/C++ for core JS/DOM/BOM functionality, while older IE browsers had an ActiveX layer between the browser and JS DOM access (making touching elements for any reason arbitrarily expensive).
Here's the rub.
Most people would consider them to be different things.
Most people would think "JS is the thing that you use in the browser, to do your scripting.".
Really, ECMAScript and JavaScript are the same thing, and "JavaScript" is a Sun (now Oracle) trademark... how none of us are getting sued is a mystery.
JS/ECMAS knows nothing of DOM or BOM, and it's up to the vendors to include DOM-access in their browser (on a per-feature, rather than per-version basis). It should also be noted that while VendorA might implement a feature from the spec, and VendorB might omit it, VendorC might have an off-standard implementation of it, and also implement a similar but completely out-of-spec feature, as well.
Don't worry about the DOM implementation specifics.
As a JS-dev, you won't need to know or care what a Java implementation of an HTML node might look like.
Even with WebIDL, and moving away from the old-world Java-centric view, as far as day-to-day usage of JS as a language, the DOM-node interfaces are as dry as toast, unbuttered, face-down in a sand dune, unless it's really what you're into.
Even then, it's more for people who make the browsers, and not the people who make things which run in them.
These aren't all of the answers. And while I've tried to remain subjective, I'm sure there's a little objectivism in there, as they aren't wholly cut and dry. I've tried to be, at least, factual.
From an engineering perspective, being careful about how and when you use the DOM in client-side JS is important -- both for making code portable and for allowing each language in the client-side stack to have access to the HTML in question, without doing somersaults in JS, to accommodate, because you built your whole site using DOM construction in JS.
From a pragmatic standpoint, rather than trying to match features to versions, use sites like http://caniuse.com to match features to browser versions. It's much more productive.
And have fun.
I have a html page that has more than one head and body. The first body says "loading" before the rest of the head with javascript and the other body loads. The javascript then deletes the first body before showing the whole document.
My friend told me this is not standards compliant. But the page works fine on Internet Explorer and in Firefox too.
Is it actually important to be standards compliant if the page works fine?
~~ edit ~~
thanks for all the help, i'll make it standards compliant like suggested.
I recommend being standards compliant for the following reasons:
If a page is standards compliant, your browser doesn't have to do unspeakable voodoo to try and get your page to render. People like faster page loads
Which also includes Google Bot. If Google Bot doesn't have to tear its robotic hair out it becomes happier. While there are other things that need to be taken into consideration, it's good to have this base covered
When you're dealing with DOM manipulation through JavaScript, non compliant html/xhtml sometimes produces weird results that lead to an annoying amount of time spent debugging
Think of it like duct-taping your broken car muffler. Sure it works now, but for how long? Web standards are there for a reason, and browsers follow them the best they can. If you follow the standards, then you can be assured that your site will work for quite a while. If not, you might be relying on some bug or quirk in the browser, which might get fixed and leave your site looking like garbage.
Follow the standards; you won't regret it.
Depends on what you're concerned with.
If your site works on the browsers you are concerned with then hey, it works!
Still, being standards compliant has some benefits:
Future Proof: Your site will work several years from now.
Accessibility: New browsers and browser updates probably aren't going to break your site (without warning!)
SEO: Facilitating search engine spiders as they index your site will allow more pages/content to be added to search results.
Feel good about yourself: Sticking to standards makes me feel warm inside. :)
Still its up to you. What's important to you?
It's important. If you designed your page to be standards compliant, then it's possible, or even likely, that your pages will still work in browsers and devices 20 years from now. Otherwise, it's more and more likely that they won't. Make it future proof. A second reason, is a non-standards-compliant code may cause problems in areas you hadn't considered. For example, being standards compliant may in one go, make it possible to: print the documents without modification, have it accessible to users with a range of disabilities and so on. In fact, many websites designed with standards compliance in mind were never intended for mobile devices, but because they were designed to be standards compliant, when devices were made to show standards compliant websites, those old sites work without any changes.
Standards compliance are a way to "guarantee" your site is going to be displayed the way you intended in every browser that follows the mentioned standards (ever heard of Internet Explorer 6, 7, not the case).
Mind you that some people (visually impaired for example) use special browsers that rely on standards compliance. Please have them in consideration, standards are needed especially in that case.
It depends of your requirements. You should ask yourself if compliance is important for your current project. But it's not hard to conceive situations where it really just doesn't matter. So, if your realize your current project wouldn't benefit in anyway undergoing modifications to make it standard compliant, just don't waste your time. But if you do see some benefits the compliance should bring, even though you should still evaluate whether the work needed really worths the benefits. It' best if you are not dogmatic about these subjects.
More often than not, if I come up with a solution that is not standards compliment, my solution is almost always hard to understand for others, buggy and based on my limited knowledge of web development. Then in shame but with hope, I drop my solution and continue searching for a better one.
Post Sniffing Rules
Although browser sniffing used to be quite popular, it's now gone out of fashion (for good reasons) and has been deprecated (if not dropped) by popular libraries such as jquery.
The better way is to do feature detection.
Exception To The New Rule
However, there are times when you might be targeting (for whatever reason) a specific browser. iOS safari is a good example, as are other mobile browsers, as the mobile platform has different ui concerns.
My Particular Purpose
For my purposes, I want to target IE specifically in order to alert the user to use another browser.
You may not agree with what I want to do, but please disregard that in your answer.
With this in mind, what the best, most reliable way to detect browser versions, more specifically any IE version, and iOS Safari too.
Is it safe to still use jquery.browser?
Use Conditional Comments. The are a perfect fit for what you're after.
Also, it's all very well and good to tell people to use feature detection but in the real world, when you have 3 days to update the browser detection on your company's website you can't go and re-write all the Javascript just to take advantage of this, so I say, heck yes, use browser sniffing, because sometimes you don't have a choice.
I've recently seen some information about avoiding coding to specific browsers an instead using feature/bug detection. It seems that John Resig, the creator of jQuery is a big fan of feature/bug detection (he has an excellent talk that includes a discussion of this on YUI Theater). I'm curious if people are finding that this approach makes sense in practice? What if the bug no longer exists in the current version of the browser (It's an IE6 problem but not 7 or 8)?
Object detection's greatest strength is that you only use the objects and features that are available to you by the client's browser. In other words given the following code:
if (document.getFoo) {
// always put getFoo in here
} else {
// browsers who don't support getFoo go here
}
allows you to cleanly separate out the browsers without naming names. The reason this is cool is because as long as a browser supports getFoo you don't have to worry which one it is. This means that you may actually support browsers you have never heard of. If you target user agent strings find the browser then you only can support the browsers you know.
Also if a browser that previously did not support getFoo gets with the program and releases a new version that does, you don't have to change your code at all to allow the new browser to take advantage of the better code.
What if the bug no longer exists in the current version of the browser (It's an IE6 problem but not 7 or 8)?
That's the whole point of feature/bug detection. If the browser updates its features or fixes a bug, then the feature/bug detecting code is already up to date. If you're doing browser sniffing on the other hand, you have to change your code every time the capabilities of a browser changes.
Version and User Agent parsing remind me of stereotyping or racial profiling. Object detection is the way to go in my opinion. The book jQuery in Action does a good job of pointing out the fine details of why.
Well, if it is a problem in IE 6, but not IE 7 or IE 8 then the feature/bug detection mechanism will mark it as not a problem and use the appropriate functions.
It makes sense in practice, browser sniffing causes many issues, what if you don't update your signatures in time for some new browser that is released? You are now locking out potential customers, and visitors because you believe that their browser is unable to support something that indeed it can.
So yes, it makes sense, and your second question is moot because of the fact that it does the detection in the first place, if it is no longer a bug everything will work as expected without the work around that is in place if the bug was there!
When coding new javascript heavy websites, which order or web browser do you code for?
I can see these possible orders, but I am not sure which I like best:
Code for one first and get it working well, then start testing with other and fix errors as I go.
This will allow for the most rapid development (with Firefox at least) but I've learned from experience that debugging IE with so much going on at once can be a pain!
Code for both at the same time. In other words, for each new feature, ensure it works with both browsers before moving on.
This seems like it will actually take more time, so maybe do several features in Firefox then move to IE to patch them up.
What do you all do?
Edit 1: To respond to a couple of answers here.:
#JQuery usage: For some reason I was not expecting this kind of a response, however, now that this seems to be the overwhelming accepted answer, I guess I should tell everyone a few more things about the specifics of my app. This is actually the DynWeb that I started another question for, and as I'm developing, a lot of the important code seems to require that I use document.whatever() instead of any JQuery or Prototype functions that I could find. Specifically, when dynamically importing changing CSS, I have to use some similar to:
var cssid = document.all ? 'rules' : 'cssRules'; //found this to take care of IE and Firefox
document.styleSheets[sheetIndex][cssid][cssRule].style[element] = value;
And I expect that I will have to continue to use this kind of raw coding currently unsupported by either JQuery or Prototype in the future. So while I would normally accept JQuery as an answer, I cannot as it is not a solution for this particular webapp.
#Wedge and bigmattyh: As the webapp is supposed to build other webapps, part of the criteria is that anything it builds look and work functionally the same in whatever browsers I support (right now I'm thinking Firefox and IE7/8 atm, maybe more later on). So as this is a more interesting (and much more complicated) problem; are there any sites, references, or insights you may have for specific trouble areas (css entities, specific javascript pitfalls and differences, etc.) and how to avoid them? I'm almost certain that I am going to have to have some sort of isIE variable and simply perform different actions based on that, but I would like to avoid it as much as possible.
Thanks for your input so far! I will keep this open for the rest of the day to see what others may have to say, and will accept an answer sometime tonight.
This is sort of a trick question. In my opinion you need to work in this order:
1: Conform to Standards
This gets you closest to working in every browser without having to test against every browser. Additionally, you gain the huge benefit that your site should work with any new browser that comes along (Chrome is a good example) so long as it's well made and standards compliant. It also makes it easier to tweak your site to work in specific browsers because the way that the popular browsers deviate from standards compliance is well known.
2: Support the Most Used Browsers (For Your Site)
Note carefully the distinction between the breakdown of browser usage on the internet vs. browser usage on your site. On the internet as a whole IE is the most popular browser with Firefox a close second and Safari, Opera, and Chrome taking up most of the remainder. However, the demographics of your site's visitors can turn these numbers upside down. On sites that cater to a more technically savvy crowd it's common for firefox to be the dominant browser with IE in the distinct minority.
3: Support Other Browsers as Needed
You need to be very explicit about the fact that browser compatibility is an operating cost for your site, and you need to decide where you draw the line. Depending on your site's purpose and business model it may be fine to support only the most popular browsers, or even a subset of them. On the other hand, it may be a vital business concern to support everything under the Sun, including IE5. It's ok to make a conscious decision to not fully support every browser if you think the cost/benefit ratio is too high to justify it. Indeed, many of the most popular sites on the internet do not work well in older and niche browsers. Though you should strive to make your site still functional in the least popular browsers, even if there are serious appearance or usability problems.
FireFox first then IE. If it works in FireFox, it is more likely to work in the other non-IE browsers, IE sometimes requires special magic.
Use jQuery and do them all at once.
Code for Firefox first, but test with IE as you go. This lets you fix any quirks as they arise. It's important to test with Firefox first because it's more standards-compliant. You should learn how to write HTML/JS the right way. Fix things as you go to get a better idea of how IE renders things differently.
You may not need to test with IE for every feature you add, but test often enough so that issues don't pile on top of each other. Repeat with other browsers/browser versions to get the overall picture of your site's compatibility.
I always test on both FireFox and IE7. And then fix and botch for IE6 and other browsers.
If it works on FireFox it will almost certainly work on Opera, Safari, Chrome, etc with only a few minor tweaks
Same thing goes for IE7 and IE6, If it works on 7 it won't take too much to get a reasonable rendering on IE6
I normally use Firefox as my main development browser because of its superior debugging tools and I code very incrementally, write a few lines and test several times an hour. But at least every hour or two I make sure that what I am doing will work on IE7 as well.
As soon as I get into an area where IE7 causes problems I start to rethink the way I'm doing it, In my experience fixes tend to multiply and get out of control very rapidly. It's often better to accept defeat and move on with a simpler design.
I've been bitten too often in the past by developing something that works perfectly on FireFox only to find that it needs a complete rethink to get it working in IE7 as well - and vice versa. It can take days to sort out and can be very disheartening.
are there any sites, references, or insights you may have for specific trouble areas (css entities, specific javascript pitfalls and differences, etc.) and how to avoid them?
A good resource for this is quirksmode. The author (Peter-Paul Koch, or PPK) has lots of compatibility tables for CSS and JavaScript support. He also has articles dealing with specific issues and how to write cross-browser code.
They don't deal with JavaScript, but Position is Everything is a valuable resource for CSS issues (mostly IE6).
Like others have mentioned, I just use jQuery to avoid these issues. If there's something it doesn't support, it's pretty easy to write custom plugins.
I do IE first, and then add Firefox.
My experience is that once it works in IE, it continues to work in IE, and the question why something not work in Firefox is usually easy to answer.
If you have to code for IE6, the most frustrating part is coding the CSS and HTML. jQuery and other libraries make it easier to code the behavior -- but you generally can't get around the fact that IE6 has so many weird rendering issues that you'll be frequently banging your head on the keys trying to make it do what Firefox, Safari and Opera do right the first time.
So Javascript isn't the hardest part. Dealing with HTML and CSS is. In my experience, if you're working with any reasonably interesting design, you're better off coding for IE first and then testing on Firefox. You probably won't have to make many adjustments if you do IE first, but you definitely will have to spend some time refitting your code to make IE do what you wanted it to, if you only code in Firefox. It's like repeating yourself. It's a pain. So it's better to get it done first so you don't end up wasting too much time.
I code for both, and write (or use) abstraction layers where there are differences between the browsers. IMHO, it's much easier in the long run to be continuously testing in a cross-platform setting. This keeps me from doing something that's tuned to one browser that simply won't work well in the other: I find out very early in the development cycle what the compatibility issues will be.
When I'm making a small change, I might first do it for one browser, but before I consider that feature or change to be complete, it must work at least in firefox and IE.
To minimize your issues now, and downstream, work with the worst to the best, in size of their existence.
Edit: If you can do the below keeping in mind of "how could this degrade gracefully down to ie6 via modified jQuery elements, etc... it might be a bit clearer.."
So, today based on Market Share, it is:
1) IE 6
2) IE 7
3) Firefox
4) Safari..etc.
Coincidentally enough, the major issues with browsers occur in that order too.
This means the majority of the issues your users will face will be in that order, and in those proportions.
On our team I have banned initial-development testing in Firefox. It has to survive the weakest link, not the strongest. Inhumane, I know, but we have cut down going back and fixing bugs related to browsers by 80%, because 80% of browser bugs are IE. Yeah, there's a ton of debugging tools in Firefox that can be used ONCE we find a problem in IE.
On the flip side we put in extra-features that are Firefox only to reward the firefox users. A simple browser type check and it takes care of the rest.
If you have look at Web Browsers market share, you will find that IE and Firefox are on the top and so close to each other so,
You should put both of them in your consideration either using cross-browser Javascritp like JQuery or go on your way by testing both of them.
I think its best to design for Firefox but like others have mentioned the JavaScript isn't the hardest part, its the CSS that is the hard part. Personally I used to code for both FF and IE at once, but I find that it takes longer because your likely to make major changes during a development cycle so don't even bother coding for both at once, it could be wasted effort.
Another thing to consider when choosing which browser to start development under is if you are more familiar with W3C standards or the IE "standard" imposed by its majority user base. Its kind of a funny thing about web standards, many if not most web developers are not happy with IE's standards support, but at the same time any code IE supports is the real standard of the web.