There are often cases when web designers wish that browsers support more web standards or fix that pressing bug they always come across. Just how difficult can it be to support all of CSS2.1 or XHTML 1.1 or such? It can't be that difficult, right? Well, unfortunately it often is. I've just been thinking about the many issues we face as an alternative browser, and I though I'd share a little look into what we deal with when producing our rendering engine. This excludes everything else, such as the interface and features of the browser.
Types of issues
There are three broad categories of bugs that we can face when developing a rendering engine:
- Browser issues
- Web site issues (known as web or otw bugs at Opera)
- Specification bugs
Browser issues are bugs and issues that are caused by our browser working incorrectly according to the specification or the de-facto-standard. These are the issues that Opera has to fix in order to be a fully standards compliant browser or work in major web sites. Web site issues are where a web site has bugs due to not following the spec correctly, or deliberately targeting our browser. Specification bugs are where the official spec has issues, such as specifying something that doesn't work in the real world or using vague wording that can be interpreted differently by different browsers. As can be seen, there is more than just following the spec and expecting all sites to work. It is not just this simple however, as each broad type of issue has a number of sub issues types.
The first type of browser issue is where we lack support for a specific part of a standard (such as border-radius in CSS3 for example). This is the part that many developers clamour for, and a very important part of developing a browser. Then there are browser specific extensions. These are generally something we don't want to add, such as ActiveX, but there are cases when it is important due to many sites using that feature or there being no standards based equivalent. Designmode, ContentEditable and xmlHttpRequest are examples of these, even if they are becoming official standards post implementation. These are often not trivial to add as there needs to be a lot of reverse engineering to work out how they should work. As they are not official specs they often don't have a spec to base the behaviour on or public test cases that can be used in the QA process. There is also the question of if we want to be bug compatible with the browser that created the feature in question, even if the quirk doesn't make sense. Added to this, there is the matter of standards and quirks mode, where a feature can act differently depending on what doctype the developer uses.
After missing features there are bugs in already implemented features. Browsers are complex pieces of software, so all have many bugs. The bugs that most people complain about is when a browser doesn't behave like the spec (or other browsers) behave. These are obviously also very important to get fixed as they cause issues that need to be worked around by developers, or leave the site working incorrectly. The bugs people often forget about are the bugs in error handling, where the browser would work correctly if the code was following the standard, but most people don't read the spec and can write invalid code. It is very common that sites don't validate and don't even use a doctype, so resort to the less specified and more murky world of quirks mode, where it can be a nightmare to work out what the browser should handle the content. This is one of the areas that HTML5 looks to specify better. If the error handling is different to what the spec states (if it is defined there) or Opera behaves differently to other browsers then this could be seen in the long term as a Opera bug that needs to be fixed. In the short term Open the Web can be used to contact the site and suggest the standards compliant way to do what was intended (such as include missing quote or whatever). This benefits the site in question as it is more likely to work on more browsers than relying on error handling, which is inconsistent at best. These two bug types can be broken down into two more sections; those that affect a lot of sites or very popular sites, and those that affect just a few sites or very minor sites. It is obvious that we have to concentrate on fixing issues that affect the most users and developers, so these get higher priority. These can often take a higher priority than adding new standards support, and take just as much work. If we have a bug in something like Google.com, even if they don't write to spec, it will affect many millions of users many times a day.
Web Site issues
The next type of web bug is when a site uses either a vendor specific extension to a standard (such as IE or Mozilla DOM extensions) or vendor specific technology (such as ActiveX or VBScript). This sometimes uses browser sniffing and can be included above, but often just is used for all browsers. For example, many video/music sites don't work as they need ActiveX to include the Media Player plug-in that uses DRM, and doesn't exist as a Netscape API plug-in. As mentioned above, for vedor specific extension they can be added into the browser engine if there is a need for this, but that is long term and not always desirable. If there is a standards based solution then open the Web will contact the site and suggest the alternative way to do the same thing. Sometimes there is other solution and the feature has to be added or the site has to stay broken. For vendor specific technology such as ActiveX there is mot often no way to add that technology, without unreasonable amount of work, or restrictions. These are often a lost hope until the site in question redesigns. These issues can also be broken down into issues with top sites and with the long tail. Again top sites will always get most priority as they affect the most users.
The final type of bugs are specification bugs. The w3C, or whoever writes the spec in question, have to be contacted about these issues, and everyone has to agree what is the correct way that the spec should be written and the feature implemented. If Opera ends up on the losing side of a spec change then it has to fix the bug to make it work like the new spec and other browsers. This will render older versions incompatible with the new spec. New versions of a spec can take a long time to be accepted, so these issues can be long term, and with no clear right way until the spec is changed, it is difficult for web designers to make something work cross borwser when using the feature in question.
One of the things we've been focused on is increasing our real world compatibility with Kestrel, so I'm very much looking forward to its release. That doesn't mean we've stopped adding new standards though, as I've hi-lighted previously and we'll hopefully be able to add more before release time permitting.