Slightly ajar

While Kestrel is getting ready to spread its wings, we are currently busy adding new features to Core-2 and deep into the QA process. I've already mentioned the CSS3 selectors are done and dusted, but what else is new since the last report? Not forgetting about CSS2.1, we've adding support for whitespace: pre-line;. This edges us ever closer to full CSS2.1 support.

CSS3 support is obviously not as advanced but is moving along with every build. background-size from the backgrounds and borders module is now supported with the -o- prefix. overflow-x and overflow-y from the basic box model module have been supported in builds for a while but not widely reported. This was one of the CSS3 properties that had started to become widely used, due to it being supported in IE, so it was essential to support for site compatibility reasons. It pops up many times in Korean web sites for example. The currentColor keyword has now been added from the colour module. This was already supported in Opera for SVG. This specifies a colour to be the same as the value of the color property or inherits the colour from the parent if no colour is specified. Keeping up Opera's reputation for great keyboard support, nav-index, nav-up, nav-down, nav-left and nav-right have been added from the basic user interface module. This allows control of which element will be targeted next when the user presses the corresponding key. The spec doesn't define what key to use for each, but suggests the direction arrows for keyboard use. This is especially useful when absolute positioning is used and the elements may not be displayed in source order. Also from the basic user interface module, outline-offset has been added to round off our outline support.

As well as these properties and the ones already reported, there has been numerous bug fixes to improve our compatibility with major sites. Hopefully we'll be able to add further CSS3 support as Kestrel matures into a release ready product. We are taking note of what properties developers want and we are assessing if they are ready to be implemented.

My second @Media is now over, and I'm back at Opera HQ. As always, it was fun to meet old and new friends that we always bump into at these events. There was many familiar faces at @Media, although with there now being a @Media in San Francisco, it felt like the crowd was maybe a bit less cosmopolitan. When Andy Clarke asked in his session who was from the UK then Europe it seemed to be most of the room, while last year I felt like I met a few more Americans and such.

Thoughts on the event

Our CTO, Håkon Wium Lie gave an interesting speach, and a call to arms to adopt the video element using none patented codecs such as Ogg Theora. I've heard good feedback from the talk, such as from Peter Gasston of CSS3.info, and I think it was one of the best presentations I've seen him give. He presented in Opera Show, which is using the projection mode of CSS in Opera to make the browser used paged media. With CSS, HTML, Javascript, SVG, plug-ins and potentially the video and audio elements from HTML5 at your disposal, the browser can be a powserful presentational platform. As the slideshow is basically a web page, the slides are available to anyone with a browser.

My name came up in the Hot Topics session, in regards to how browsers are listening and designers can report issues to me. I'd like to re-enforce this as I think it is an important point. We want to create as little problems as possible for designers and developers, so if there are any major (or minor) bugs in Opera that are causing you problems, please come to me and we'll look into fixing them. If you have a test case for the issue that is even better. The IE team get a lot of suggestions on what fixes developers want, and it would be helpful for us if we get the same.

I was talking to Andy Budd at the conference party, and his idea of a CSS 2.2 came up in the questions to Håkon. I personally think it is a good idea and it is getting some traction. I'm not sure it should be called CSS2.2 as CSS3 is already very modularised, but the naming is irrelevant. I'd like to see the CSS3 that has been implemented, such as all the selectors and the things Dave Hyatt has been working on adding to Safari (border-radius, multiple background images etc.) and making them into a common baseline that all browsers such concentrate on adding in the near term.

Another thing Andy mentioned, and a few others such as Dan Cederholm (whom i also had an interesting conversation with) brought up, was being worried by HTML5 due to adding the Font element back to the spec, and how this is a bad message to send out to developers. I agree here, but I understand why it is there. When we are working on compatibility at Opera, we see sites that still use these elements that shouldn't be used today, and when there are errors the fallbacks are often different between browsers. The people writing the spec are trying to define the error conditions of all these elements, so that user agent implementers know how to behave in a cross browser compatible way. Now this is great for browser implementers as we can hold a spec us and say things should behave as it says and we will behave just like the other browsers, but it is bad for designers reading the spec, as it pollutes it with bad mark-up that shouldn't be used and makes the spec more complex to read. It is more work, but I think there should probably be two specs. A full version for the browser manufacturers, and an abridged version for developers, that only contains the recommended elements and doesn't include all the error conditions. That way both sides will win.

Somewhat related, on the compatibility front, my third name drop of the conference was when Molly mentioned the work we were looking to do in regards to sharing test cases between browsers through a trusted third party. If we can pull this off then it will be another strong weapon to enabling browsers to be as compatible with each other as possible, and removing the frustration developers have when browsers act differently. It is time that browsers compete on quality and features and not on standards.

Dan Cederholm's talk was very interesting, and inspiring, and the the topic of Microformats came up again. Opera recently added Microformats to some of its sites, and it is something we are very interested in. Andy Clarke's talk was as inspiring and funny as usual. The topic was related to web design around the globe, and as I work with web sites from every corner of the web. He mentioned web sites in the far east having more cartoony feel, and that is certainly something I've noticed while working on Korean sites. Our Japanese site is translated in house at the Japanese office, so it is certainly something we could look into localising the style and interaction to see if it makes sense. We have over forty nationalities working for Opera, so we have the local experience to look into this more closely.

On thing Joe Clark hi-lighted in his session was the use of text resizing and zooming in different browsers, mentioning Opera as having one of the best implementations. It was good to see our accessibility support getting noticed, and we are hard at work improving our accessibility across the board for future versions. working with screen readers is an important part of this. Opera takes accessibility very seriously. A couple of developments could make our zooming support even better in the future. The first, which I've mentioned previously on this blog, is that internal versions of Opera (and the Nintendo Wii) support SVG as a background image in CSS. This allows scaleable decorative images to be added to a design, which look great no matter how much the user zooms in. The second is the ability to import fonts through CSS. Håkon predicted that we would see support for this with-in a year. If this comes true, then there will be less need to use images instead of real text for headlines and such. Text of course scales much better than bitmap images.

There was a presentation by Jeremy Keith on Bullet Proof Ajax. It was very clear that much of what he talked about that is primarily for accessibility reasons, is also perfect for the mobile web. I think this is a message that should be put across more, and can be an area that people in the accessibly field can take their skill sets across to. One good example of this is Opera Mini, which uses the Opera rendering engine, but due to the client server architecture where everything is rendered on the server and sent as a compressed binary, it can't handle Ajax or some JavaScript like it's big brother Opera Mobile. It isn't a binary choice as it does support some JavaScript, just as screen readers also do. Using Hijax means that Opera Mini will get the fallbacks that enable it to work. Twitter was an example of a site that broke in Mini due to using Ajax to submit posts. We asked them to do capability detection to send a regular form post if xmlHttpRequest isn't supported, and now it works brilliantly in Mini.

@Media was the last major none MS specific conference that Molly will be presenting at. She pre-announced this, but it was more of a shock that Joe Clark also announced he would retire from working in the web accessibility field. I'm not fully sure if this means he will stop presenting at conferences on web standards in general. Of course, both will be sorely missed. The web conference world may be a little less contriversial without them both. It seems like it is a time of change on the circuit. But as they say, the Queen is dead, long live the Queen. It is maybe an exciting time, where some fresh faces can make a name for themselves, and the mantle can be passed. I really wanted to see Jeremy Keith's presentation, so I sadly missed Hannah Donovan's session with Simon Willison, but by all accounts it was fantastic. It's great to see new people stepping up to the mike and sharing their knowledge. Simon of course has been around for a while now, but I haven't seen him prsent a session too many times in the past. His OpenID presentation at XTech was fantastic as well. John Hicks also marked his session speaking debut at @Media. A speaker I'd like to see more of is Ian Forrester of BBC Backstage, who I've never seen give a full presentation, but was fantastic and very witty when doing the 20x20 lightning talks at XTech.

It's the season for end of year lists. I thought I'd create my own wishlist for 2007, aimed towards the world's web developers and designers. I hope by this time next year, I can look back and see some of these issues resolved or improved across major and minor sites alike. Without further ado, here is my list:

1. Adopt Object detection, consign browser detection to history. Although browser detection can be useful when working around specific browser bugs, it is most often used in inappropriate ways, such as blocking a browser entirely or giving a browser a different path through the code, when the regular standards based path would work fine. A good example of where Object Detection would work better is with rich text editors. Opera has often been blocked from working with these, because Opera didn't support contentEditable or designMode -- the building blocks of many rich text editors -- until Opera 9. If these editors had used Object Detection to detect the presence of contentEditable or designMode, then Opera 9 would have suddenly started working with these editors, without any change on their part. also bare in mind that using browser sniffing to work around browser bugs can also be dangerous. I've seen many scripts that work around bugs in Opera 7 and below, that have long been fixed. Because they just detect Opera, then the old workarounds are still applied and break the modern versions. If browser sniffing has to be used then it should be versioned, so that later browsers are not affected. Make sure the browser vendor knows about the bug you've hit however, so that they have a chance to fix it. This of course runs the risk of the bug not being fixed in the next release, but if the browser vendor knows about the issue and it has been confirmed, then it is their issue that it hasn't been fixed. A good article on Object detection has been written by Hallvord at Dev.Opera.

   One word of warning about Object Detection. Don't test one object and assume support for other objects, or that support for one object means that the user agent is a certain browser. Many compatibility issues are found where authors test for the existance of document.all, and either assume the browser is Internet Explorer (not always true) or that the browser will support other IE DOM extensions, or technologies such as Active-X or VBScript (also not always true).

2. Adopt Graded Browser Support. This is a technique that Yahoo!'s YUI team put into practice, and has been used by others, such as the BBC, for a long time. When was the last time you had a major browser issue on the BBC site, with a decently modern browser? The concept of Graded Browser Support, as published by Nate Koechley, is that their are a number of grades or tiers of browser support on a site. In the top grade, these browsers are given full support such as QA resources and bug fixes when issues are found. The next tier below that are untested browsers. These are browsers that are still under active development and are assumed to work, but not explicitly tested by the QA department (or yourself if you're a small team or solo developer). The key here is that even though the browser may not be tested, nothing is done to stop the browser from working, such as an Upgrade your browser page or broken code. If there are issues with these browsers then they will most likely be looked into, especially if a solution is presented. The final tier are the old browsers with known issues, such as Netscape 4. These will not be blocked, but will be given a reduced, but accessible experience. This could include not sending any CSS, or JavaScript, just raw HTML, with server side logic. If you have written good quality HTML, with accessibility in mind, then your site should work fine this way for old browsers and text based browsers such as Lynx. Linked with Object Detection, the adoption of this approach by major sites (such as AOL, Google, Microsoft and Yahoo!) would seriously reduce the amount of needless blocking of browsers and the potential customers that are using them. I wonder how much revenue is lost by blocking users that would have otherwise purchased something or used a service, but were blocked by browser sniffing. On sites that sell high ticket items, this potential loss is magnified.

3. Use semantic markup. This is a well known area, and improving every year, but as always there is room to improve. Many new sites are still built with tables and presentational images inside the markup. I think that it is often a sign of if a developer/designer is a real craftman/woman or a cowboy by how clean their code is. We want more craftpeople in our industry. As well as the structure of the markup, I still often see class and ID names that are presentational and not structural. There is little point in removing a colour tag to set the colour in CSS, if one is going to use class="red" in the markup. Imagine the confusion when someone else looks at the code and the text has actually changed to green in a subsequent redesign, or the left-nav has been moved to the right. I was thinking of proposing a standard set of ID/Class names for common structural elements that could be defined in a Microformat, but I just noticed Andy Clarke has a similar idea minus the mention of Microformats, back in 2004. I still think this would be useful, especially for new developers, search engines and browsers. If a browser or search engine is aware of the semantic meaning of sections of the markup then it could lead to some interesting possibilities, especially with things like reformatting pages for mobile screens or for accessibility. More about this at a later date. Speaking of Microformats…

4. Make use of Microformats. The semantic web has becoming more popular this year. Not via RDF and OWL, but via tags on blogs and social networking sites, as well as RSS feeds and the adoption of Microformats. Microformats are very interesting as they give semantic meaning to markup without having to define a new standard that is supported by all the browser vendors. Being able to use hCard for contact details and hCal for calendars, enables interesting features such as the automatic detection and conversion from data on a web page to a form that can be downloaded and added to your address book and calendar software. If search engines start using this data, then finding information and aggregating it could become much easier. Some major sites have already started using Microformats on their sites to markup data. Yahoo! use hReview to markup reviews on Yahoo! Tech Upcoming.org etc, while Apple uses hCard in their new .mac webmail. I hope to see the use spread across many other sites and services, big and small.

5. Think beyond the desktop. The mobile web is taking off and will continue to do so in 2007. Opera Mini alone had over 1 billion page hits, well within its first year of release. The current run rate is much higher. The far eastern markets are particularly strong, as well as places, such as Africa and India, where people may only own a telephone and not have access to a computer. The successful launch of the Nintendo Wii, and the buzz surrounding the browser, has shown there is much interest in surfing on none traditional devices. To stay ahead of the game, designers have to stop thinking about just the desktop and high resolution displays, and take a look at a host of different opportunities. Many markets are saturated on the desktop by a number of big players, but there is little content out their that is ideal for the mobile and devices segment. Filling this gap could become very profitable. Making sites work great on a handheld needn't be a huge task. For those that have good structural mark-up, all that is often needed is a handheld stylesheet, that lays out the page to fit into the confines of a small screen, and hides the unwanted content. For more complex sites and mobile specific services, then a new mobile sister site may be more appropriate. Opera offers the handy Small-Screen rendering mode on the desktop browser, to make testing mobile designs much easier and cheaper.

That is all for now. I may add more as I think of them. It's new years eve, so I must rush out and celebrate. i hope everyone has a great new year. If I get a list of suggestions, I may publish a list of most requested features, standards and bug fixes that developers want Opera to add for the new year.