Mozilla's "modern browser" attack on IE overlooks Firefox shortcomings | Hacker News Reader

Mozilla's "modern browser" attack on IE overlooks Firefox shortcomings

arstechnica.com

30 pointsabraham28 comments

Not only do MS's figures show their tests they they created (so that 100% means they met a self-defined project goal not that they match 100% of any externally defined/agreed standard), they don't entirely compare like for like. While they show how bad IE8 is compared to the other currently released competition, they list there own "won't be released for a couple of months yet" version but don't include other people's alpha/beta/RC versions.

It would be interesting to see how well FF4 and the current Opera and Chrome pre-releases manage against this set of tests (probably not 100% as the tests have a built-in bias, but I'm sure they'd do better.

All the tests have been given to the W3C. Once they've been added to the test suite, you'll be able to compare them to whatever browser you like, whever you like. The current W3C suite is here: http://test.w3.org/html/tests/reporting/report.htm

More tests need to be added. If you have some tests, please submit. Please help to make this suite robust. Otherwise its just inactive complaining.

There are already other tests though, but MS didn't use them in this analysis. Hence it is a good test to see if they've reached there project goal but not a good test of general compatibility with the standards. If they are just using their own tests and not the others, then raising more test cases is not going to make any difference.

AFAICT, his only attack against FF4 being a modern browser is that FF4 doesn't do process isolation on tabs, which I would argue is unnecessary.

FF4 has process isolation for plugins, which is super important. Process isolation for tabs protects against runaway Javascript, but you don't need process isolation to do that since the javascript engine is part of Firefox.

Process isolation on tabs, when combined with a solid sandbox, also prevents a browser exploit in one tab from compromising others.

It does not prevent it, it makes it more difficult. There is still communication between processes which could be exploitable. That being said, it certainly helps.

In theory, the sandbox should prevent it. In practice, of course, this is not the case.

Process isolation is a great feature but it has nothing do with page rendering. As a web developer, I'm concerned about how people will view and interact with my sites. If their browser does that correctly and quickly, that's what matters here.

If your browser has process isolation, a crazy bookmark system, skins, or an extension system those are just features for the end user and don't affect web applications running under it.

This is not necessarily 100% true. Process isolation affects your user's experience in an indirect way. As web apps become heavier and heavier they adversely affect each other more and more. Many times your sites perceived lack of performance is due to another misbehaving tab. Its true that standards support improves the singular experience of your site, but process isolation improves the combined experience of the web as a whole and allows everyone to do more impressive things.

A browser doesn't need process isolation to clamp down on misbehaving sites. It might be easier than doing it in the scheduler in your javascript & rendering engines, but process isolation is not necessary.

Challenge to Microsoft and FF: swap and merge test sets!

MS has submitted theirs to the W3C. Mozilla (and everyone else) should do the same.

Agreed. And there's no reason why FF shouldn't ace the IE test, and vice-versa.

Wait what? An attack on another company didn't involve finding faults in your own company? Impossible.

Mozilla is accusing IE9 of not being a true Scotsman. It gains them some press coverage for what would otherwise be of interest mainly to the faithful.

The "standards" that you are referring to here that IE does not comply with yet are not really "standards" yet. With the specifications clearly in debate, I don't know why anybody would expect them in the production version of a browser. In supporting these standards the other browsers are getting ahead of themselves.

Here's a quote from the article:

"Along those lines, some of the weak areas in IE9 relate to standards that are still basically in flux and are implemented with vendor-prefixed flags in other browsers"

"On that note, Doug Schepers of the W3C SVG working group recently dismissed critics of Microsoft's SVG support in IE9 and lauded the company for implementing a "very large, functional subset" of the standard" - Mozilla didn't have this for quite some time.

In the future, with HTML becoming unversioned, this will be SOP. Every other browser vendor seems to have no problems implementing standards as they emerge, yet one of the largest companies mankind has ever seen can't spare the resources? Give me a break, this is all about power struggles.

Also, the fact that browsers actually implement emerging standards means that when the standard is eventually finalized (again, talking mostly in the past here), it's less likely to be the 'ivory tower' sort of standard, and more likely to be what a standard is supposed to be: a codification of what everyone is already doing. This is far more useful than some sort of proclamation from upon high.

In the future, with HTML becoming unversioned, this will be SOP

I find it odd that no one seems to realize how broken this is.

Every other browser vendor seems to have no problems implementing standards as they emerge

That's just wrong. Take FF4, for example, there is a lot of stuff that it doesn't implement still. It only looks good in comparison to IE9. It looks a lot less good if you compare it to every draft that's out there.

more likely to be what a standard is supposed to be: a codification of what everyone is already doing. This is far more useful than some sort of proclamation from upon high.

This is contradictory. The way standards for HTML5 have generally worked is that a smaller set of web vendors have made a proclamation from upon high that this is the now the web (albeit in flux). "What everyone is already doing" apparently is Opera (who appears to be the furthest out front), and not IE. That's like WebOS defining the new appstore standard and telling Apple to get in line.

I so hope IE10 comes out with a whole bunch of new features that no one else has and then pushes those into the standard. Just to hear everyone whine about how they're now rushing to market with features that haven't been fully ratified.

The alternative, that we have tried, is for standards bodies to dictate a standard and hope that browser implement it (which they often don't).

Waiting for the code to actually ship before calling it standardized lets you get actual results.

In my (admittedly limited) experience, when web developers say they wish browser vendors would follow standards, what they really mean is that they wish everyone used WebKit.

In the history of the web, most of the standards have simply codified what was already in common usage. We've already seen problems with implementing large standards after the fact: We had the box model problem in IE with CSS, for example. Some of biggest failures, like XHTML, were from standards committees and some of the biggest successes, like xmlHttpRequest (Ajax), just started out as proprietary features.

In my opinion, the best way for the standards to emerge is early and often implementation. It's best for everyone to be able to actually work with a reference implementation. This already happened, for example, with CSS gradients. It was a feature proposed by the WebKit team and Firefox took the idea and implemented it differently. Web developers got a chance to use both and weigh in on the pros and cons. Browser makers got to see how works in real situations. And, in the end, WebKit changed their implementation because the Firefox method turned out to be better and simpler. And now that has been put in the standard to become part of HTML5.

Microsoft isn't even in the conversation.

most of the standards have simply codified what was already in common usage.

But there's a BIG difference between saying, "OK, pretty much all of the top 5 browser manufacturers have implemented feature XYZ, and it is commonly used today by many popular sites in a standard way. Lets codify this."

"WebKit just added this cool new feature. Opera implemented it two weeks after it shows up in WebKit. No one is really using it yet, but it's really cool. Write up a draft of it and now lets say its part of the standard (in-progress)".

That's not codifying common usage. That is some vendors in key positions in the standards body taking advantange of their positions.

I agree. It's dishonest to say that Microsoft isn't implementing HTML5. But they've actually said something much more subjective: that IE is not a "modern browser". The argument, which hasn't really been explicitly stated, is that a modern browser attempts to implement these new draft features before they're standardized.

In the past, Microsoft was not shy about implementing all kinds of new HTML technology but since IE6 they've only been doing the minimum necessary.

You can't get around to codifying a commonly used feature if it never becomes commonly used. And it's pretty clear that all these new HTML5 features will be in common use everywhere else long before the HTML5 standard is finished. So even though Microsoft is going to be releasing a new browser shortly, it'll be obsolete almost immediately.

No browser in the market are smart and there's not doubt about it. Browsers don't grow with the users, they don't remember well, cannot spit the information back on demand. Until and unless browser reacts or come close to reacting like a human brain, they cannot claim to be smart or modern.

I will call IE a modern browser when both IE8 and IE9 don't crash on http://crashie8.com/

Process isolation:

Run Chrome

Open a lot of tabs

Open one with a HTTP auth that brings up the native browser login dialog

Switch to another tab

Close the one with the dialog

Result: whole browser crashes.

Moral: process isolation does not mean better user experience.

Like I said a lot of times:

IE 6 is still officially supported

IE 9 is not available on XP

This is why Microsoft is still crippling the web.

  Moral: process isolation does not mean better user experience.

No, the moral is that process isolation isn't a magic bullet that somehow prevents all types of browser crashes. But that doesn't mean it's not a useful technique for reducing the impact of things like a buggy plugin.

Like I said, it doesn't magically make all nuances go away all by itself, it may make the programmer's job a lot easier but it does not directly impact user experience.

That's why it's not appropriate to compare browsers based on whether they implement this or not.

Last time I checked if I crashed one instance of Flash player in one tab, all instances crashed in all tabs.

Reply on news.ycombinator.com