I have a film scanner (cost £500 a couple of years ago â" second hand, it's been out of production for about a decade). It isn't supported by SANE, there are some very limited F/OSS drivers for Windows which don't even work for most of what I have the scanner for (and don't work on Win64), and the official drivers work on OS X/PPC and Win32 (up to Vista â" don't know what stops it running on 32-bit Win7).
I run WinXP in a VM (without networking, except for to host) for it, as it's practically the only way I can keep it running for the indefinite future. That said, I don't expect the majority of users to be happy with VMs, given a mixture of working inside and out, and the different filesystems, and the different networking.
It's depends what you're doing. I've spent a while dealing with the Scottish Corpus of Texts and Speech, and there the size is around four million words. If you're doing anything based upon dialects, size does make a very real difference, because you're interested in the density of usage by area. Personally, even in a non-linguistic context, I find it useful to know whether someone in x is likely to know (by virtue of using) a word y.
Bear in mind that Opera is far from the smallest browser which funds a viable business: yes, we are probably the smallest browser that attempts to compete on the Desktop (and certainly growing in absolute terms; whether we're growing as fast as the market is less clear, however), but there are other browsers out there.
Consider browsers such as NetFront and SkyFire: both of them have radically different business models (in fact, both ones that Opera has moved away from!), the former developing custom browsers for OEMs, and the latter charging end-users.
In the past year, Desktop has brought in c. 70 million NOK per quarter, the vast majority of which comes from Google, which is approximately equal to 50 million USD per year.
In addition to that, Google is the default browser in Opera Mobile and Mini, but the amount there is far harder to quantity. Note that Mini alone has a userbase (in absolute numbers) equal to that of Desktop, so it seems reasonable to expect a considerable amount of money there as well.
Opera's monetization strategy for its desktop browser revolves predominantly around search. Google is Opera's global search partner and provides the vast majority of desktop monetization.
...and...
Today, revenue generated from Opera's mobile consumers emanates primarily from mobile search, the Opera Mobile Store and content partnerships.
Google is Opera's default search partner for Opera Mini and Opera Mobile world-wide.
Both go on to mention other, smaller, search affiliation deals.
The MiG-25 was obtained by the West after a Russian pilot defected, aircraft and all. It had nothing to do with a Soviet aircraft being in airspace without permission.
PHP is far less dynamic than JavaScript, Python, Ruby, etc., though: function and class assignments are constant (though first-class functions exist in PHP 5.3, they're rarely used and probably aren't worth spending *too* much time optimizing for). The main source of dynamism is the dynamic weak typing, everything else is far closer to most compiled languages.
NaCL binaries are not portable in the same way I can't install the FireFox's Windows binaries on Linux (or the armel ".deb" from packages.debian.org on my amd64 computer), but honestly, who cares? Mozilla and Debian guys just compile it for each supported platform. There is also the possibility of creating a "fat nexe" that supports all platforms.
And what happens when I'm browsing the web on my MIPS-based TV? I'm at the mercy of the website author to specifically support my architecture. Today, I can visit any website and it will work. There is no dependency on any architecture specific stuff. Most developers will only bother compiling for x86 and ARM in all probability, which will hurt anyone else.
Is open source code on an open source browser. I would prefer it being a plugin (I think at some point there was one) so I can run it in all my browsers. But this is no different than any other proprietary feature on other browsers. I'm currently using Mozilla's proprietary "crypto" JavaScript API for an application, and it only runs on Mozilla's browsers. Not convenient, for sure, but what should I do? Not use the feature at all? Or try to make something valuable from it, so other developers might consider incorporating it?
It is a plugin... using a non-standard, non-documented plugin API, which nobody apart from Chrome supports or has any intention of supporting (it's a huge amount of badly documented, totally web irrelevant, anti-Open-Web chunk of code --- why should anyone take it in?). If they had used the standard plugin API (NPAPI), it would work today in every browser.
And I'm sorry, but this is fundamentally different to a lot of proprietary functionality in other browsers. Most of browser vendors are putting in large amounts of effort into removing old proprietary behaviour and specifying anything they wish to keep. Even Apple when it adds new proprietary behaviour to WebKit typically specifies it. Writing a spec is a big deal: it allows anyone else to write a clean-room implementation, which is often desirable (especially for CSS/DOM extensions: it's practically impossible to share much code without all moving to a single engine). Google hasn't released any spec for NaCl (and neither for the Pepper plugin API it relies upon), the spec it has released for Dart is nowhere near complete enough to allow a new implementation (and it had a several year headstart on implementing --- something that makes their implementation very hard to compete with), the spec for WebM is mostly just a dump of the code of the implementation (it's not really a spec: it's just code and the spec just says "match this").
See http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html: LLVM bitcode isn't stable between releases, is still undocumented in sufficient detail to do a clean-room implementation, and is fundamentally designed to be a compiler IR and not a generic interchange IR. Trying to use it as the latter will only lead to pain.
I live in Europe. I travel by train (long-distance) typically several times a month. To be fair, with where I've lived almost all my life, I've rarely had (fast) trains less frequently than hourly. Maybe I've just been lucky, but I've never found it to be any issue.
Assuming speed limits remained unchanged, my normal route by car would take around 6:30 hours. Compare this to worst case by public transport: 5 minutes walk to subway, up to 15 minutes wait (though I believe that would only occur if I was trying to depart at 11pm!), 10 minutes on the subway, 5 minutes to the station, an hour until the next train (as if I had just missed one), five hours on the train, and then 10 minutes walk. All in all, 5:45 v. 6:30, worst case for public transport, average case for car. I'd personally certainly rather sit on a train for that time than sit in a car. The possibility of moving around and the fact I can have a table to work on are all massive benefits.
When I lived in Sweden, there were fast trains to Stockholm twice an hour. Certainly nothing that required wasting hours waiting.
Indeed, in all my travel around Europe (and I really can't comment on anywhere outwith of Europe, having only been outside of it once!), I can only recall once having any particularly long wait, and that was getting a TGV from Paris-Charles de Gaulle â" the only reason for that wait was because I'd giving myself around two hours to get from the plane, through security, pickup bag, and onto train, instead of allowing half an hour. I made it to the station in fifteen minutes. The flight I was on was normally at least half an hour late landing.
What self-driving cars operate at 350 km/h (220 mph)? Heck, how many manually driven cars do? Very, very few. Sure, you might need an extra half hour at each end of the journey getting to/from the station, but given a long-distance journey your total travel time will still be less.
For mobile devices, the RK29xx provides hardware support. For desktop computers, some codecs are currently decoded by a mixture of dedicated hardware and shaders at a driver level (I believe AMD do this for MPEG-2, most commonly found on DVDs), so even for hardware that's already shipped adding GPU acceleration through shaders is entirely possible (and for GPUs that support OpenCL, it can be done in a generic manner).
Indeed. You're not allowed to have anything that allows third-party code-execution on iOS, so a JavaScript interpreter is instantly out. You might get away with having an HTML parser (though it does duplicate built-in software, so might still get rejected), but that's not massively useful in this day-and-age. This is the reason why Opera Mobile and Firefox for Mobile aren't on iOS.
In the Scotland at least I believe the mall's guards could claim they have performed a citizen's arrest for trespass (for the mall is private property) in lieu of any police being present.
What Apple did for PPC to x86 was fairly complex, by emulator standards: any call into a system library simply changed byte order of arguments (because of the endianness change from their big-endian PPC OS to the little-endian x86 --- x86 to ARM wouldn't have to do that, as most ARM systems are LE) and called the native x86 system library. This cut out the majority of slowness when dealing with OS-provided functionality, be it painting, OpenGL (thus the reason why many recent games were playable through the emulator), or other such CPU/GPU intensive tasks.
By emulating as little as possible, they got quite reasonable performance. Could the same be got on Cortex A15 CPUs, which I expect the majority of uses of Win8/ARM will use? It doesn't seem impossible --- sure, they won't be as quick as high-end hardware, but will likely still be quicker than many current netbooks, so performance equal to that of a netbook from a couple of years back seems plausible.
Opera marks the page as insecure if it fails to get a response to the OCSP request (IIRC since 9.5), though everything else continues as if the OCSP response was such that the certificate is valid. Fail-secure seems like a rather dumb strategy, though is what the majority of the market does.:\
They're all well-known Gecko people, though, and have a significant advantage, even if they don't fix the bugs themselves: they likely know who to CC such that the person CC'd will be interested in it and likely to fix it.
Equally, Jesse's a security specialist: I wonder how many of his bugs got fixed quickly because they were possible security bugs.
Many middle- and almost all high-end servers have hot-swappable RAM. When you're dealing with large numbers of RAM modules, and downtime is expensive, you want to be able to swap as much as possible at run-time.
A large part of the reason HTML 5 was written at all was to standardize large parts of the behaviour in web browsers that the web relies upon --- until a few years ago, huge parts of the budgets for browsers were spent on reverse-engineering other browsers (latterly IE6, before than NN4, etc.), which resulted in a hugely anti-competitive environment. When work on HTML5 started, it was incredibly hard to write a browser that worked with the vast amount of already deployed content, and what specs there were were practically useless, in part because the vast majority of content on the web doesn't follow them. Sure, you could refuse to support anything that isn't conforming, and "point out they're shit" as you so eloquently put it, but when Google doesn't work, nobody would care about your browser, and use one that does support invalid content.
HTML5's raison d'Ãtre is implementation interoperability, and when you have interoperability between implementations, you then have a hard time defining what should be conforming content and what shouldn't be --- both types of content are processed interoperably. As it is, what is conforming and what isn't has been based largely upon use-cases provided to the WG. If you think something should be changed in the spec, send feedback! mailto:public-html-comments@w3.org is the address! If you do send feedback, do make sure to include justification for whatever change you propose.
Also, what are these comment tags you refer to? ? Supported by old versions of a single-browser (IE is the parser used by both http://validator.nu/ and (through a programmatic transformation to C++) Gecko, and provides support for SAX, DOM, and XOM APIs. provide a Python implementation that offers a drop-in replacement for XML parsers in most Python XML toolchains.
Such tools, that finally offer good compatibility with existing content, combined with changes in the spec to try and unify HTML and XHTML further (if the XML syntax were so discouraged, why would there be efforts put into unifying them?), such as HTML parsing HTML elements into the HTML namespace, should make it entirely feasible for toolchains based upon XSLT and the like to use HTML input/output.
The whole living standard debate is one where I think many have missed the point: the a look at something like CSS, especially Level 3. Many drafts have multiple implementations, and implementations will continue to evolve over time, and move on to Level 4 drafts as soon as they appear, so what meaning does whatever you call "Level 3" have when people are only interested in implementing the latest drafts?
To speak as an Opera employee (albeit only for the past couple of years â" two years tomorrow, actually) for once:
While certainly some people in the company vehemently defended it, as you put it, the number of people internally who'd say that it wasn't a problem for us to fix were in a minuscule minority. Certainly, from around a decade ago, we've ended up with more non-standard IE extensions implemented than FF have, which led some sites to work better in Opera than FF, though on others (to this day) sends us down the wrong code-path due to broken browser-sniffing.
I'm not really convinced it was the market that pushed site-compat to get to where it was today: it was more the gradual effort over a number of years towards it, and in general on the web you're either fairly badly broken (as Opera was) or stuff pretty much works (as all major browsers are like now).
To be fair, there have also been cultural changes within the company. For example, we have over three times the number of automated tests today than we had when I started, which has massively reduced the number of regressions, thus allowing developer time to be spent more on fixing bugs once.
Note that with 10.50 we introduced an entirely new JS engine, which worked with pretty much the same amount of the web as the one in 10.10. That's what I've spent the majority of my last couple of years working on, and the fact we shipped it working just as well as the previous engine, having developed it in less than half the time that it took V8 to reach beta, is a testament to our testing nowadays.
We don't have the thousands of users of every nightly FF and Chrome have â" we very much have to get it right first time, and that presents a far harder challenge, yet now, we are succeeding. Hurrah!
One final note on Google Apps: they don't officially support us, quite often doing stuff using non-standard stuff (often with one codepath for IE, using non-standard stuff; one codepath for FF, using different non-standard stuff; and yet another codepath for WebKit, using yet again different non-standard stuff), making it hard for us to know what to do. (Do we try and copy the non-standard FF/WebKit stuff? They're trying to get rid of a lot of their non-standard stuffâ¦) Hopefully, sometime soon, this will change, and we'll be officially supported.
I was â" for some reason, as thinking about this now it makes little sense â" hypothesising that the majority of callsites would have an immediate argument. http://jsperf.com/math-sin-cache/3 shows that in the case of having an immediate argument, in Opera at least (which is unsurprisingly what I know the perf characteristics of best), using a cache is significantly faster; Chromium is giving somewhat unstable results, showing between a 1â"5% difference between Math.sin and a cache; Firefox/QtWebKit both make Math.sin significantly quicker in the immediate argument case. Of course, in the case when the argument is largely polymorphic, property caches stop providing decent performance, and calling Math.sin becomes quicker.
I also never claimed that implementing floating point maths in JS using integer maths was quicker than using the native Number type (or made any claim about the relative performance at all), merely that within JS engines not everything is a double, and that there is (internally) a separate int32 type, so the performance wouldn't be quite as bad as was claimed (which is certainly far from any claim that it's going to be at all quick).
(Disclaimer: I'm one of the test engineers on Opera's JS engine.)
Although JS as a language has a single Number type almost identical to IEEE 754 doubles (the only difference is there is only a single NaN value in JS), every implementation, going back to Brendan Eich's original, has always implemented the JS Number type as two separate types internally: signed 32-bit integers, and double-precision floats. Even today with modern JS engines and modern CPUs, integer maths is still substantially quicker than floating-point maths.
Equally, they won't actually be dynamic object property lookups: the property lookups will be cached. There will likely be fairly little difference between Math.sin/cos/etc. calls and a lookup in an object.
Up-front disclosure: I've been involved with HTML5 since 2006, and worked for Opera Software since 2009, and (among other things) am QA for HTML/DOM/etc. implementation.
2022 is far from insane: CSS 2.1 has been under development since 1998, and is yet to reach REC (though hopefully will this year) â" and CSS 2.1 is just a minor update to CSS 2.
Yes, for most practical purposes the spec will be done long before it reaches REC, but writing a testsuite that is considered complete enough is massively-time consuming, and having two implementations passing every test will take time (again, we're still not there with CSS 2.1 after 13 years).
HTML5 will almost certainly take longer than CSS 2.1 because not only does it just clarify prior ambiguities, but it also adds a fairly large number of new features. Also, the ambiguities that are being clarified are often large gaping holes (e.g., there is no definition of how cross-origin access between frames should work, what should be allowed, prior to HTML5) in previous specifications, and as such each browser has its own design for quite what happens in those areas (normally similar except in the edge-cases from reverse-engineering), and quite a lot of those designs will be non-trivial to change to match HTML5 for all browser vendors in places, meaning there will be quite a lot of things that will remain different in the edge-cases for a while.
Note that under what the W3C Process requires today for a spec to proceed to REC neither HTML 4 nor CSS 2 would yet be a recommendation (indeed, such documents are closer to the quality that would be expected of an early working draft nowadays).
Opera doesn't support H.264, and was the first browser to ship a stable release with WebM support (and, heck, the original browser to ship an experimental video element, with Ogg/Theora/Vorbis).
Slashdot Mirror
I have a film scanner (cost £500 a couple of years ago â" second hand, it's been out of production for about a decade). It isn't supported by SANE, there are some very limited F/OSS drivers for Windows which don't even work for most of what I have the scanner for (and don't work on Win64), and the official drivers work on OS X/PPC and Win32 (up to Vista â" don't know what stops it running on 32-bit Win7).
I run WinXP in a VM (without networking, except for to host) for it, as it's practically the only way I can keep it running for the indefinite future. That said, I don't expect the majority of users to be happy with VMs, given a mixture of working inside and out, and the different filesystems, and the different networking.
See http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html, which is a post to llvm-dev which concerns itself with this, as well as the more general unsuitability of the IR for program distribution.
It's depends what you're doing. I've spent a while dealing with the Scottish Corpus of Texts and Speech, and there the size is around four million words. If you're doing anything based upon dialects, size does make a very real difference, because you're interested in the density of usage by area. Personally, even in a non-linguistic context, I find it useful to know whether someone in x is likely to know (by virtue of using) a word y.
Bear in mind that Opera is far from the smallest browser which funds a viable business: yes, we are probably the smallest browser that attempts to compete on the Desktop (and certainly growing in absolute terms; whether we're growing as fast as the market is less clear, however), but there are other browsers out there.
Consider browsers such as NetFront and SkyFire: both of them have radically different business models (in fact, both ones that Opera has moved away from!), the former developing custom browsers for OEMs, and the latter charging end-users.
Opera very much gets money from Google.
In the past year, Desktop has brought in c. 70 million NOK per quarter, the vast majority of which comes from Google, which is approximately equal to 50 million USD per year.
In addition to that, Google is the default browser in Opera Mobile and Mini, but the amount there is far harder to quantity. Note that Mini alone has a userbase (in absolute numbers) equal to that of Desktop, so it seems reasonable to expect a considerable amount of money there as well.
See Opera's financial reports:
...and...
Both go on to mention other, smaller, search affiliation deals.
The MiG-25 was obtained by the West after a Russian pilot defected, aircraft and all. It had nothing to do with a Soviet aircraft being in airspace without permission.
PHP is far less dynamic than JavaScript, Python, Ruby, etc., though: function and class assignments are constant (though first-class functions exist in PHP 5.3, they're rarely used and probably aren't worth spending *too* much time optimizing for). The main source of dynamism is the dynamic weak typing, everything else is far closer to most compiled languages.
And what happens when I'm browsing the web on my MIPS-based TV? I'm at the mercy of the website author to specifically support my architecture. Today, I can visit any website and it will work. There is no dependency on any architecture specific stuff. Most developers will only bother compiling for x86 and ARM in all probability, which will hurt anyone else.
It is a plugin... using a non-standard, non-documented plugin API, which nobody apart from Chrome supports or has any intention of supporting (it's a huge amount of badly documented, totally web irrelevant, anti-Open-Web chunk of code --- why should anyone take it in?). If they had used the standard plugin API (NPAPI), it would work today in every browser.
And I'm sorry, but this is fundamentally different to a lot of proprietary functionality in other browsers. Most of browser vendors are putting in large amounts of effort into removing old proprietary behaviour and specifying anything they wish to keep. Even Apple when it adds new proprietary behaviour to WebKit typically specifies it. Writing a spec is a big deal: it allows anyone else to write a clean-room implementation, which is often desirable (especially for CSS/DOM extensions: it's practically impossible to share much code without all moving to a single engine). Google hasn't released any spec for NaCl (and neither for the Pepper plugin API it relies upon), the spec it has released for Dart is nowhere near complete enough to allow a new implementation (and it had a several year headstart on implementing --- something that makes their implementation very hard to compete with), the spec for WebM is mostly just a dump of the code of the implementation (it's not really a spec: it's just code and the spec just says "match this").
See http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html: LLVM bitcode isn't stable between releases, is still undocumented in sufficient detail to do a clean-room implementation, and is fundamentally designed to be a compiler IR and not a generic interchange IR. Trying to use it as the latter will only lead to pain.
I live in Europe. I travel by train (long-distance) typically several times a month. To be fair, with where I've lived almost all my life, I've rarely had (fast) trains less frequently than hourly. Maybe I've just been lucky, but I've never found it to be any issue.
Assuming speed limits remained unchanged, my normal route by car would take around 6:30 hours. Compare this to worst case by public transport: 5 minutes walk to subway, up to 15 minutes wait (though I believe that would only occur if I was trying to depart at 11pm!), 10 minutes on the subway, 5 minutes to the station, an hour until the next train (as if I had just missed one), five hours on the train, and then 10 minutes walk. All in all, 5:45 v. 6:30, worst case for public transport, average case for car. I'd personally certainly rather sit on a train for that time than sit in a car. The possibility of moving around and the fact I can have a table to work on are all massive benefits.
When I lived in Sweden, there were fast trains to Stockholm twice an hour. Certainly nothing that required wasting hours waiting.
Indeed, in all my travel around Europe (and I really can't comment on anywhere outwith of Europe, having only been outside of it once!), I can only recall once having any particularly long wait, and that was getting a TGV from Paris-Charles de Gaulle â" the only reason for that wait was because I'd giving myself around two hours to get from the plane, through security, pickup bag, and onto train, instead of allowing half an hour. I made it to the station in fifteen minutes. The flight I was on was normally at least half an hour late landing.
What self-driving cars operate at 350 km/h (220 mph)? Heck, how many manually driven cars do? Very, very few. Sure, you might need an extra half hour at each end of the journey getting to/from the station, but given a long-distance journey your total travel time will still be less.
For mobile devices, the RK29xx provides hardware support. For desktop computers, some codecs are currently decoded by a mixture of dedicated hardware and shaders at a driver level (I believe AMD do this for MPEG-2, most commonly found on DVDs), so even for hardware that's already shipped adding GPU acceleration through shaders is entirely possible (and for GPUs that support OpenCL, it can be done in a generic manner).
Indeed. You're not allowed to have anything that allows third-party code-execution on iOS, so a JavaScript interpreter is instantly out. You might get away with having an HTML parser (though it does duplicate built-in software, so might still get rejected), but that's not massively useful in this day-and-age. This is the reason why Opera Mobile and Firefox for Mobile aren't on iOS.
In the Scotland at least I believe the mall's guards could claim they have performed a citizen's arrest for trespass (for the mall is private property) in lieu of any police being present.
What Apple did for PPC to x86 was fairly complex, by emulator standards: any call into a system library simply changed byte order of arguments (because of the endianness change from their big-endian PPC OS to the little-endian x86 --- x86 to ARM wouldn't have to do that, as most ARM systems are LE) and called the native x86 system library. This cut out the majority of slowness when dealing with OS-provided functionality, be it painting, OpenGL (thus the reason why many recent games were playable through the emulator), or other such CPU/GPU intensive tasks.
By emulating as little as possible, they got quite reasonable performance. Could the same be got on Cortex A15 CPUs, which I expect the majority of uses of Win8/ARM will use? It doesn't seem impossible --- sure, they won't be as quick as high-end hardware, but will likely still be quicker than many current netbooks, so performance equal to that of a netbook from a couple of years back seems plausible.
Opera marks the page as insecure if it fails to get a response to the OCSP request (IIRC since 9.5), though everything else continues as if the OCSP response was such that the certificate is valid. Fail-secure seems like a rather dumb strategy, though is what the majority of the market does. :\
They're all well-known Gecko people, though, and have a significant advantage, even if they don't fix the bugs themselves: they likely know who to CC such that the person CC'd will be interested in it and likely to fix it.
Equally, Jesse's a security specialist: I wonder how many of his bugs got fixed quickly because they were possible security bugs.
Many middle- and almost all high-end servers have hot-swappable RAM. When you're dealing with large numbers of RAM modules, and downtime is expensive, you want to be able to swap as much as possible at run-time.
A large part of the reason HTML 5 was written at all was to standardize large parts of the behaviour in web browsers that the web relies upon --- until a few years ago, huge parts of the budgets for browsers were spent on reverse-engineering other browsers (latterly IE6, before than NN4, etc.), which resulted in a hugely anti-competitive environment. When work on HTML5 started, it was incredibly hard to write a browser that worked with the vast amount of already deployed content, and what specs there were were practically useless, in part because the vast majority of content on the web doesn't follow them. Sure, you could refuse to support anything that isn't conforming, and "point out they're shit" as you so eloquently put it, but when Google doesn't work, nobody would care about your browser, and use one that does support invalid content.
HTML5's raison d'Ãtre is implementation interoperability, and when you have interoperability between implementations, you then have a hard time defining what should be conforming content and what shouldn't be --- both types of content are processed interoperably. As it is, what is conforming and what isn't has been based largely upon use-cases provided to the WG. If you think something should be changed in the spec, send feedback! mailto:public-html-comments@w3.org is the address! If you do send feedback, do make sure to include justification for whatever change you propose.
Also, what are these comment tags you refer to? ? Supported by old versions of a single-browser (IE is the parser used by both http://validator.nu/ and (through a programmatic transformation to C++) Gecko, and provides support for SAX, DOM, and XOM APIs. provide a Python implementation that offers a drop-in replacement for XML parsers in most Python XML toolchains.
Such tools, that finally offer good compatibility with existing content, combined with changes in the spec to try and unify HTML and XHTML further (if the XML syntax were so discouraged, why would there be efforts put into unifying them?), such as HTML parsing HTML elements into the HTML namespace, should make it entirely feasible for toolchains based upon XSLT and the like to use HTML input/output.
The whole living standard debate is one where I think many have missed the point: the a look at something like CSS, especially Level 3. Many drafts have multiple implementations, and implementations will continue to evolve over time, and move on to Level 4 drafts as soon as they appear, so what meaning does whatever you call "Level 3" have when people are only interested in implementing the latest drafts?
To speak as an Opera employee (albeit only for the past couple of years â" two years tomorrow, actually) for once:
While certainly some people in the company vehemently defended it, as you put it, the number of people internally who'd say that it wasn't a problem for us to fix were in a minuscule minority. Certainly, from around a decade ago, we've ended up with more non-standard IE extensions implemented than FF have, which led some sites to work better in Opera than FF, though on others (to this day) sends us down the wrong code-path due to broken browser-sniffing.
I'm not really convinced it was the market that pushed site-compat to get to where it was today: it was more the gradual effort over a number of years towards it, and in general on the web you're either fairly badly broken (as Opera was) or stuff pretty much works (as all major browsers are like now).
To be fair, there have also been cultural changes within the company. For example, we have over three times the number of automated tests today than we had when I started, which has massively reduced the number of regressions, thus allowing developer time to be spent more on fixing bugs once.
Note that with 10.50 we introduced an entirely new JS engine, which worked with pretty much the same amount of the web as the one in 10.10. That's what I've spent the majority of my last couple of years working on, and the fact we shipped it working just as well as the previous engine, having developed it in less than half the time that it took V8 to reach beta, is a testament to our testing nowadays.
We don't have the thousands of users of every nightly FF and Chrome have â" we very much have to get it right first time, and that presents a far harder challenge, yet now, we are succeeding. Hurrah!
One final note on Google Apps: they don't officially support us, quite often doing stuff using non-standard stuff (often with one codepath for IE, using non-standard stuff; one codepath for FF, using different non-standard stuff; and yet another codepath for WebKit, using yet again different non-standard stuff), making it hard for us to know what to do. (Do we try and copy the non-standard FF/WebKit stuff? They're trying to get rid of a lot of their non-standard stuffâ¦) Hopefully, sometime soon, this will change, and we'll be officially supported.
I was â" for some reason, as thinking about this now it makes little sense â" hypothesising that the majority of callsites would have an immediate argument. http://jsperf.com/math-sin-cache/3 shows that in the case of having an immediate argument, in Opera at least (which is unsurprisingly what I know the perf characteristics of best), using a cache is significantly faster; Chromium is giving somewhat unstable results, showing between a 1â"5% difference between Math.sin and a cache; Firefox/QtWebKit both make Math.sin significantly quicker in the immediate argument case. Of course, in the case when the argument is largely polymorphic, property caches stop providing decent performance, and calling Math.sin becomes quicker.
I also never claimed that implementing floating point maths in JS using integer maths was quicker than using the native Number type (or made any claim about the relative performance at all), merely that within JS engines not everything is a double, and that there is (internally) a separate int32 type, so the performance wouldn't be quite as bad as was claimed (which is certainly far from any claim that it's going to be at all quick).
(Disclaimer: I'm one of the test engineers on Opera's JS engine.)
Although JS as a language has a single Number type almost identical to IEEE 754 doubles (the only difference is there is only a single NaN value in JS), every implementation, going back to Brendan Eich's original, has always implemented the JS Number type as two separate types internally: signed 32-bit integers, and double-precision floats. Even today with modern JS engines and modern CPUs, integer maths is still substantially quicker than floating-point maths.
Equally, they won't actually be dynamic object property lookups: the property lookups will be cached. There will likely be fairly little difference between Math.sin/cos/etc. calls and a lookup in an object.
Up-front disclosure: I've been involved with HTML5 since 2006, and worked for Opera Software since 2009, and (among other things) am QA for HTML/DOM/etc. implementation.
2022 is far from insane: CSS 2.1 has been under development since 1998, and is yet to reach REC (though hopefully will this year) â" and CSS 2.1 is just a minor update to CSS 2.
Yes, for most practical purposes the spec will be done long before it reaches REC, but writing a testsuite that is considered complete enough is massively-time consuming, and having two implementations passing every test will take time (again, we're still not there with CSS 2.1 after 13 years).
HTML5 will almost certainly take longer than CSS 2.1 because not only does it just clarify prior ambiguities, but it also adds a fairly large number of new features. Also, the ambiguities that are being clarified are often large gaping holes (e.g., there is no definition of how cross-origin access between frames should work, what should be allowed, prior to HTML5) in previous specifications, and as such each browser has its own design for quite what happens in those areas (normally similar except in the edge-cases from reverse-engineering), and quite a lot of those designs will be non-trivial to change to match HTML5 for all browser vendors in places, meaning there will be quite a lot of things that will remain different in the edge-cases for a while.
Note that under what the W3C Process requires today for a spec to proceed to REC neither HTML 4 nor CSS 2 would yet be a recommendation (indeed, such documents are closer to the quality that would be expected of an early working draft nowadays).
For a probably more refined answer than this, see http://wiki.whatwg.org/wiki/FAQ#What.27s_this_I_hear_about_2022.3F.
Opera doesn't support H.264, and was the first browser to ship a stable release with WebM support (and, heck, the original browser to ship an experimental video element, with Ogg/Theora/Vorbis).