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