Slightly ajar

While at the Web App Summit yesterday, I was sitting next to Jeremy Keith and mentioned I was quite tired as we were racing with WebKit to become the first browser to pass Acid 3. Jeremy then posted the following fairly humorous Twitter post (edited for more family friendly language):

Suggesting to David Storey that, instead of bickering with Webkit about acid3, they just whip out their [male body parts] and start measuring. - Jeremy Keith

Eric Meyer replied on Twitter with the following:

@adactio +1 on that. Not only would it be as productive and relevant, but also would be done right away. Plus they could sell the video. - Eric Meyer

Firstly, it would be anatomically impossible for our female developers to do this. More seriously, I'd have to disagree with Eric's reply. The extent of our bickering with WebKit is pushing each other to pass Acid 3 quicker. This can only be a good thing. You could argue how relevant the tests are in the Acid tests, but that we are both committed to improving our standards support is only a good thing (and much better than measuring things).

I'm not quite sure how making sure we have support for the likes of RGBA, HSLA and Web Fonts, while ensuring at least some support for SVG. These are quite important web standards. When IE finally supports Acid 3, we'll actually be able to start looking at using SVG in real web sites.

One of the things this test shows (as well as Acid 2) is that developers love competition. I think this is human nature. It is much more motivating to fix difficult issues, if there is a test to pass with a success criteria. Becoming the first team to pass that test is something to be proud of. As people are competing, issues in the spec are often found and fixed faster too. I'm really glad Opera and Apple are going toe to toe improving standards support. I just wish it had some of my favorite standards that I want to be supported: the various properties from the CSS3 backgrounds and borders module (although the spec isn't finalised yet), and SVG as a CSS background-image.

Currently WebKit and Opera only have performance issues left, so any further progress wont benefit standards so much, but I wish Mozilla and Microsoft luck on passing the DM and rendering test. Maybe Mozilla nad Microsoft can have their own personal duel together.

On the video comment, Opera supports Ogg Theora, while WebKit supports Quicktime in the HTML5 video element, so the videos would be incompatible anyway

We've just released information that Opera has overtaken Safari in its Acid3 score. The current score is now 98%, to Safari's 96%. I'd not be surprised if it improves further in the near future. This work is being carried out in a post Core-2.1 build, that most likely wont be included in Kestrel. Check out Anne VK's blog, or CSS3.info for some more information as it comes in.

Update: Working into the night, our core developers have fixed the final 2%, making Opera the first browser to reach 100% in the DOM tests. The test hasn't been passed yet as there are some rendering issues, and it hasn't been released in a public build yet. That experimental build should be released on Opera Labs in the near future.

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.

Never letting being late get in the way of a good story, I'd like to celebrate the launch of Opera 9 this past Tuesday. During the launch I was away in Germany at the World Cup match between England and Sweden. It was a great match but I was a wee bit guilty that I was there having a great time while other people were slaving away with the big launch. Although along with Mike, I've put a great deal of work in trying to get sites ready for the launch, be it through contacting sites, patching or working with developers on their issues in Opera 9.

Site patching is a difficult business as we like to give sites time to respond before applying a patch or user agent spoof, so not every patch needed for major sites was included for the launch, especially as we've been away in recent weeks to meet with developers, but they will be applied in the coming days. User agent spoofing can also cause unwanted side effects, such as a recent change with masking as Mozilla on my.yahoo.com. While this fixed three issues it was put in to fix, it broke another part of the site, where links now always open in a new tab due to the use of a Mozilla only property.

I've seen a number of of forum posts by people that say Opera 9 was not ready for launch, and indeed there are some issues reported by web developers I've been working with that have not been fixed. Although there are some issues, there will always be bugs in even the simplest of software applications (and a browser is far from being simple), and as the old adage goes real artists ship. While I'm sure everyone would have liked more time to work on Opera 9, it is a much better product than Opera 8 and we had to ship it sometime. I think the benefits of releasing it now outweigh the cons. Having the browser out there in the wild as a none-beta product will push developers that only support released products to add support for Opera in sites that require Opera 9 such as rich text editing or sites that broke due to a bug in Opera 8 or below. Opera was also delayed slightly due to the great effort put in by the developers to add support for DOM level 2 style such as document.stylesheets. This is used by a lot of important sites and I for one am glad we managed to get it included for the launch. I think I'm right in claiming that Opera is now the first browser to support all of DOM Level 2. That is a big thing and a few bugs shouldn't overshadow it

Not that bugs are unimportant. Far from it. Work continues on fixing known bugs and important ones will be included in the first point release of Opera 9. I'm still talking with sites and script authors on fixes that are needed on our and their side to work in our browser. I'm confident important open issues will be fixed soon. Nothing should detract from what is a top quality product, in my opinion, and the passing of the ACID 2 test and our support of the DOM level 2 spec is testament to the quality of our rendering engine and our commitment to web standards and a open web.

After partying with Monica and co, It's time I sign off and get some sleep, I've got a web to open in the morning…

We've been very active recently in finding issues on Korean web sites, and reporting these to the site authors. Korea is a quite unique market in that they have very advanced devices and one of the highest take up rates of broadband internet access in the world, yet Internet Explorer has a huge market share in Korea, so almost every site I've tested is designed and tested for IE and Windows only, without use of web standards. This causes big problems for every other browser and platform, including Firefox, Safari and ourselves. Some issues are bigger with no easy solution such as the use of Active X, but the majority are due to making use of quirks and bugs in IE and often only need to change one word to make them work in all major browsers. Many of these issues can be found in my previous post on common web site issues.

We'd like to do all we can to fix these issues and promote web standards, enabling Korean sites to work on any device, any platform and any browser. Users should be free to make their own choices on how they access the web. To help our push in this area we are extending Open the Web's efforts into Korea. Opera's team in Korea is growing as we speak, and Irene has recently been hired with part of her responsibility to work with myself and the rest of the team on Opening Korea. I'd like to wish her welcome, and look forward to seeing cross browser development take off. If you are Korean and can't access you're favourite sites, feel free to contact me and I'll make sure the issues get looked into.