Short Answer: The biggest problem is not about Opera's consistency with standards. It is that web developers don't test in it.
Long Answer: The issue is the following:
The damage from the first browser war was a fractures into "built for netscape" and built for IE". Mozilla's quirks come from the netscape camp, actually it has poorer IE quirk handling than Opera. Opera tried to handle *both* sets of quirks, because browser sniffing has been the dominant way to quickly fix issues:
if name=IE
blah
else name=netscape
other blah
endif
Opera must handle one quirk or the other and must try to reverse-engineer exacly what they are doing. With layout this can be tedious as the combinatorial possibilities are large.
Opera designed a masquerade, it would pretend to be another browser, and set about coding round the quirks. Those quirks are horrid to code round, and occur even in "standards" mode. Opera has tried very hard to handle quirks gracefully. First it emulates major quirks of IE and Netscape as best it can. Secondly in recent versions it has browser.js which fixes sites on-the-fly (hooking custom scripts into the page loading process) and auto-updates those fixes. Finally site preferences dynamically change its masquerade behaviour per-site, again auto-updating.
In my experience, Opera is a lot more compatible now than it was a couple of years ago (9.5 is a great step forward here too). *BUT* browser sniffing is back with a vengence with Web 2.0 (Google being the worst offender), and so is coding for IE or
NetscapeFirefox. The biggest problem is not Opera's compatibility. It is that web developers don't test in it.
Developers hack something and it works in Gecko. Then they hack something that works in IE. Then they ship the product. If they strictly code to standards then it is most likely to also work in Opera and Safari, but not guaranteed. This is especially the case when Gecko has got the spec wrong, as has happend causing clear Opera incompatibilities recently.
Opera have made some positive steps: Opera now powers Adobe CS suite (Dreamweaver, Device central) which will slowly get developers aware of rendering and functional bugs in it. And they are furiously coding new web developer tools to make Opera a better browser to develop in. The idea is to get parity with Firebug. They have opened
http://dev.opera.com to provide developer docs that have an opera-aware bent. And they have a small team who "Open-the-Web" - find bugs in web sites and contact the owners with possible solutions. But the web is big and Opera's resources are small.
I know this sounds very soft on Opera from my part, but I really believe Opera has and is trying its best to be compatible, but they are running against a huge Sea of complexity. Things are getting better and the fact that the mobile-aware web is growing will benefit Opera, as will the release of the dev tools to get people developing in it.
Show Posts
On my XP VM I see no more than 30MB working set, 25MB private bytes with all plugins installed. And surprisingly, it triggers faster than FARR (FARR configured to use more memory without more than the default locations indexed). FARR consumes about 10MB of working set, but I'd gladly trade more memory to get it triggering faster.
), who drove the MacFUSE project and wrote GrabFS also wrote ProcFS, a FS representation of process and includes hardware etc. For example, the iSight camera is available as a file to grab cam shots off by copying that file etc.
