Browser Daydreaming

This entry was published at least two years ago (originally posted on January 9, 2003). Since that time the information may have become outdated or my beliefs may have changed (in general, assume a more open and liberal current viewpoint). A fuller disclaimer is available.

A few days back, Phil asked what we’d like to see in a web browser. I initially responded in my usual semi-flippant fashion, but after running it through my head for a couple days, I’ve actually got some ideas.

To start with, I’ll look at web browsers as divided into two core components, as outlined by John Gruber on Daring Fireball:

It is essential to understand that there are two huge, almost completely separate tasks involved in producing a web browser. The first is the HTML rendering engine — the part of the browser that parses HTML and turns it into an on-screen graphical representation. The second is the browser application: the windows, menus, buttons, and dialog boxes.

I’ll start with the second part — the application itself. The things I’m most interested here are scattered across multiple browsers at the moment, and I do end up wishing that they were all in one package. Key things I’d like to have in my ‘ultimate browser’:

  • Safari’s clean, simple interface (without the ‘brushed metal’ look, though).
  • Safari’s speed.
  • Chimera’s tabbed browsing (unless someone can come up with something better).
  • Safari’s bookmark management.
  • Internet Explorer’s form autofill.
  • OmniWeb’s beauty.
  • The ability to tab among all page elements — links, form elements (text fields, buttons, and menus).
  • Full-featured contextual menus (Safari’s are pretty anemic at the moment).
  • And there’s probably more that I’m not coming up with at the moment.

When looking at the other side of the browser experience, I was kind of inspired by Jason Kottke’s browser integration musings and Mark Pilgrim’s wondering if Safari should be intentionally buggy (and for the record, no, I don’t believe it should, but that’s another post for another time).

Dreaming about the perfect UI for a browser is all well and good, but we’re still faced with the dilemma of which rendering engine to use. Each of the major engines out there (IE Mac, IE PC, kHTML [Safari, Konqueror], Gecko [Chimera, Mozilla, Netscape], Opera and OmniWeb] has its own collection of bugs to be worked around, causing frustration for both web designers trying to design sites that look equivalent under all browsers, and for end users who, depending on their level of expertise, may or may not understand why any given site doesn’t seem to work in whatever browser they use.

So, what I’d kind of like to see, would be a plug-in based interface for the rendering engine, easily changed via a menu choice somewhere. Find a way to wrap the latest build of any given rendering engine in a small piece of plug-in code, and drop it in an “engines” folder for the browser app. The app would come with one default engine (and as long as I’m living in a perfect fantasy world, let’s make that engine an as-yet mythical completely strict standards-based engine), but at any given point, you could go to a menu and switch to another rendering engine, which would then re-render the current page (or all pages — let’s add a preference option to select whether rendering engines would apply on a global basis or window-by-window) with whatever engine was chosen, which might be less strictly accurate, but might be more compatible with whatever mess of code the user is currently attempting to view.

I have no idea how feasible something like this might be, and I don’t think it’ll ever happen, but hey, I like the idea. Of course, in a perfect world, I’d much rather see standards-compliant websites that worked in standards-compliant, bug-free browsers, but I don’t expect that’ll be happening anytime soon. I can dream, though….