Slightly ajar

There are various reasons why web sites do not work in browsers such as Opera. Generally they fall into four categories; there is a bug in the browser, a bug in the standards specification, a feature has not been implemented yet, or there is a bug in the site. Although Open the Web to some extent deals with all of these, the later is what we deal with the most, and is what we can mainly help site authors with. These areas are not black and white however and certain issues could be pigeon holed differently depending on interpretation. I'll look at some common web site bugs in this post that effect Opera the most.

Browser sniffing

This is a term for detecting what browser is requesting the content, and is commonly done either server side or in JavaScript/ECMAScript. After detecting the browser different content is served to it. Opera often has problems with this as sites will use it to either block us entirely, send us broken content or forget about us entirely and send no content. There are varying degrees of blocking a browser. The worst will not let the user in at all unless they know how to spoof the user agent string, while others are kinder and warn that the browser may not be supported but you can try anyway. Not all browser sniffing is bad however. It can be useful when there is a known bug in a browser, so that different content is sent that works around the bug. Bugs generally get fixed eventually, so if you take this approach it is best to also detect the version number of the browser that has the bug and only send the adjusted content to that version. That way if the bug is fixed in the next release, your fix will not break the browser.

Object detection

This is generally a better approach than browser sniffing and should be encouraged. With object detection, a function is tested to see if a browser supports it. If it does then you can safely use it, otherwise you can use a known work around. This way a new version of a browser will automatically work with a site once they implement the missing functionality that was tested. Although object detection can do a lot of good, it can also break sites if used wrong. A common way of using it wrongly is to use it as if it is browser sniffing and saying the JavaScript equivalent of If supports document.all browser is IE. Although document.all is an IE extension this assumption falls flat on it's back because Opera also supports it. Object detection should never be used to try to detect what browser is being used. Often the document.all detection is used to then send the browser further IE only code such as CSS filters. As no object detection is used on this because it is assumed we are IE then Opera breaks.

addEventListener

addEventListener is included in the W3C DOM Level 2, and Opera supports it so there should be no problem right? Wrong. The third parameter of this method is useCapture, which specifies if it is a capturing or none capturing event listener. Unfortunately both Firefox and Safari have a bug with this where they treat it as a non capturing event listener no matter if the parameter is true or false. More information about this can be found at this blog post. This causes Opera problems because some scripts that have been reused a number of times use capturing event listeners instead of none capturing, and as it works in other browsers they do not noticed they used the wrong one. This is very easy to fix however by switching the true to false. [UPDATE} Apple are updating their implementation to correct this bug, and it should work the same as Opera on the latest builds of WebKit. This will be good news when this is shipped in Mac OS and Safari. Hopefully Mozilla will follow soon.

position: absolute VS position: relative

IE has a bug where in CSS absolute and relative positioning are treated as the same. Instead absolute positioning should be taken out of the flow of the layout while relative is relative to the containing item. As both seem to do the same in iE, for developers that only test in iE they do not notice the difference and often use the wrong one, meaning content that should be aligned somewhere in the document tends to be stuck at the top left hand corner of the screen in Opera, Safari, Firefox et al. Again this is very easy for the author to fix by swapping the values.

None standard code

This is often used together with browser sniffing or object detection. Browsers such as IE or Netscape in the early days often develop their own none standard code such as Active-X or extensions to the DOM. As only one or limited browsers support it then sites that make use of it will only work in a limited number of browsers. Active-X is the biggest problem as it is IE and Windows only, not to mention a security issue. Not all none standard code ends up bad however. The object that almost single handily started the AJAX revolution, XMLHttpRequest, started life as a IE 5 only extension. Other browsers saw how useful it was, mainly after the likes of Google started using it, and now it has become a de-facto standard if not a real W3C one. As it is so widely used and implemented it is likely that it will be standardised in a W3C specification.

Plug-in mistakes with Flash

I almost missed this one off the list. To include plug-ins such as flash on a page, you have to include an embed tag wrapped in a object tag, so all browsers know how to handle it. It is common however that sites do not give the same parameters in the ibject tag as elements in the embed tag. This means that browsers such as Opera and Firefox that use the embed tag display the plug-in differently to browsers that use object, such as IE. Common mistakes with this are updating the url of a plug-in on the object tag, but forgetting to change the embed tag and specifying different back ground colours. By far the biggest mistake though is missing wmode="transparent" off the embed tag when i is needed. wmode sets the windowing mode of the plug-in. This is especially needed when any JavaScript is going to display over the plug-in area, such as a fly out menu. Without the wmode set to transparent the menu displays behind the plug-in and can't be seen, rendering the site unusable in many cases. It is also useful if your flash content is not square and you want the content under to show through.

Although there are many other issues, these are the most common I come across day to day. If you are a web author, you can minimise these issues by validating your (X)HTML and CSS to ensure valid code is used, check the JavaScript console to make sure there are no errors there, do not use browser sniffing unless needed, use object detection throughout your JavaScript to make sure a browser supports what you are trying to do and finally test in the major browser engines. I'd recommend to test in the following browsers:

• Internet Explorer
• Opera (Presto)
• Safari (WebKit)
• Konqueror (KHTML/KJS)
• Firefox (Gecko)

Testing in all of these, depending if you have access to each of the platforms, will ensure your site works in all the major engines. While WebKit and KHTML are not the same, they are based off each other, so if you do not have access to a Mac or Linux then testing in either/or may suffice. If you have time you should also test without plug-ins and javaScript enabled to make sure your site has fallbacks and remains accessible. Testing on mobiles is becoming increasingly important but not everyone has access to a phone running a browser. In this case Opera's small screen mode (View -> small screen) is useful as it shows how our mobile browser would render the page. This takes handheld stylesheets into account if one is specified. This makes developing mobile friendly code easier and faster, and remember the same engine s used on the Nintendo DS Browser.