Slightly ajar

All systems have been go, getting ready for the beta/alpha releases of our two flagship products. While Kestrel will spread its wings on Tuesday, I got a birthday present today with the launch of the second beta (if we were Web 2.0 that would be Gamma) release of Opera Mini 4. Many bugs have been fixed, including better integration with the Blackberry for all you crack(berry) addicts. As Mini 4 was a full re-write, many popular features were left out of the first beta. These are starting to return with today's release. Secure connections are back so it is safe to use your bank again. Content folding, and search engine customisation are also back. There are also more view options available, with landscape and full screen mode.

If you want to check out how much the standards support has improved since Mini 3 then download the beta then check out Cameron Moll's Markup test pages If you don't have a phone that supports Mini (that'll mostly be you Verizon customers) then you can check it out on the Mini 4 beta simulator. Note that ordered lists (ol) are supported, unlike what the test suggests. This seems to be a obscure bug with that particular page. If you are interested in designing for mobile then the first part in a series of guides about Opera Mini and mobile web design will be published by yours truly very soon on Dev Opera It will cover Opera Mini basics, how it differs from the desktop browser, and an introduction to handheld stylesheets and media queries. A more in-depth look into the specifications, particularly the JavaScript support, and an article focused on handheld and media queries will come at a later date.

I can also highly recommend Cameron Moll's hotly anticipated Mobile Web Design book that has just been released. This is the one book you should buy above others if you are interested in this field. It is well worth the $19 cover price. If you need to justify why you should create a mobile web strategy then this book should convince you that it is worthwhile. It is also one of the few texts on the topic of mobile recently, that doesn't preach designing for one device and one browsers. It is good to see the standards movement doesn't all have blinkers on.

Everybody seems to be posting their Opera Wish-lists, so without further ado, here is the list from my point of view, with focus on developer relations/web standards issues, and a couple of pet peeves. No internal knowledge was used or is inferred by this post. No kittens or fluffy animals were also harmed.

1. Replace the toilet seat. Please…I mean really.
2. Improve and simplify the user interface, with special focus on platform integration, especially on a Mac where platform consistency is expected. I'd especially like the tab bar move to the correct position. Correct in that it is the place I think is correct, maybe not everybody (I know the reasons why it is where it is), and it is where most (none-Opera) users expect it to be. As more apps in Mac OS X are getting tabs (terminal for instance) and the move to unified toolbars, the current position of the tab bar looks out of place. I'd love to see the Mac version get the unified toolbar look sported by iTunes and Leopard, and to follow the Apple HIG (spacing between elements in the interface for instance). I'd also like to see integration with AddressBook, Keychain and such. I like my passwords to be in one place, same with contacts.
3. Microformats integration across the board, from Opera Kestrel to Opera Mini. Imagine how much typing or cut 'n' paste that would save, for contacts and events alone, especially on Mobile where input takes longer. I'm sure there is some amazing things that can be done with XFN and xFolk. The challenge is how to present the presence of Microformats to the user without adjusting the layout of the page (changing how the designer intended the page to look can't be a goof thing) or add yet another icon to the URL field to go with the RSS, Widget, and Security/phising icons. There is enough already. Add OpenID into the mix and there are some great possibilities. There'd have to be some work with integrating OpenID into the wand and anti-phishing technologies to find a way to solve the phishing concerns though. Again, on mobile this would be a godsend.
4. Developer tools. We have some basic tools available on Dev Opera but we need professional quality tools, especially a JavaScript debugger, which not only matches what the competition offers, but blows them away. They should also be useful across our range of products. Web Developers have said time and again that they want better tools, and we are listening. Please let me know if there are any specific features you'd like to see, whether they exist in another tool or not. We are building tools for developers, so it only goes to say that we need input most from those that will use the tools. Otherwise we are just guessing what developers need.
5. Improved standards support. Specifically more CSS3, such as box-shadow, multiple background images, border-radius, border-image, RGB/HSLA and multi column layout. CSS2.1 is close to feature complete, but it can always improve and have bugs to squash. Our SVG implementation is the best in the industry, so it would be nice to improve it further, but I don't think it is in need of a high priority. Our DOM2 and DOM3 support is also up there or even beyond best of breed currently. It would be nice to get persistent storage from HTML5. We already have Web Forms 2 (the only browser so far) so we are currently ahead of the pack with HTML5 at present. We also have experimental support for the video element. Beyond CSS3 the main issues for me are squashing bugs and adding essential things that are not yet standard like JavaScript getters and setters (these may be part of a standard now?) that are used by a lot of major sites.

I guess I can't have a number six, but I'd like all that added and still make our engine faster (maybe a new logo or interface can have go faster stripes or Steve Jobs benchmark distortion field ). It's already been stated that we are working on performance in Kestrel, and further in Peregrine, so there is no secret it'll be a fast bird.

The CSS3 Colour Module is currently in Candidate Recommendation at the W3C. It has a number of new properties to allow authors more control of how they specify colour in their designs. In this post I'll take a quick look back at was has officially been available up until CSS2.1 and what has been added to the mix in the latest version of the CSS3 module.

Setting the colour of an element

CSS allows the foreground or the background of an element to be set using a number of different colour units. These are set using color for the foreground colour (mostly the text colour) and background-color. In CSS3 color is included in the Colour module, but background-color is included in the backgrounds and borders module. color acts just like CSS2.1 but adds a new legal value, attr(<identifier>,color). This allows one to specify an attribute from the element that the selector is pointing to, and the value of that attribute is used as the colour value. If it is not a valid colour then the browser/user-agent will fall back to using the inherit keyword.

Colour units

The value of a colour in CSS2.1 could either be one of 16 HTML4 colour keywords, or using the RGB colour model, specified as either a hexadecimal value (such as #FF0000) or a RGB triplet (such as rgb(255,0,0)). CSS3 has extended this by adding further colour keywords and an additional colour model. currentColor colour value has also been added, to set the colour to the same value as that specified in the color property. This is set to inherit if set on the color property itself. This is useful to set the colour of the background or border to the same colour as the foreground.

Colour keywords

In addition to the existing HTML4 keywords, the SVG colour keywords have been added. These are based on the X11 colour keywords. These have been implemented in browsers since Netscape 1.1, so should work in all major browsers, but they are now valid to use without getting validation errors. The named colours can be found in the CSS3 Colour spec.

Colour models

CSS2.1 uses the RGB colour model to specify colours, either as a hexadecimal number or RGB triplets. While this works well, it can be argued that it isn't intuitive. If one wants to tweak the colour to a different shade of the same colour, it isn't always obvious how to change the value. I still usually look up the value from a colour chart for instance (although I'm not a trained graphic artist). The new colour model, HSL, is thought by many to be more intuitive than RGB. This stands for Hue, Saturation and Lightness. Hue is represented by a 360 degree disc, where one can select the base colour that is desired. The basic colours (apart from white, grey and black -- more on that later) are around 60 degrees apart on the disc. For example, red is 0 and 360 degrees, yellow 60 degrees, green 120, cyan 180, blue 240 and purple/magenta at 300. Values between these get a mixture of the colours adjacent, such as cyan-blue at 210 degrees. The ligtness and saturation have to be set to get these colours however. Both are set on a percentage scale from 0 to 100. The lightness value sets how light or dark the colour is. No matter what hue or saturation is set as, using 100 for lightness would make the colour white, and 0 would make it black. Using values in-between would give a darker shade of the hue or a lighter tint. Providing the saturation is set as 100, and the hue is 240 (blue), setting the lightness to 75 would give a light blue, and 25 would give a dark blue. 50 would give regular blue. Ajusting this value would make the colour darker or lighter. As mentioned, setting full saturation will give the colour it's full hue. Making the saturation lower will move the colour to a more pastel shade until it reaches grey with no saturation. When using no saturation the colour is fully grey and the hue value doesn't make a difference. The grey will get lighter or darker depending on the lightness value. The statement color: hsl(240, 25%, 13%); would make a dark greyish blue, while a pure dark blue could use color: hsl(240, 100%, 13%);. As can be seen, once the basic colour positions are learnt on the colour wheel and which value is for saturation and lightness, it is fairly trivial to know how to get a different shade/tint or tweak the colour. HSL is currently supported in the latest versions of the WebKit, KHTML and Gecko rendering engines.

Opacity and transparency

traditionally there has been little control for transparency in CSS, except for making an element fully transparent with the transparent keyword or using transparency in PNG images. Much more control has been added in CSS3. The most widely supported is the opacity property. This is used quite often in the wild as IE can be given a CSS filter to mimic its behaviour. Opacity can be used to set an element to be fully transparent (opacity:0.0;), fully opaque (opacity: 1.0;) or any value in-between for varying degrees of transparency. While this is very useful, there are cases when it is desired that only the background (or foreground) have transparency applied to it. The RGB and HSL colour models have been extended to allow this by adding a alpha channel as a fourth value, with the same value range as the opacity property's value, creating HSLA and RGBA. background-color: hsla(240, 100%, 50%, 0.5); would make a semi-transparent blue background for instance. RGBA and HSLA are not as widely supported as opacity yet however.

Colour Profiles

There are a number of new properties relating to colour profiles. color-profile allows more control over the colours used by specifying a ICC colour profile. The default value is auto, which uses the sRGB colour space, unless an image includes its own ICC colour profile, in which case this is respected by the browser/user agent for that image. sRGB uses the sRGB colour space and ignores any colour profile included within a image. A named value can be set, which uses the corresponding colour profile in the browser's colour profile description database (if that profile exists), overriding any colour profile that images may have. A colour profile can also be set by specifying a URL where a colour profile is located.

A rendering intent for the colour profile can be set using rendering-intent. I don't know much about rendering intents, but a description for a valid values (apart from inherit and auto) can be found in the International Color Consortium standard. Finally a @color-profile rule can be set to group the colour profile and rendering intent. This was first defined in SVG 1.0.

The iPhone has now been released to much fanfare. I'd like to run through a few things on what this means to web developers and those that want to optimise their sites to work on mobile web browsers.

The first point that has to be raised is that Apple also believe in the One Web approach, where they feel that mobile browsers are capable of rendering regular web pages and optimisations can be made by giving an alternative stylesheet customised for the smaller screen. This is a view that Opera supports. Makers of WAP browsers will probably disagree as they don't have the technology to display regular web pages correctly. It isn't a black and white case of course. Sometimes it is nice to have a mobile specific version, such as when the content is very location aware, or the application is complex so it would take a lot of work to optimise the regular site. I would say on average is is best to leave the page as it is, and rely on technology such as Opera Mini's intelligent zoom or iPhone's zoom, or optimise the CSS (more on that later) for web pages (blogs, wikis, news sites etc) and do a custom mobile version for web apps like Flickr or Gmail etc. With a mobile specific site a link should always be given to go to the regular site, as there may be information there that wasn't provided on the mobile version.

If using One Web principles, the issues comes with trying to optimise the CSS for mobile. The W3C spec has a solution for this; the handheld media type. The principle being that computers use Screen media, when printing Print is used, Handheld for mobile phones, PDA and small handheld media devices/tablets and so on. This sounds rosy, except Apple and Nokia in their wisdom have decided not to support Handheld. That may be fine if they didn't want authors to optimise the layout for iPhone/S60 Phones, but Apple clearly do in their developer documentation (click on Optimise for Page Readability and scroll down). They state that iPhone ignores the print and handheld media queries because these types do not supply high-end content. Where they get this idea from I've no idea. It is obvious they don't need to support print (Opera Mobile and Mini don't either) because you are not likely to hook your mobile up to a printer and print the document, but print media has nothing to do with high or low end content. It is the same for Handheld, and it should be used for doing exactly what the suggest; specifying a stylesheet for mobiles. They get around the lack of handheld support by using Media Queries. This is a solution I've proposed in a previous article. This works well and gives a lot of fine grain control, but it would be much simpler to just support handheld media to get the same effect. That would get around any issues where a desktop based browser could get the mobile stylesheet due to using the screen media type, and where older mobile browsers will not get the mobile stylesheet as, as far as I know, only Opera based and WebKit based browsers support Media Queries. It is also worrying that they seem to suggest that developers should design specifically for the iPhone, and not mobile browsers in general, especially with a CSS filename of iphone.css in their example. This is a case we tried to avoid when the Wii browser was getting popular, by adding TV media support, so that all TV based browsers would benefit from the optimisations. There are of course exceptions where a web site is and should specifically be aimed for one browser and device, such as when Wiicade make use of the Wiimote hardware for example. In the case of the Apple documentation they give the following code suggestion:

<link media="only screen and (max-device-width: 480px)"
href="iPhone.css" type="text/css" rel="stylesheet" />

I'd suggest changing it to the following:

<link media="handheld, only screen and (max-device-width: 480px)"
href="mobile.css" type="text/css" rel="stylesheet" />

That way it will work on any devices that support handheld media (and makes sure Opera Mini 4 doesn't apply its desktop overview mode) and also on mobile devices such as the iPhone and Nokia S60 browsers which only support Media Queries.

Apart from the handheld debate, it is interesting to note that iPhone suffers quite a few of the same limitations as Opera Mini. Notably that it doesn't support file downloads or uploads (although you can upload from the camera in Mini), no plug-in support such as Flash, limited javaScript execution time etc. Although these are draw backs of both browsers, it does mean that it will make the base line that developers can aim for much more consistent. Fixing issues in one browser should fix many issues in the other browser.

One thing of note on the iPhone that is interesting to me was revealed in Daring Fireball's iPhone First Impressions. That is that the UI's interface uses the Helvetica font. This is interesting for a couple of reasons. First of all OS X usually uses Lucida Grande as its default UI font. I wonder if there was any reason for the choice, or if it just looked better on the smaller but high resolution screen? Either way I love the Helvetica font, so I think it is a nice choice. The most interesting thing for web developers though is that it means one important thing — that regular desktop quality fonts are available on the iPhone. This is not really a surprise, as it is based off OS X after all, but it is nice to have confirmation. One of the biggest problems with mobile development in my mind is the inconsistencies between devices caused by font support on phones. many only have one font (which is of quite low quality) and some have very limited text sizes available. It is also common that italic isn't even available. I don't have a iPhone, so I can't confirm if any other fonts are available. I'd expect they'd include the Microsoft core fonts (in the Web folder in FontBook) such as Arial, Times New Roman and everyone's favourite Comic Sans MS. I think it is important for consistency in mobile web design for handset providers to start providing the same fonts across models and brands. Web Fonts could solve the problem but it will be a while before they are supported across multiple mobile browsers, and a user probably doesn't want to download large font files across a slow EDGE network.

<p.look out for our Opera Mini 4 developers guide soon. it is in the final stage of preparations. As Opera Mini 4 is in beta, standards support will likely change for the final release, so look for updates to the document as time progresses.

On this blog I've mentioned quite a lot about CSS3 selectors. You might have noticed that the official Opera desktop team blog recently announced that Opera Kestrel has completed and enabled full selectors support. This also means that Opera Mini 4 should have full support by launch and the Wii browser will likely also benefit from this. Now I ca put to bed talking about selectors, what else is on the horizon? Well, there is certainly a lot more CSS3 that we can work on, including some very interesting things like multiple background images, border-radius, multi column layout, web fonts (a particular favourite of Håkon, our CTO and father of CSS) etc. I can't promise support for any of this, but we are listening to designers and developers, so it'd be interesting to see which CSS3 properties are most wanted.

Away from CSS, our SVG continues to improve, cementing Opera's place as the most compatible browser for SVG rendering. I believe we are still the only browser that supports SVG animation. Being able to use SVG from the img element and from CSS is a particular favourite of mine as it leads to some interesting scaleable design techniques, such as using SVG as a background gradient, or bullet point icons that don't go jagged when zooming into the content. Because SVG isn't as widely implemented as CSS (read no IE support and no official Safari release until Safari 3 comes out ), there isn't as much talk about it as CSS, and I don't think that Opera perhaps gets as much publicity as it deserves for our stellar support (do a Google search for SVG). Maybe it is time we made a svg.info site.

As a Mac user, what really excites me is the news that Kestrel will get an improved theme and interface for Mac. I'm not a big fan of the current look, so the improvements will be welcome. Even as an insider, I've not seen these changes yet, so i guess I should start digging into the internal builds.