Browser Possession

By | July 28, 2007

I am reporting on a break-through idea.  I have to describe it.  It will change the world.  Ar at least change the World Wide Web.  It’s not “my” idea.  It was a result of a brainstorming session.  I’ll explain:

It’s the last day of Ajax Experience. It started off with a keynote by Kevin Lynch from Adobe.  It was an amazing demo.  He took a web application using Jack Slocum’s EXT and published it using Adobe AIR.  This allowed the application to run as a desktop app in any operating system.  It was HTML, CSS and JavaScript, but running without a browser.  It used WebKit, the browsing engine that powers Apple’s Safari.  So it basically had a specialized browser running inside Flash, on the desktop.  This is when I had a seed of an idea: “Hmm, I wonder if they could embed that in Firefox and IE?”

I didn’t pursue this line of thinking too much at the time.  Later, this evening, I was getting ready to leave when Brad Neuberg and Paul Abrams started a little brain storming session. Brad did an awesome job of moderating.  Seriously, he was a study in patience, tact and inspiration.  (Brad works on the core of Dojo)  We were imagining a different WWW.  A different paradigm of viewing the web, where “desktop” and “web” became blurred and “public” and “private” became important.  (More on that another time)

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.

OR

  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.

What are the benefits?  First of all, I would only have to test ONE browser, regardless of whether you used IE, FF, or Safari.  Inside those browsers, would be the soul of Webkit, who is rendering the page, NOT the native rendering engine.  Webkit would have taken possession of the page rendering on demand of the publisher.  THEN, when a new version of Webkit is released, it is up to the publisher to change his page to use the new plugin ONLY if they wanted to.  Let’s say you had a page that you never wanted to upgrade.  You would specify Webkit 1.0 and never upgrade that to Webkit 2.0.  Maybe even allow for Gecko plugins or IE rendering plugins.  Then you could say, “I want this browser to render my page, regardless of what browser shell the user may be using!”  This also allows the page to be very simple so that Google can still read it and index it.

This would solve so many problems and create so many opportunities.

  • It would reduce cross-browser testing to zero.
  • It would allow much more advanced applications to be built because you wouldn’t have to yield to the lowest common denominator.
  • It would simplify pages because you wouldn’t need all the extra divs that are only there because of box model problems.
  • It would speed development because you wouldn’t need to learn all the different  browser language quirks.
  • It would allow plugins with different languages like Python or Ruby on the client.
  • It wouldn’t break the Web now, and it would ensure never to break the Web later.
  • It would allow more radical upgrades of browsing engines because backward-compatibility would be a non-issue.

Apple could do this and convert a whole slew of people to be designing for Webkit (which powers Safari and the iPhone)

Side note:  Although Apple didn’t have a presence at AjaxExperience, I noticed an important thing.  9 out of 10 developers had Macs.  Very few PC’s.  I thought this was really interesting.  Plus, I saw at least 6 iPhones.  I used one. They are extremely nice to use. 

This idea is breakthrough.  I think almost everything we need to accomplish it is available today.  Whether a Flash plugin or a WebKit plugin, the infrastructure exists.  It would completely change how we build web applications and sites.  It would make IE and FF irrelevant.  They would become shells.  At that point the “browser” has alot less meaning.  It would ensure that pages would be rendered the way the developer wanted them to be rendered.  There are so many good things that would come of this.  We would be fast-forwarding the web by 10 years, right now.

This is the biggest idea, since jQuery.  And for me, that is saying alot.

20 thoughts on “Browser Possession

  1. Pingback: Ajaxian » The End of TAE, and Browser Possesion

  2. Pingback: Ajax Girl » Blog Archive » The End of TAE, and Browser Possesion

  3. bsterling

    I love the idea; but I am wondering what thoughts will go into accessibility and search engine friendliness. With what you propose, and with flash’s limited accessibility compliance, those will be sticky points in my mind. Now, of course you came make two versions of your site, but that goes right back to weighing cost against compatibility.

    Not sure if that is coming off exactly how I am trying to say it, but I hope you get it.

    Ultimately this is a great idea and I will be following along.

    Reply
  4. Glen Lipka

    I’m actually thinking of just ONE source. So you make your source compatible with webkit and google. n Simple semantic markup, css, js. You assume one browser (webkit), the way 2 years ago, I assumed IE6. Then the flash/webkit plugin would suck in the source and render it. So you wouldn’t have to maintain two versions.

    Google would still read the source from the page…the flash is just a method of progressive enhancement…it takes the source and renders it in an alternative rendering engine.

    SEO is critical, thats why FLASH alone is not a good answer. But sucking in html, css and js from the page and shoving it into webkit, is just saying, “I am a publisher of content. And my content works with Webkit…render it with that”. The JS to pull the page into the flash movie would be complex, but I dont think there is a technical roadblock.

    Reply
  5. david

    I’m just wondering on what the overhead would be using this technique? First the source gets generated and then everything gets regenerated in flash.
    I would suspect there will be a longer duration between the user action and the response on the screen. How can this be kept to a minimum.

    I never worked with AIR and i have limited flash knowledge but i think sucking in a source in flash would take up memory.

    As far as the rendering engine plugin is concerned making people understand they have to use another browser in their browser of choice/default browser might be very alien to most. I know a lot of people who don’t even (want to/ care to) know which browser they are using.

    Reply
  6. bashley

    @david: part of the basis of the brainstorming session was that we were to turn current assumptions on their head. In x years, what we now assume is overhead re bandwidth, computing power and capacity will be largely irrelevant.

    That said, with this idea as an output of the brainstorming, it will certainly be a challenge to make it tangible within current constraints.

    Reply
  7. Matt

    This is a good brainstorming exercise, but ultimately an unrealistic dream, IMO.

    1) It requires Flash, which not everyone has installed or enabled. I browse without it on, because 90% of Flash on the web is annoying advertisements and the other 10% is mostly pointless.

    2) If you are going to have a “web browser” embedded within Flash, why not just write fancy Flash “pages” with more functionality?

    3) Won’t you be subjected to the minor differences in OS implementations of Flash, as well as browser implementations? Are you just trading HTML browser quirks for Flash browser quirks?

    4) You will instantly make all the existing browser, HTML, JS, and CSS tools unusable on your site. Functionality that is taken for granted in the web experience by user will stop working as it always has. Bad for the user.

    5) You’ve moved away from the intent of HTML/CSS which is to allow sites to be rendered and interpretted differently by different user agents. What if I’m a color-blind person with bad eyesight? My browser customizations that let me actually see the web will be gone and your site will be unreadable to me.

    Although the goal is good, the unfortunately reality is that nothing is going to replace the status quo any time soon. Just be grateful that compatibility and standards-compliance are actually greatly improving in web browsers rather than moving in the other direction. That along with the abstraction provided by libraries such as jQuery mean that the average JS developer doesn’t even need to care about browser quirks anymore. And it only took us 10 years to get this far… 😉

    Reply
  8. Glen Lipka

    Matt, I don’t quite follow you. The main idea is to take Adobe AIR and embed it in a browser. So right now, with AIR, any web project, built on HTML, CSS and JS could be a desktop app, cross-platform, using WebKit as the rendering engine. The demo of that at the conference was pretty impressive.

    This doesn’t depend on Flash. It depends on AIR.

    The idea was, Instead of a desktop app that has a standard rendering engine, why not a browser app with a standard rendering engine. Specifically, I think the page needs to be HTML/CSS/JS to start with. It’s just replacing the rendering engine with a Webkit engine instead of the native one. Otherwise everything is exactly the same.

    In regards to pentration, Flash is the most saturated technology on the web. There are more users with Flash than with JavaScript. And it’s cross-platform consistency hasn’t been an issue that I have heard.

    I actually think that the technology to do this is much closer than you might believe. Having the publisher choose the rendering engine would benefit everyone. User and developer.

    It’s kind of interesting to me that most of the comments have been “why we shouldn’t even think about this” versus, “I wonder how close we are and what we would need to get this”.

    Anyway, I really appreciate your (and everyone’s) comments and I will think about them in detail.

    Reply
  9. rachel

    Here’s a user perspective:

    If this idea prevents me from running a pop-up blocker or other security tools in my browser, I want no part of it.

    If I can still filter out the ads & spyware, what the heck, bring it on.

    Reply
  10. jdsharp.us

    I think most people are missing the point, it doesn’t have to do with embedding your site in flash or implementing a rendering engine in flash. It’s using flashes install base as a means for distribution of a “common” (webkit) rendering engine. Your site would still be plain html/css/js (which search engines can index as normal) just you would “replace” the browsers rendering engine (IE, FF, etc) with one similar to how flash loads on demand.

    I find this concept very interesting, but my question is how will this new runtime integrate into the native browser’s functionality for navigation, forward/back buttons?

    Reply
  11. Glen Lipka

    @JD: Yes, that’s it. About the backbutton, I know there has been alot of work on how Flash Movies can pass the back/forward buttons back and forth. It seems like there needs to be a “bridge” JS file which passes all the commands back and forth.

    Reply
  12. evertrooftop

    You’re missing the biggest point here..

    Whats the advantage of getting a user to install yet another plugin versus forcing the user to use a specific browser..

    yea, the user keeps the browser skin they are used to, but the process is the exact same..

    Reply
  13. John Hann

    Yes, this sounds like a HACK in the short term. But unless you’ve had the opportunity to write to only one browser (and one as wonderful as Webkit), you wouldn’t understand how awesome this is! Working with iPhone Safari for the past few weeks, has opened my eyes. The CSS3, the lack of browser code forks, and the lack of cross-browser testing means a ton more time to create and innovate! I am writing 1/3 of the code I used to need to write (and, no, it’s not because iPhone Safari is crippled).

    When I heard that people were investigating this, I nearly jumped in the air. (I would have if I wasn’t so tired after staying up all night trying to solve some IE rendering bugs. Seriously.)

    And best of all: no vendor lock-in and no MS bullying. Browsers will compete on the basis of browsing features. Apps will compete in terms of form and function.

    In the future, if you get jaded with Webkit, port over to IE (ugh, the idea of that!) and publish your app using embedded IE8 in Silverlight…

    Reply
  14. Glen Lipka

    @Evertrooftop: It’s not another plugin. It’s flash. This whole discussion started with the Adobe AIR demo from AjaxExperience 2007. The next version of regular flash “might” allow for Webkit to be embedded inside it. Flash is as close to ubiquitous and you can get.

    Ideally, the user would never know the difference or see anything different than looking at it in FF or IE. (Except without rendering issues)

    @John: I also think it would lead to a serious leap forward in web design and develop innovation. Alot of this depends on what Adobe does next.

    Reply
  15. tomq

    I’ve been working on some new architectures using Java, Spring and Flex as the UI. I’ve got everything working great, and yes is will deploy and work in AIR. I think the Flex has great potential as a UI; fast, cross browser and cross OS compatible. That being said, there are still some definite things that need to be worked out by Adobe.

    The Flex Data Services component, now a part of Lifecycle are way to expensive. 6K/cpu up to 20k/cpu. I’m currently using an Open Source alternative (Granite Data Services) that works well, but is not production ready. In my opinion Data Services are very necessary to the success of Flex and also AIR. Without being able to connect your applications easily to internal or external data services, your applications are pretty much just plain old Flash apps. Nothing to exciting there. It’s when your applications can connect to external services, i.e. Google search, or Ebay, or Amazon, or whatever…that’s when things get really interesting.

    Adobe has always had some great ideas and didn’t know how to market them correctly. I’m just hoping they don’t do this with Flex and AIR.

    Reply
  16. Eric

    Even better, once some hacker/phisher finds an exploitable bug in Webkit or whatever engine, he can use this approach to make that exploit work on any browser, on any platform…

    Reply
  17. Pingback: Andre’s Blog » Blog Archive » Can Flash and AIR make the Browser and Operating System Irrelevant?

  18. tam

    The thing is: The most people have flash, so you will do content for a big number of people. The most people use IE8 which is not good because doesn’t implement good standards such as canvas or video TAG. Even if browsers implements Video tag, each one has its own codec (puffff, your contents won’t be cross browser). THIS IS A VERY GOOD SOLUTION UNTIL ALL THE BROWSERS FOLLOWS THE SAME STANDARDS, and the best of this solution is: YOUR CONTENTS ARE HTML5 AND ARE VISIBLE FOR COMPATIBLE BROWSERS WITHOUT THE HACK

    Reply
  19. Kit Grose

    I’m a bit late to the party, but the biggest issue I can see is with Flash sandboxing (you can’t access the file system IIRC), which would limit the ability for things like INPUT TYPE=”file”, as well as other FS-integrated solutions.

    Also worth noting is that WebKit adds a pretty significant download overhead to the Flash Player download, especially if, like you say, you embed all previous versions of the codebase in the player (as Flash does for Flash v6, v7, etc.). You’ll be turning an already bloated download into a massive download.

    But God it’d be lovely; coding for WebKit only is glorious. 

    Reply
  20. Pingback: Browser Possession Part III | commadot.com

Leave a Reply