Slightly ajar

CSS3 development work is going full steam ahead for most browsers. At Opera this is no exception. Most people don't have the privilege of testing out our latest internal builds, which will go into a future release of our browser, so I thought I'd share with you some of the great work our developers have been up to in regards to CSS3.

A lot of work is going into selectors, and there is a quite extensive list of extra support added to those already implemented in Opera 9.1. New in the latest builds include:

• :root
• :not()
• :nth-child()
• :nth-of-type()
• :first-of-type
• :target (still buggy at present)

As well as those above, the following are implemented in our core engine, but not currently enabled due to various issues:

• :empty
• :nth-last-child
• :nth-last-of-type
• :last-child
• :last-of-type
• :only-child
• :only-of-type

It is planned that these will be enabled by the time the other selectors are included in a release version of Opera. Having all these selectors supported will allow designers to be able to have much more control over their designs without adding extra class attributes to the HTML or using JavaScript to allow certain effects.

One example is :nth-child. With this it is possible to add alternating style using :nth-child(odd) and nth-child(even). This can be useful on data tables, so that each row has an alternating background colour, making it easier to scan through the information. A lot of blogs use a similar approach (currently using extra mark-up) to make alternating rows of comments styled differently. Using different values in the parentheses allows endless options to be used. nth-child(4) will match the 4^th child of the element it is applied to, while something more complex like nth-child(4n) will match every 4^th child (such as a row in a table), and nth-child(4n+6) will do the same, but has an offset of 6, which means it wont be applied until the 6^th child has been reached.

Another example is :first-of-type. This could be used to slim down the CSS code that is used on this blog. Instead of using all sorts of selectors to apply the drops cap to the first paragraph in a post, using p:first-of-type would enable the first p element to be matched in a blog post, then first-letter could be chained to this, such as p:first-of-type:first-letter. It wouldn't matter if a Div element was before the first paragraph, it would ignore everything until it reaches the first p tag.

With all these changes, where does this leave selector support in Opera once the new additions get released in an official build? Well apart from bugs in any of the implementations, all the selectors will be supported, and the only thing currently lacking is support for the ::selection pseudo-element. Of course there is still a lot of work to do on the other CSS3 goodies that aren't currently supported.

For a much more comprehensive look at CSS3 selectors, take a look at Roger Johansson's excellent article on the subject. Away from selectors, I can also confirm that text-shadow has been implemented in internal builds. As the name suggests, this allows shadows to be applied to text, allowing some nice effects.

While I've known about this for a while, under a different model name, the Nokia N800 has just been officially announced at CES. This is the follow up to the cult hit, Nokia 770. The reason why I'm writing out it of course is that it runs the Opera browser. It is an interesting choice by Nokia's marketing department that they have decided to move the device from it's own product range to the N Series range. Will this cause confusion in that while the N Series are Symbian S60 based smart phones, the N800 looks smart, but is neither a phone (likely to cause the biggest confusion), nor runs S60. It instead runs Nokia's own Internet Tablet OS 2007 edition, which is based on embedded Linux.

Judging by the photos, the N800 is made of nicer materials than the 770, but I think I prefer the understated minimalist design of the 770. The onscreen keyboard also looks much improved. In some ways this competes with another Opera powered device; the Sony Mylo, but they are both aimed at different markets. The Mylo's style looks like it is aimed at a younger audience and the form factor is more suited to communication as it's primary function, while the N800 has a more mature look and it's screen size is ideal for web browsing first and foremost. The beautiful 800 x 480 screen means that pages can be shown in their original form without zooming, reformatting or horizontal scrolling. The only issue being that if your eye sight is not as it once were, the text size may be too small at this high-resolution to read comfortably for long periods, which is where Opera's zoom feature will come in handy. This is different from the Wii where the screen may be big enough, but smaller text isn't sharp enough without zoom due to low resolution on regular TVs.

This device is another perfect excuse to make sure your site works in Opera. Like the Nintendo Wii, web pages will display just as they do in the desktop browser, baring resolution differences. Like the Wii, this supports the latest embedded Flash version, Flash 7. The main difference is that while the Wii sports Opera 9, the N800 uses a build of Opera 8, so there may be some issues that are not present in the latest desktop release. However in general, if you get your site working in Opera desktop, it will also work great on Wii, Nokia 770 and N800, and any other device that comes out in the future with around desktop resolution screens, for free. Not to mention the big head start on getting sites to work on screen size constraint Opera powered devices, such as mobile phones. It'll be quite interesting to see what devices come out next. Whatever it is, make sure you are ready for it.

P.S, Nokia, where is my copy so that I can test sites and Open the Web on this thing?

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.