24 comments

[ 3.1 ms ] story [ 50.4 ms ] thread
The answer is quite obvious.

While traditional institutional fear make it invisible.

It is sad even Mozilla execs cannot see the obvious solution raised by the question Google has asked.

Browser vendors could standardize at an even lower level.

A system following the heart of Unix could allow for shared architectural components between the vendors and rapid innovation in the industry as a whole.

Why shouldn't MSIE be able to use the rendering engine of Chrome + the Javascript engine of Mozilla?

A simple "chassis" for W3C supporting browsers isn't some technological utopian vision. Just simple, stupid, good design.

Getting vendors (and the developers "on the ground") to work on something would be the hard part.

But oh what a wondrous world it would be.

So we've seen Microsoft and Mozilla whine about Chrome Frame, how about anyone without a vested interest in seeing Chrome fail?
(comment deleted)
Almost certainly not the case, because sites need to opt-in to use Chrome frame. I doubt somewhere in Windows they will be accidentally opting in.

Chrome Frame is using the existing plug in architecture, they aren't being excessively obtrusive.

In that case my comment is ridiculous- so no problem there.
(comment deleted)
I agree with Mozilla.

It would become an easy way out for people to just have 2 click plugins for their website instead of forcing people to take the hard way and install a full browser.

Why is this bad? From anyone other than a browser vendor's perspective.
Its bad because you would have maybe a dozen different "browser" plugins to visit several different websites.

You as a web designer wouldn't know which ones to design for especially if people can't install plugins, and as a result, would have to add on even more testing than the usual IE6/7/FF/Opera/Chrome/Safari.

Your website will also include the special hashtag thingie cruft at the top to support multiple browsers.

Overall, its a bad bad idea.

I guess this needs repeating: Chrome Frame doesn't load unless there's a specific tag in the page telling it to.
Do I really have to spell this out for the HN audience? (Really annoyed by these comments and downvotes).

You don't really think chrome will be the only browser to do this? And also, you will be snooping for plugin compatibility just like people are doing today for browser compatibility.

Then don't use it on your site?
I actually think it would be interesting if there was a standard interface between the renderer and the browser ui.

This would allow renderers to compete on their own merits with their real customers (developers), instead of being shackled to the success or failure of their attached UI.

OTOH, one potentially bad outcome would be that there would be increased stickiness of content. Once content is authored targeting one renderer, there is little reason for authors to update it since they can always target the old renderer.

You don't need to spell anything out. People disagree with you.

First, there's no realistic world in which all of a sudden everyone is using different plugins. Almost nobody in the world has the kind of distribution that Google does. Very few people could pull this off, and I doubt even Google can.

Second, if there were a way to get users to install plugins 99% of the time, then we wouldn't have half the issues we currently do. You act like it would be a bad thing to test for the availability of plugins which enabled new features. It wouldn't be. It would actually be quite awesome.

Third, Chrome Frame is exactly the same as Chrome, so, at least in theory, there is NO NEED to test for anything knew. Even if every browser did this, there would be NO NEW browsers. There may be some implementation gotchas, but I don't see the same kind of doomsday scenario you do.

Anyway, I think it's highly unlikely Chrome Frame goes anywhere at all.

Where does the dozen come from? There's only Google Frame plugin.
Noteworthy that the "IE Tab" is a popular Firefox add-on: https://addons.mozilla.org/en-US/firefox/addon/1419
I do not believe this to be noteworthy because you can clearly choose to open things in IE. Whereas in the chrome frame you get double the security risk and don't get to choose which browser to use. At least with that plugin you get a choice.
Users simply don't care about this. They think google is the browser already. Mozilla has this bizarre notion that people will be upset because they don't know which rendering engine they are currently using.
I believe that to be skewed based on developers downloading that add on for testing purposes (albeit a lazy way around the test)
That's pretty hypocritical of Mozilla. About a year ago, they were flaunting similar ambitions[1] and actively working on Screaming monkey[2].

Quote, "Mozilla is developing a plugin for Internet Explorer that will add support for the HTML5 Canvas element. Microsoft's attempts to stifle adoption of open web standards could soon be circumvented by plugins that bring Firefox technology to Internet Explorer."

Talk of double standards...

[1] http://arstechnica.com/software/news/2008/08/mozilla-drags-i...

HN discussion: http://news.ycombinator.net/item?id=280375

[2] https://wiki.mozilla.org/Tamarin:ScreamingMonkey

This sould be nuanced. Screaming Monkey and the Canvas plugin are drop-in replacements. The Chrome frame is optional, and could possibly interfere with cookies or history handling (although I'm not sure it's the case). The problem raised by Mitchell Baker is that it would make it very hard to "manage information across websites". Did I hear XSS and tracking cookies?
Chrome Frame lets IE handle cookies and history and all that. XSS and tracking cookies keep working as they always have. Chrome frame uses the IE network stack to ensure this[1]. The canvas plugin and screaming monkey were both intended to be implemented using tags[2].

I expected a better response from Mozilla than this.

[1] http://code.google.com/chrome/chromeframe/developers_guide.h...

[2] http://blog.vlad1.com/2008/07/30/no-browser-left-behind/#com...

Edit: Added [2].