hoppipolla
Our sitepatching is specifically designed to solve problems in real time rather than needing the site owner to make any changes, or for the user to upgrade their Opera.
Did you report a bug on Opera for the site that you were having difficulty with? Often half the battle is knowing that there is a problem, and having good steps to reproduce. With those things we likely could investigate whether we have a bug that needs to be fixed or whether the site is treating us differently to Gecko/WebKit for some reason, and come up with a solution.
We put a huge amount of effort into handling "nonstandard" html, including fixing the standards so that they represent the reality of what browsers have to handle.
In this case our failure is clearly a bug that we should fix. I don't think anyone disputes that.
In general, site-compatibility is a hard problem. People often depend – intentionally or not – on the specific behaviour of particular browsers. When this causes sites to break in Opera we try to analyse the breakage and adopt some strategy to fix it. Hallvord is one of the people responsible for this and, if you read his blog you'll see that it's not a trivial undertaking; pinpointing an error in tens of thousands of lines of closure-compiled, minified JS makes for an interesting challenge, for example.
If we find the problem's a bug in Opera we obviously try to fix that bug. If it is the site doing something broken we typically try to contact the site owner to get it fixed. In either case we may also try using our browser.js system to make a short-term "sitepatch"; a hack using a combination of UA string manipulation, javascript and CSS that changes the behaviour for a specific site and which can be rapidly deployed. In this instance sitepatching likely isn't reasonable, so we will have to work to find the solution that will unbreak the site as quickly as practical.
Given this limitation, the only problem with displaying event handlers is that developers who don't understand the underlying event model of the platform might not grasp the correspondence between the high-level abstractions in their library-using code and the low level DOM behaviour. Clearly any such developers will become more effective once they know a little more about the platform they are working on.
WHATWG are editing the "HTML Living Standard". Unlike the W3C model, there aren't version numbers or set phases that the spec must go through. Instead there is a process of continuous development; fixing bugs as they are found and continually iterating new features in response to the evolving needs of the web. This process is modeled around the way that browsers are actually developed, and should help innovation on the web keep pace with proprietary platforms.
The goal of the W3C version is somewhat different; it is essentially a branch aimed at stabilisation (likely at the expense of accuracy) in order that there is a well defined set of technologies covered by the W3C Patent Policy. It is also governed by a somewhat different (consensus based) decision making policy compared to the WHATWG version (the editor specs what people are willing to implement). History suggests that any differences that arise are most likely to be in things that don't affect UA interoperability but concern the definition of a valid document.
So the net effect of this change is that we will once again have a version of the HTML spec being developed using the system (and at the speed) that gave us HTML5 in the first place.
AFAICT IE has a somewhat different design; it seems to really be much closer to "one process per tab", which presumably means that they incur some IPC overhead when different tabs in the same unit of related browsing context have to communicate.
[1] http://www.whatwg.org/specs/web-apps/current-work/#unit-of-r...
I know this is not quite the same implementation that other browsers have.
[1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html#dom-n...
Chrome also has it, behind a flag.
(the parent comment originally asked when browsers would support getUserMedia)
The use cases it needs to address are mostly documented at [1] although there are some missing (people are currently putting together a wiki page [2]) e.g. in order for image prefetching to work the decision on which image to choose can't depend on layout (i.e. it can only depend on things that are likely to be known when the markup is first parsed and before any CSS is applied). There is further discussion at [3].
[1] http://www.w3.org/community/respimg/2012/04/16/summary-of-us... [2] http://www.w3.org/wiki/Images [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May...
Although in general things that make authoring easier are preferred, designs that are easy to implement in a bug-free way are generally preferred over designs that are complex and likely to lead to interoperability issues. After all, having to fight implementation differences is a rather common complaint about the web platform.
It also hasn't been clearly demonstrated that multiple elements are easier to work with. They are more familiar, but significantly more verbose. I don't know how that plays out in practice.
I think it is instructive to examine how the incentives line up for various players here.
* For high-marketshare browser engines:
Prefixes are great. It allows them to release whatever new stuff they like whilst avoiding the bad rap that Microsoft got for releasing proprietary things like XMLHttpRequest. This makes them look innovative, which gets them lots of press. It also makes it impossible (thorugh the "you won't implement other people's prefixed stuff" social contract) for their competitors to implement the new things and, even once the others do implement, the existing content won't work, helping protect their marketshare. Of course you can't ever drop the prefixed property, but there is no social stigma for this, so it isn't a big deal.
* For leading-edge web designers:
Using prefixed properties in demos is a no-brainer. They allow you to create novel effects which you can then discuss in your blog, so improving your reputation and social standing in a competitive market. The fact that the sites won't work in multiple browsers is irrelevant to you because you are mainly targeting other designers who will have a full set of browsers installed.
* For web designers working on client projects
Using prefixed properties is attractive, particularly on platforms where there is an unhealthy balance of rendering engines. It allows you to make designs that look like the leading edge demos — indeed your clients may be demanding this. You can rely on vendors never dropping prefixes and by the time the next major shift in browser marketshare occurs you probably won't have to maintian the site anyway.
* For the CSS WG:
Well obviously this is composed mainly of people from the other groups. But the main argument they use in favour of prefixing is that it allows them an unbounded amount of time to tinker with new proposals whilst providing a convenient excuse to ignore the legacy content that has built up in the meantime. This means that in the future there might be fewer people who have WTF-why-is-it-like-this moments when using CSS and decide to blame the working group. Therefore they think that prefixes are good.
* For non-dominant-marketshare engines:
Prefixes suck. You put a huge effort into implementing some new feature that someone else released under a prefix, release it, and it probably doesn't cause a single site to work better. You have to hope that authors start to include your prefix (even though there are probably legacy tutorials that don't mention it) or already included it by adopting the scattergun "add all the prefixes I can think of and hope the syntax doesn't change" methodology. This affects your ability to attract new users.
* For new entrants to the market:
This is an extreme case of the above. Prefixes are an enormous barrier to entry.
* For end users:
Prefixes suck. They increase the difficulty of changing browsers because they increase the chance that sites will break. This makes it harder to choose your browser on the basis of features like UI, privacy controls, security performance, etc.
So we have a solution that is good for vendors with dominant market positions and bad for users. That seems pretty anti-open-web to me. In the long term, I think the solution is to get over the idea that it is OK to keep fiddling with features once there is content that depends on the existing implementation; i.e. you have two options: "don't ship" or "ship and accept the legacy you create". That means no prefixes in CSS, just like we don't have them in HTML.
In the short term, the situation for non-WebKit browsers on mobile has become critical. If a decade ago browsers hadn't decided to implement the Microsoft-proprietary features in a way that was compatible with the legacy, we might all be stuck with IE6 today. If Safari hadn't added "like Gecko" to their UA string they might found it much harder to gain traction. History suggests that when browsers feel the need to take some action to improve competition, it is good for the long term health of the web. So it is here.
A more reasonable conclusion might be that the author made a mistake when testing Chrome. Having passed on the reports that Chrome still produces the header, the author has verified that this is indeed the case. I guess he will update the article.
From an interoperability point of view the HTML parsing algorithm is the poster child for the success of the HTML effort; there is a testsuite of several thousand tests [1] (also submitted to the W3C [2]) that has contributions from multiple browser vendors and a number of unaffiliated individuals. Although parsing isn't sexy in the way that, say, <canvas> is, getting interoperable parsing makes it much easier to create cross-browser content (at Opera we closed a huge number of site-compatibilty bugs when we landed the new algorithm).
There are also a few open-source implementations that are not tied to browsers e.g. for python (and kind of also PHP) [3], for java [4] (fun fact: the gecko C++ implementation is generated from that java implementation) and javascript [5] https://github.com/andreasgal/dom.js It would be great to see more conforming implementations for other languages, or to see libraries like libxml2 that have existing ad-hoc HTML parsers update their implementations to match the spec.
[1] http://code.google.com/p/html5lib/source/browse/#hg%2Ftestda...
[2] http://w3c-test.org/html/tests/submission/Opera/html5lib/
[3] http://code.google.com/p/html5lib/
If you want to make a even-slightly quantitative comparison you need to at least start by loading the same set of sites. Then you need to worry about them sending different content (e.g. different adverts) to different browsers.
In the end most people go by metrics like "how responsive does the UI feel", which is fine, although since it's a perception thing it can be influenced by factors other than the actual speed e.g. preconceived notions set by marketing.
It seems that they chose Microdata over RDFa because the latter's syntax was deemed to be unwieldy.
It's not really true that RDFa is more extensible than microdata, there are a small number of missing features related to XML data, but nothing too significant for these use cases; see, for example, [1]
[1] http://bnode.org/blog/2010/01/26/microdata-semantic-markup-f...
The first problem is that there is no documentation of method. It appears that the results were obtained by simply running JSLint on itself once. Without some indication of how the results are obtained and how stable they are it is essentially meaningless. Of course this is quite fixable but until it is fixed the data presented is basically worthless.
The second, and arguably larger, problem is that the page makes grandiose claims about the applicability of the benchmark that it doesn't even attempt to back up. In particular the claim that the performance on JSLint will be a better proxy for "other large, well-written JavaScript applications" than existing benchmarks. If we examine the Microsoft paper linked, it says:
"Specific common behaviors of real web sites that are underemphasized in the benchmarks include event-driven execution, instruction mix similarity, cold-code dominance, and the prevalence of short functions"
It is not demonstrated, nor is it obviously apparent, that JSLint will be any more typical in these respects than other benchmarks. I haven't examined the JSLint source code but I assume it isn't event-driven, deals mainly with string manipulation and makes many calls to the same few functions during parsing. If my guesses are correct it sounds like it will not, on its own, be a significantly better proxy for real-world performance than existing benchmarks. Of course it may be that it exercises a different subset of the ECMAScript engine than existing benchmarks; in this case a test like this would be a good addition to, rather than replacement for, an existing benchmark suite.
If you want to help out, contributions are very much appreciated; see [1]. Indeed, contributing tests is probably the most effective way to reduce browser interoperability problems and hence pain for future web developers.
If you want to take the tests and start adding subjective weightings based on importance and ease of working around fails, the liberal (BSD-style) license will let you do that (although obviously you can't claim that your derived work is the official W3C testsuite anymore).
This is a known issue. No promises, but it looks like a fix might be ready sooner rather than later.
http://groups.google.com/group/google-maps-js-api-v3/browse_...
It's not instantly obvious to me what the problem is here, so I will need to investigate further.
Thanks for the bug reports!
If you are having problems with javascript in Opera, I would really like to hear about them so that they can be fixed. There is a bug report form at [1], or reply here. Obviously it is nice if you have a reduced testcase, but just knowing that a site fails is immensely useful.