Slightly ajar

The new year is upon us, and what better way to start it than to create a wish list for the upcoming year. These will be mostly related to Opera, but also some in regards to web standards in general. These don't relate to any inside knowledge at all, and are just personal wishes.

Change the toilet seat

I'm running Opera here on my brother's PC (My Mac laptop died a sorry death on new years eve), on XP and the logo isn't so bad due to the icons on XP being so tiny and low resolution. It is a different matter entirely on OS X though, which is magnified more on Leopard, with the new dock that gives a shadow of the shadow, and a reflection of the reflection. Not to mention a reflection of the shadow and a shadow of the reflection. A icon probably needs to be more detailed, but as a logo mark how about a perfect circle, a red ring? Rings and circles have a lot of positive symbolism, are very recognisable, and are geometrically pure and minimal. A ring is also used in Japanese (a strong market for Opera) as the symbol for yes or correct, just as a tick is fin the West (while a tick means incorrect in Japan).

Promote our roots and heritage

Opera is both Scandinavian, and European. Being Scandinavian has one big disadvantage; the cost of doing business and the wages are high due to the cost of living, taxes etc. It does have big benefits though. Scandinavia is known for its technical inovation (as is Opera), with the likes of SonyEricsson, Nokia (ignoring the fact that Scandinavians would term Finland as Nordic and not Scandianvian), Saab and Volvo. That means there are many people with great technical ability here, and just as many close by in the rest of Europe. Arguably though Scandinavia is more famous for its design. Bang & Olufsen is the stand out name in terms of electronics, but there are many more from the worlds of fashion, art, architecture, home furnishings, music and so on. Names such as Ikea, H & M, and Absolut (whose bottle is a design icon) are probably house hold names around the world. And who didn't play with Lego when they were a kid? Of course, Europe as a whole is famous for its design or high quality goods. From Germany with its cars, to Italy with Fashion, Switzerland with watches an France with its wine and cheese. Did I also mention the Scandinavian women?

In some ways we are already moving in this direction. If you look at our feature list, it can often be described as maximilism instead, of the Scandinavian minimilism of its most famous design movement. But we've got some great new designers, that are doing some fantastic work, and we've recently worked with the photographer of Moods of Norway for the images on our new B2B section of the Opera web site. You'll even notice one of their founders in some of the photos. They're a small but up and coming fashion label that are very popular here in Norway, and stars like Gwen Stefani are fans.

I'd love to see us work closer with these kind of companies and creative people, and also come up with a design aesthetic of our own, which is both uniquly ours, but pays homage to our heritage, and design excellence of the region.

Deliver to top quality partners

In 2007 Opera delivered products to some of the biggest names. Nintendo, Vodafone, T-Mobile and Sony are just a small example. One partner I'd love Opera to have is the aformentioned B&O. It wouldn't do anythnig for our market share, as they ship low quantity, high cost items, but the combined innovation potential of both companies combined would be quite exciting. I can think of some great control methods we could do with their new programable, touch screen remote, and I can imagine they'd create a great minimalist interface. We also have the technology so that we could be included in their entire range, from TVs, to mobiles, landlines, music systems and even their car projects.

I'd also love to do something more experimental. Car manufacturers often create prototypes for the big car shows. I'd love to see Opera create a prototype browser for a company such as Saab, that shows how a browser could be integrated into a car, and even control the entertainment system and other systems. Being a prototype, it wouldn't have to be even functional, just design ideas. Opera has already shipped in aircraft seats, so there is no reason why it couldn't be included in cars too, especially with our voice control technology.

Opera Labs

Speaking of prototypes, we have a fairly new labs site. During the year we released a number of experimental builds, such as advanced SVG, canvas and video builds. It would be great to use this site more to show some of the crazy technology we are working on, and realease things like prototypes and experiemnts that perhaps couldn't be included in our flagship products. Experimenting with different interface styles for instance.

Faster, Safer, more Standards

We are probably industry leading in all these areas, but there is no reason why we can't improve even further. There is certain CSS3 properties that I'd love to see, and HTML5 has some interesting features. It would be nice to see core pieces of each spec ready, and implemented by the major browsers, by the the end of the year. It isn't possible for all of the spec, but in CSS3's case, it could include a couple of modules such as Backgrounds & Borders and Media Queries for example.

Developer tools

It is no secret we are building real developer tools. It will be difficult to rival the likes of Firebug instantly, as they've had years of development. We are commited to making good quality tools however and to improve them as they mature. I hope they ease issues with developing for Opera, and help improve our compatibility rate. Hopefully we can deliver some of that Opera innovation to the developer tool space.

The one true web to rule them all

There is a feeling in the air that we are in the mist of the beginning of another great browser war. Lets hope the Web wins this time, instead developers moving from the Web to alternative one vendor controlled technologies such as Air and Silverlight. It certainly looks that way with all the Silverlight sponsorship and booths they've been doing at Web conferences recently. Far more than promoting IE IMHO. I'd love MS to commit to adding to IE any feature that exists in Silverlight, or is planned to be, and is included in a Web standards, in a reasonably similar time frame. If Silverlight gets much more features for developers to use than IE, then it is natural developers will start looking at the shiny new toy. Silverlight is a nice rival to Flash, in a one vendor solution rival to another in the plug-in space, but if it becomes a rival to the web, then that is scary for everyone, except Microsoft. Ditto with Air.

I want the Web to win in '08 and not any commercial interest from either player.

Over the last year or so there has been an increasing visibility of the web away from the desktop, especially with the rise of Opera Mini (which we've just announced over 1 million downloads in 10 days) and the hype of the iPhone. That isn't the only way to see the web away from its traditional confines though, and the launch of a white games console from the N company paved the way for another kind of experience - surfing from the couch. What makes this unique and what should you look out for?

If you take the experience on a phone, there are some constraints and differences you have to look out for. Even though they are called Personal Computers, a PC is generally anything but, with many people sharing one machine. On the other hand a phone is very personal. A phone is rarely shared, people keep them with them at all times, and customise them heavily. It is therefor logical that personalisation is something that should be taken into account for a successful mobile web experience, and it should be optimised for 1 to 1 interaction, just like the desktop. The TV on the other hand is a much more social affair. There is probably not many sites more popular on the N companies console that YouTube. what is more fun, having friends bunched around a desktop in the office, or sprawling out on the couch with a pizza watching the latest funny clip? The web on a TV is meant to be shared between many people. Information isn't private, as many people can see the screen at once and the tV is probably in one of the busiest rooms in the house. The Big N take great advantage of this with multiple controller support. Other users can point at things on the screen individually. With some imagination this could be taken advantage of in interesting ways. Wiicade for instance allow for multiplayer games. Apart from Video, Music and Games, social networks could be an interesting area for innovation. Presently there isn't much social going on in the popular networks - one persons interacts at a time.

So what are the constraints? We'll it is different than mobile. With mobile you have slow latency and low bandwidth (unless you are connected to Wifi). TVs in general are connected to Wifi or a wired network. Mobiles also are limited to the palm of your hand, while TVs are generally much bigger than your desktop or laptop. The problems in this area are viewing distance and resolution. A standard definition TV has a resolution of 720 by 576 (PAL 576 p/i) or 720 by 480 (NTSC 480 i/p) and in reality the viewable resolution is lower than this due to inefficiencies. This low resolution causes bigger problems as the screen sizes are usually large so the pixel density is very low, and text can be blurry and hard to read. As technology marches on these problems will fix themselves. 720p (1280 by 720), 1080i and 1080p (1920 x 1080) displays are already on the market and fairly popular (note: the most popular TV browser doesn't support HD), and the resolution is around that of regular computers. Whether the user has a HD TV or not though, the same constraint is present. The user will usually be sitting on the sofa, a good distance from the screen. You as a designer have to take this into account, and is sometimes called the 10 foot interface. Even on a big HD screen, the text should be designed to be enough to read. This limits what can be displayed at one time. Consider restricting the number of columns and including side bar content, that isn't regularly accessed, under the main content. Browsers are gaining high quality zooming functionality (Such as Opera's Intelligent/Adaptive Zoom) , but the experience will be better if the text is readable without having to zoom in and out.

The methods of interaction can also be difficult. Just like mobile, this is hard to predict. A set top box or TV could come with a wireless keyboard and trackpad/scroll ball, or it may come with just a remote (that can vary themselves). It may even come with a magic wand that follows the users hand movements. Unless a keyboard is available (this shouldn't be assumed) then text entry will be a pain (although experience makes this easier) so avoid making a user add unnecessary text. Consider implementing OpenID for example, and keep the URLs short. Use device independent event handlers in your JavaScript where possible.

Just like mobile, you don't have to make a separate optimised page for TV browsers. Media Types and Media Queries come to the rescue. You can define a separate stylesheet just for TV browsers or you can adapt your existing stylesheet to bump up the text size and refolw the layout for example. Using a combination of the two, you can progressivly enhance the layout as you detect higher screen resolutions. If you have stylesheet that either has the media attribute set as all or tv (or screen, tv and other combinations of different media types) you can include the following CSS:

@media tv {
     /* catch all for any tv that don't fit the queries below */
}

@media tv and (min-device-width: 720) and (device-aspect-ratio: 4/3) and (scan: interlaced) {
     /* styles for 480i standard ration TVs goes here */
}

@media tv and (min-device-width: 720) and (device-aspect-ratio: 4/3) and (scan: progressive) {
     /* styles for 480p standard ration TVs goes here */
}

@media tv and (min-device-width: 1280) and (device-aspect-ratio: 16/9) and (scan: progressive) {
    /* styles for 720p widescreen TVs go here */
}

@media tv and (min-device-width: 1920) and (device-aspect-ratio: 16/9) and (scan: interlace) {
    /* styles for 1080i widescreen TVs go here */
}

@media tv and (min-device-width: 1920) and (device-aspect-ratio: 16/9) and (scan: progressive) {
    /* styles for 1080p widescreen TVs go here */
}

If the stylesheet is just for tv you can leave the first catch all media query out and just include the styles without a media query. If you use all or include other media types in the statement, you probably want the media query so that screen browsers or printers don't get the TV styles (unless you want them to of course). Depending on your design, you'll probably not want to include all those media queries and just adapt the layout and text sizes where needed. You may also want to use max-device-width instead of min-device-width and exclude some of the extra conditions. It may not be important if the screen is interlaced or progressive for example. Aspect ration may be important if you use multiple columns, as a widescreen display will fit more content horizontally (or will at least have more real estate, maybe not more pixels). You milage may also vary with what browsers support which media queries. device-width should be the most supported. Opera and WebKit based browsers are the only browsers that currently support MediaQueries as far as I know, but they are part of CSS3 and any device based browser worth its weight in salt should add support for this.

Finally, you should take into account the colours, thickness of elements and movement on TV. White and red in particular are hard to read on TV (My blog won't be great then) as the bleed (I'm not sure if this also applies to HD TVs?) and so should be avoided if possible. One pixel elements, such as borders can also bleed, so consider using 2 pixels at a minimum. Fast movement on older TV can also cause ghosting, so be careful in this regard. Speaking of movement, media playback is often a problem as a company has to licence the codecs or plug-ins. This makes it very variable if a format is available or not. Flash is generally the most supported, but generally needs to be saved as version 7 or lower. Avoid Quicktime at all costs, as it is only available on Mac and Windows (or Apple's own hardware). Many devices come with some form of embedded linux for example, where this is not available. Windows Media is not much better, if at all. This is one of the reasons why Opera (and Mozilla) are pushing for a Ogg Theora solution. It is an open standard, that can be implemented and shipped by anyone without paying licensing fees or royalties. Including this in a browser allows it to be used on devices and become a baseline format that people can deliver to. This is something for the future however, and no browser on TV that I know about supports this yet.

So in summary, make your text readable at ten feet, think collaboration, think social, avoid unnecessary input, progressively enhance for HD with Media Queries, and avoid those sharp bright colours.

The W3C has just recently published a working draft of their first annual CSS snapshot. As this came about in a meeting in Beijing, I'll name it the Beijing report. Peter just beat me to the punch in covering what is included in the Beijing report on the CSS3.info website, so I'll let you read his post for an overview of what is in the draft. I personally think that this is a great step forward from the W3C, and is a sign that they are listening to criticism that CSS3 is taking too long. Having a snapshot like this allows user agent vendors, such as ourselves, to know what modules, or properties are considered stable enough to implement, without too much worry that the specs will change significantly.

We'd all love to see many of the things in the Backgrounds & Borders module, but this is not considered stable enough to be included in the snapshot, nor any property from the module. Looking at properties such as border-radius where more than one rendering engine supports supports it, they do differ in syntax and implementation. Opera does implement background-size as -o-background-size as it was needed for the UI of a certain customer delivery, and it was best to use an experimental implementation of a CSS3 property than invent our own vendor specific property.

Of the contents of the working draft, how far is Opera along in supporting these modules and specs? Using the latest public weekly of Kestrel as the subject, I've gone through the draft and noted what is and isn't supported.

CSS Level 2, Revision 1

This spec has been a long time coming and draws ever closer to completion. The spec is too large to cover everything that is supported in detail here, but if you take a loo at Opera Merlin's (9.0 - < 9.5) official spec sheet, you'll notice that Opera supports all of CSS2.1 with the exception of the visibility: collapse and white-space: pre-line property values. Since Merlin, Kestrel has added white-space: pre-line support. This can be tested at PPK's Quirksmode site. The spec has been updated recently, so I'm not sure if that information still holds true, so if anyone knows differently then please let me know. I couldn't find a changelog detailing what the recent changes were when it moved to Candidate Recommendation in July. Even if we only lack one value of one property, we still have bugs that have to be ironed out. The last I checked the test suite also had bugs. I would assume that Opera Kestrel currently has the most complete CSS2.1 support.

CSS Selectors Level 3

I've already wrote a lot about selectors on this blog, so regular readers will know that we pass all tests on the css3.info selectors test. The tests are not exhaustive, so there will be bugs, but it gives a good indication of what we support. It reports that we support all CSS selectors. This isn't quite true as it doesn't test the ::selection selector. That is the only selector that Kestrel doesn't currently fully support. Just like our CSS2.1 support, Opera has first class support for this spec, and is close to completion, apart from the seemingly never ending bug squashing that is a familiar part of any software development.

CSS Namespaces

CSS Namespaces allow is most useful in XML documents, and allows ocuments with mixed namespaces to be styled individually. For example, a p element in one namespace can be styled, without the p elements in another namespace being effected. If you declare the namespace @namespace xhtml "http://www.w3.org/1999/xhtml"; you could style only the p elements in this namespace using xhtml|p.

Opera already supported CSS3 Namespaces in Merlin, and it is now supported in other browsers such as Safari and Firefox. There are five testcases for namespaces in CSS found here, of which Kestrel currently fails one.

CSS Colour Level 3

Of all the specs and modules in this draft, the colour module is the least supported by Kestrel. We clearly support the colour properties for CSS2.1, but what about the extra properties and values in level 3? SVG colour keywords are supported, and in reality these have been supported by browsers for a long time, and just were not included in a spec. The opacity property was much requested and was included in Merlin. The currentColor value is also supported and I believe this was added in Kestrel. The HSL colour model isn't supported yet, but shouldn't be hugely difficult to support, given that it maps to RGB. An alpha channel has been added to both RGB and HSL an these are both not supported yet. This differs from opacity in that it is only applied to the property it is used on, such as the background-color and not the whole element. This will mean that the text will not be effected in this example. ICC Colour Profiles are also not supported as far as I'm aware, and neither is the flavor colour keyword. David Baron has written some testcases (thanks to fantasai for pointing that out) an not surprisingly Kestrel fails most of the HSL, HSLA and RGBA tests. Strangely it also fails the HTML colour keywords and SVG colour keywords tests and I'm not sure why. Safari and Firefox also both fail these tests. We also fail the flavour test, but I can't think of a single use case for the flavor colour keyword.

Overall Kestrel is in good shape in regards to supporting the standards in this snapshot, and has either the best support or close to it for each module listed, except perhaps the Colour module. Each of these have limited features missing, and except for the continuous cycle of bug fixing they are close to completion.

During the development of Kestrel, I was hearing of the advancements in our SVG support. Not being a SVG person I wasn't familiar with everything that was added, but I was interested in checking out the W3C SVG test suite to see how our progress was doing. Being a W3C test suite, it looked both intimidating and time consuming so I never got time to run through the tests. Fortunately I didn't have to, as Jeff Schiller took the public Alpha through its paces and updated his support graph.

I'm not sure if this includes SVGT 1.1 or just SVG full 1.1 (I suspect the latter), but Kestrel has improved Opera's support to 93.4% of the test suite. That makes it not only the most compliant browser, but also the most compliant user agent full stop, even beating the impressive Batik 1.7. The closest browser is Firefox 3 with 58%. Now we have full CSS3 selector support, I'm looking forwards to the race to full SVG compatibility, and I think Batik will give us a good run for our money. It's a shame Jeff's chart doesn't show the tests that fail for each browser.

I've heard a number of web developers complain about Opera focusing on SVG, but there is a few reasons for this and it doesn't effect our other work, and I certainly agree it shouldn't be our primary focus, but:

• We have different developers that work on different areas, so working on SVG isn't taking people off JavaScript or CSS layout for example
• SVG was often a carrier requirement for inclusion on mobile devices, and is much more useful and widespread in the mobile world, than it is on desktop.
• It is a standard that shows promise once support is widespread, and if we are going to do something, we are going to do it properly
• SVG is very useful on things like device projects where Opera is the interface to the device using WebUI. Think games consoles for instance
• Other browser vendors like Safari and Firefox are adding SVG support and it shouldn't be too long before get good quality cross browser support. IE will be the problem, and in that way it will be similar to the PNG situation pre IE7, but IE is under active development now and they have a great team, so I wouldn't rule them out.

Now Opera has good compatibility with SVG, developers can take it for a spin and start learning the basics of SVG in preparation for the future. I recommend to start looking at using it for background-images in places that degrade well without the image, such as the gradient example two posts ago. Once Safari and Firefox add support for SVG through CSS you can start using this technique across browser, and send a rasterised png/jpeg version to IE through conditional comments. The size and bandwidth savings should be quite substantial, the scaling is much better and it is so easy to edit the file if you want to change the colour, edit the gradient etc. The possibilities of adjusting the image through the DOM should be fascinating too (rotate a arrow bullet on-click in a tree list for example) , but this wont be so easy to do fallbacks for IE.

You may have downloaded Kestrel by now, and glanced at the change log, but you may not have tested out its new capabilities. I don't profess to be a JavaScript expert, so I'll leave that to those of you who know better, but I've cooked up some demos of the new CSS and SVG capabilities along with an article explaining them. That article is now ready, so please go and check it out.

For those of you who want to go straight to the examples (some modified from previous demos on this blog), here they are:

• Striped table, without Javascript, using CSS3 selectors and SVG as a CSS background-image. It also uses text-shadow
• Classless flexible drop caps using first-of-type
• Liquid layout using dynamic Media Queries
• Rounded corners combining SVG and border-radius. Allows rounded corners in Opera, Safari and Firefox, without images or JavaScript.

This article and demos have just scratched the surface. There is a lot to look forward to with our new JavaScript engine, improved DOM support, more HTML5 and canvas, and a more complete SVG implementation including partial SVG 1.2 Tiny support, and more. If you've been experimenting with Kestrel and have tried out some of the new features, share your examples and experiences in the comments. Hope you enjoy the article.