> 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.
I gave up on Opera because it was unusable on a small site that I use regularly. The site's owner licenses vBulletin and hires some local web guy to customize it (local being rural Pennsylvania).
I was the only person using Opera on the site. It wouldn't be a surprise if I was the only Opera user the web guy encountered all year.
IE, Firefox, Chrome all worked properly. Using Opera was turning me into a whiner as far as the site's owner was concerned. And he was justified, using Opera was just a luxury that was creating a PITA for him...on a site he was providing gratis.
I suspect his site was broken in terms of standards. But from my standpoint, it was Opera that was broken.
Don't misunderstand me, I chose Opera originally because I admired the project's goals. I still admire the feature set Opera provides. For me, it's tradeoffs became increasingly impractical. I want my browser to deal with the problem of broken sites in real time, not contact the site's owner for a long term solution.
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.
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.
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.
You're somewhat wrong. Chrome will put browsing contexts that normally can't reach each other via the DOM on the same event loop (and in the same process) if it decides it's got too many renderer processes spawned already. Once it does that, they can try to reach each other via the DOM if they have window names.
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 can't speak to the exact event loop behavior; I haven't tested it.
Even if you have only one main event loop per process, spinning nested event loops (e.g. the way Firefox does for alert and sync XHR) would let you do things in one tab while another is blocked on an alert or whatnot. I just don't know whether Chrome does that.
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.
Your "wand" feature also adds a terrifically ugly yellow border to remembered inputs which developers have no way to prevent (like you can with WebKit by using outline: 0). I'm all for a constant UI to create a good UX but not when it can make a site look bad.
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].
This is what I did on my dev Chrome to enable WebRTC:
- Type "about:flags" on the address bar and press enter
- Enable the "Enable MediaStream" option
- Click on the "Relaunch now" button at the bottom of the screen
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.