hoppipolla

To be clear, we aren't running some idealistic enterprise where we value standards compliance over real world usefulness. Indeed Opera has historically been more willing to implement IE quirks than other browsers, a policy that has recently come to cause problems because some sites punt us down an legacy-IE-only codepath that we don't work with, rather than a standards codepath that would work fine.

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.

> Opera would be great if it handled nonstandard html gracefully for me

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.

Yes, but there is still a node that has an event listener on, and it is quite possible to display that in developer tools. Opera Dragonfly already does this, for example. What's not possible is for the browser to know that the event handler on element A only has any effect if the event occurs on descendant elements B and C, for example.

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.

Technically there is still only one "HTML5" standard; the W3C one.

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.

Oh, so 1:1 between processes and event loops? Doesn't that mean that something blocking in one tab (alert(), sync XHR) might will block tasks in any entirely unrelated tab that just happens to share a process/event loop? That seems rather unexpected.

I think multiple "units of related browsing context" [1] would be more accurate; unless I am wrong Chrome uses at most one process per event loop and has one event loop for each set of browsing contexts that can reach each other via the DOM. This means that e.g. an alert in tab A will block scripts in tab B if B.opener == A.

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...

OK, GMail drag and drop issue turned into a bug report :)

FWIW we have the "wand" feature which will fill in, and submit, a form for you with previously used values (it's the key icon on the toolbar or ctrl+enter).

I know this is not quite the same implementation that other browsers have.

Random pedantic fact: Martin, and several of the listed contributers work in our office in Linköping, Sweden.

It seems that the "mpt" who owns that domain today and is responsible for this article is not the same as the "mpt" that wrote the original article [1].

[1] https://twitter.com/mpt/status/209033178705436672

That's what getUserMedia[1] provides

[1] http://dev.w3.org/2011/webrtc/editor/getusermedia.html#dom-n...

Opera Next has it (so it will be in the forthcoming Opera 12): http://my.opera.com/ODIN/blog/2012/04/17/web-page-camera-acc...

Chrome also has it, behind a flag.

(the parent comment originally asked when browsers would support getUserMedia)

Do you have a better proposal?

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...

That is a very appealing design, but sadly it doesn't address all the use cases. In particular one thing that people want to be able to do is to display a different image depending on the viewport dimensions, for example a closer crop on a small screen compared to that shown on a larger screen.

Because I was making a specific point about the implementation complexity of things that depend on attributes vs things that depend on many elements.

This doesn't modify parsing. Modifying parsing would be something like allowing <img> to have child elements. Adding extra attributes to an element requires no changes to the parser.

From an implementation point of view, putting everything in a single attribute is way simpler; the design of <video> is quite problematic. The reason is that with a single attribute everything can be processed atomically. With a design based on multiple elements things can happen between elements being processed, creating many more edge cases.

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.

Long experience of contacting sites suggests that it is, at best, of limited effectiveness. At Opera we have a not-insubstantial team dedicated to developer outreach who frequently contact sites that are broken in Opera and give them help to get stuff working again. But the approach doesn't scale; we can only contact so many broken sites and we can only get so much traction being proactive and asking people not to depend on new, shiny, but single browser, stuff.

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.

It seems like a weird thing to perpetrate a hoax about :)

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.

The DOM and ECMAScript both assume that strings are sequences of UTF-16 codepoints. So while a browser could use non-UTF-16 internally it wouldn't help much because you would have to convert to UTF-16 in all the externally-facing APIs anyway.

Bleach [1] is a sanitizer that uses html5lib on the backend. I think that Mozilla use it.

[1] http://pypi.python.org/pypi/bleach

Right, WebKit shipped code based on the spec first but the spec itself underwent subsequent revision as the Gecko / Presto implementors found site compatibility issues and bugs. I think the WebKit implementation was recently updated to the spec, so we are at, or at least very close to, having very interoperable HTML parsing in Opera/Firefox/Safari/Chrome. I also believe that Microsoft are aiming to implement the new algorithm in IE 10.

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/

[4] http://about.validator.nu/htmlparser/

[5] https://github.com/andreasgal/dom.js

These "I have X tabs open" comparisons are very unhelpful. Different sites take hugely different amounts of memory in just the same way that different desktop applications do.

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.

https://bugs.opera.com/wizard/

http://schema.org/docs/faq.html#14

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...

It is worth taking this with a liberal sprinkling of salt.

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.

The W3C HTML Working Group is working on a complete testsuite for HTML5. The WebApps working group are doing similar things for their specs. many of which are often loosely referred to as "HTML5". The goal of these testsuites is to help browsers achieve interoperability, so the emphasis is on getting high quality tests that cover the whole spec and include difficult cases.

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).

[1] http://www.w3.org/html/wg/wiki/Testing

I haven't confirmed it, but I have heard [1] that it tries to download Flash content if you don't have Flash installed.

[1] http://krijnhoetmer.nl/irc-logs/whatwg/20110210#l-826

http://www.questionhub.com/StackOverflow/3899985

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!

(disclaimer: Opera Employee, Core QA)

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.

[1] https://bugs.opera.com/wizard/