Friday, July 27th, 2007

The End of TAE and Browser Possesion

Category: Browsers, The Ajax Experience

Another Ajax Experience is over. We had a blast and it was a tons of fun to see so many of our friends in the community and to have so much top-notch content. Many thanks to all those who came out, especially the speakers, many of whom came to present at great personal sacrifice. And, a tip of the hat to those who held some announcements for the show, such as:

As the last sessions were wrapping up, a group including Brad Neuberg, Glen Lipka, Alex Russell were seen huddled together in an animated discussion. Glen kindly pointed us to a summary of their chat, which includes what he’s calling “browser possession”:

The most exciting idea, which several people seemed to be noodling on at the same time was what I am loosely calling Browser Possession. It goes like this:

1. You make a web page using HTML, CSS and JS.
2. You test it in ONE browser. Probably Webkit.
3. You include a single JS at the top of your page, a spinoff off of SWFObject.js
4. The JS would instantiate a SWF file which would fill the 100% of the height and width of your browser window.
5. The JS would then suck in the HTML of the page, and feed it to the Flash Movie.
6. Then the Flash movie would instantiate Webkit inside it and render the page.

Glen goes on to simplify the proposal as:

1. Same as above, but instead of a Flash movie, it would be a Webkit native plugin.
2. This would need it’s own JS that was specific to this task.

Back when Adobe started briefing developers on Apollo/AIR, a few of us joked about WebKit running in a plug-in rendering web pages inside of a web browser. Funny to see it proposed as a serious idea.

With ScreamingMonkey proposing essentially the same idea with the JavaScript run-time, it’s interesting to imagine a world where Ajax applications can choose from several HTML renderers and JavaScript run-times, much like IE lets devs choose between the “Quirks” and “Standards” code paths.

Posted by Ben Galbraith at 9:02 pm

1.7 rating from 135 votes


Comments feed TrackBack URI

Wow, I saw that brainstorming session, and I knew some mad genius was breaking forth. A fitting end to a great show.

Comment by Ryan Breen — July 28, 2007

Adam Lock’s ActiveX glue for Gecko (which works both ways: Gecko as an ActiveX plugin in IE, and ActiveX-only plugins adapted to look like NPAPI plugins in Mozilla) provided an early example. It’s still going, AFAICT.

The problem with these schemes remains distribution. It’s not easy getting onto most PCs. You have to pay the Dells of the world for the right.


Comment by Brendan Eich — July 28, 2007

The idea of metabrowsers sounds great… It’s a pity that 90% of audience would never notice. Praise Microsoft :/.

Comment by ch__ — July 28, 2007

Browser inside Flash would such basket balls through garden hoses.

You lose all the goodies the browser provides for HTML. Ad-Blocker, Search, User CSS, User JS, Context-Menu with your stuff like “translate word”, ability for change the font size and enforce a minimum font size, fast back/forward through rendered page caching etc. pp.

No thanks.

Comment by Martin — July 28, 2007

I agree with Martin ^^

Comment by Dougal — July 28, 2007

@ch: Are those restrictions insurmountable? Couldn’t the back button be passed to the embedded browser? Couldn’t bookmarks be synched? I think of it as a challenge to integrate those needed benefits, not a reason to give up.

The basic premise of a progressively enhanced page, that renders in an engine that the publisher chooses, and not the user would make “backward compatibility” a limited concern. Microsoft’s speech on Thursday was adamant that backward compatibility stopped them from fixing bugs and innovating. JavaScript 2 sounded great, but backward compatibility creates loads of problems.

@Brendan: The flash player has more penetration than IE and probably as much or more trust. If metabrowsing piggy-backed on AIR, and specifically the Flash ActiveX Control, why would 90% of users not notice? Ideally, they would never know. Flash currently is meshed into the users pages with barely a second thought. That’s why I think using AIR is a shorter route than a browser-plugin alone.

If Google or Apple started to publish a pure meta-browser plugin, I also think that distribution would become much easier. Ultimately, this is a boon for publishers and site developers. You know what the user will get, and are still making html/css/js.

Why wouldn’t Apple want to do this? Or Adobe? That AIR demo seemed to be 90% of the battle. And Apple has everything to gain on this.

Why am I awake at 5:40am?

Comment by Glen Lipka — July 28, 2007

Its an interesting idea, I was just joking about it to someone the other day because there were a few stories going round that somehow AIR was a successor to flash. That would only be true if AIR was available as a browser plugin, and so flash plugin replaced by a webkit+flash plugin.

I think it is a funny idea, a bit weird, and really a tragedy that it could be useful. A crude but effective workaround for the fact that browser standards never quite seem to be good enough to avoid having to code browser-specific workarounds.

I dont think its that much In Apple’s interests, especially as they now have Safari for Windows and so would probably rather be pushing that. Dont know what their relationship with Adobe is like these days, no flash for iphone so far etc.

It could make sense for Adobe to do it. I guess it will come down to how much AIR takes off as a standalone thing seperate from the browser, and how much Silverlight actually proves to be a threat. Certainly one of the merits of making stuff using flash was that it would behave the same across playforms & browsers, and they have been trying hard to keep in with developers & the latest trends by embracing AJAX, so I suppose its not impossible that they could go down this path.

Comment by Steve Elbows — July 28, 2007

I don’t like the idea. Check that… I hate the idea. Though props to you guys for having the discussion, and having the nerve to air it out in public. My concern is that although its a clever approach to the problem it completely misses the point of what we want to achieve as a community. Its a hack, not a fix. We as a community don’t want ubiquity, we want reliability.

Competition is an enabler… it encourages innovation and variation. Using Flash/some other means as a hybrid to fix lack of reliability boils down to one plugin to rule them all. Browser/Plugin what’s the difference at that point, it still spells monopoly on innovation. We saw probably the worst possible result of that with IE6… 5 years of no innovation… while it probably wouldn’t be worse than that… putting all our eggs into one basket in any situation is a very very bad idea… one way or another it slows down development and innovation…

The real solution to this problem is for major vendors (and by proxy smaller vendors) of browsers to agree to not compete (yet still innovate) at the rendering level without working together to find the right solution. We’re seeing a lot of movement in this area lately and THAT is what should be encouraged.

If vendors can agree before releasing their respective products that X “feature”, where feature is something new deliverable by code, should be coded by a web developer with X method… we will go a lot further, a lot quicker towards resolving the problems plaguing our industry today. We as a community must encourage competition that EXCLUDES the handling of HTML/CSS/JS, and then encourage agreements between vendors to continue to innovate at that level. If Microsoft/Mozilla/Opera/Apple do not attempt to brand their innovations with handling HTML/CSS/JS then most of our problems will be gone.

Make a better browser? Absolutely! Compete at the speed the rendering process absolutely! Extend the browser to handle more day to day tasks like RSS feeds? Absolutely!… but leave the core to an agreed standard… not W3C standard.. just ANY standard…

Back to the point… our goal is reliability… backward compatibility is a very good idea as it encourages growth… so lets focus on getting all players to play nice with one another rather than inventing clever ways of avoiding the work of finding a consensus. If that consensus can be reached soon… then in a couple of years we’ll have a reliable platform to develop on that will continue to be reliable as time goes on. Lets just find a way to make the approval and agreement process happen BEFORE a browser is released to the public… getting four teams (Microsoft, Mozilla, Opera, and Apple) to sit down together may be difficult, but doesn’t seem to me an insurmountable goal… and frankly its makes them all look good, regardless of their marketshare… :)

Comment by Owen Lambert — July 29, 2007

“Its a hack, not a fix”

Comment by Peter Michaux — July 29, 2007

All I can say is… please NO… do not do this

Comment by Ryan Lowe — July 29, 2007

Wow. Please, no.

Comment by Robert Alan — July 29, 2007

Personally, I am a little confused.
Is sIFR a bad idea? It’s unobtrusive. It helps designers pick the fonts they want to use without messing up Google. Degrades perfectly well. Users never notice slowness.

All I am saying is, with Adobe AIR, you could, in theory, get the next gen of sIFR where instead of the fonts being rendered better, the whole page is rendered in an engine of choice. I never said, “everything else would break”. I didn’t say “ad-blockers and controls would break”.

Im confused by comments like “Wow. Please, no.” Is that what you say to sIFR too? Maybe those who just say, “All I can say is… please NO… do not do this” could be specific. I am pretty sure you are making assumptions I am not making.

My assumptions:
1. 100% unobtrusive. 1 page to develop in html/css/js.
2. The plugin is Flash which has wonderful penetration and trust.
3. Nothing in the browser would break (back/forward/bookmarks/ad-blockers).

In terms of the comment about browser innovation. I agree, there were several years of stagnation from Microsoft. However, those were GREAT years for developers. Sometimes we NEED stability to develop great things. I think the pendulum needs to swing sometimes. I am not disagreeing with the point about competition brings innovation.

Comment by Glen Lipka — July 30, 2007

Here’s a “framework” for doing this kind of thing. It’s called FXT and it’s been around awhile:

Comment by Greg Fuller — July 30, 2007

Glen: swapping in Webkit in something like AIR as a demon possessing IE is not enough. Webkit is not as web compatible as Gecko, and both Webkit and Gecko take the “else” path in all the “if (isIE) … else …” scripting forks. Putting it inside an IE instance guarantees a chinese wall between the demon’s inner content and outer content.

See Netscape 8, which made a franken-browser of Firefox by using MSHTML for some sites, Gecko for others. Consider cookie sharing or non-sharing, certs, etc. You can use the IE settings model from AIR, but the interpretation of those settings won’t be identical. AIR is in its early stages, and it has the “advantage” that its content does not have to interoperate bug-for-bug compatibly with IE. AIR has its own content model.

And then there’s download footprint.

A full browser that can handle web compatibility plus OS integration is non-trivial, to put it mildly.

But sure, the ScreamingMonkey approach could be used over the long run, with enough work on distribution and compatibility. IE is a possession target. MS won’t stand still for it, but if they break too many APIs that their own code (e.g., Silverlight) can use but Flash cannot, they’ll raise antitrust issues again.


Comment by Brendan Eich — July 30, 2007

I think there might some confusion about what Adobe AIR is and will do. The initial release of AIR is a _desktop_ runtime for Flash/PDF/HTML content and will not work to unify/replace the Flash and PDF browser plugins. It’s somewhat similar to MDM Zinc, Screenweaver, mProjector and many other proector wrappers available to bring Flash to the desktop except that rather than implementing PDF/HTML support as distinct modules each with their own API, Adobe has made them all scriptable through the wrapper application (AIR runtime) so the different content types can all interact. It’s really very clever. Adobe AIR makes filesystem access (read, write files) possible too. I can’t see this happening in the web browser!

The Flash plugin in itself isn’t capable of embedding WebKit rather WebKit and Flash can share the same application container and communicate using a common API when compiled as an AIR application.

However, I hold a knife and fork by my proverbial hat in case anyone can make this browser-in-browser work by embedding AIR into a regular browser.

Good luck.

Comment by Stephen Beattie — August 1, 2007

Leave a comment

You must be logged in to post a comment.