Redrawing the Browser’s Borders
April 25, 2008 – 6:59 pmTraditionally browsing architectures have had a rather arbitrary separation between the rendering engine (suitable for embedding and reuse) and the browser user interface (not so much). These terms are a bit misleading because “rendering” necessarily entails far more than just painting HTML on the screen; the core engine is likely to include some pretty beefy networking capabilities and much else besides.
The other day Todd Ditchendorf (aka Mr. Fluid) tweeted the scope of this single-site browsing ambitions:
My goal is to remove any reason for someone to prefer Safari over a Fluid SSB for general browsing due to a missing feature. Getting there…
Then Mark Finkle gave in to mounting pressure from the ruthless Prism user community and landed a patch to add “basic browsing buttons” (i.e. back, forward and the like) in an optional toolbar. This comes on top of an ongoing struggle to get a preferences dialog into the product since Firefox’s version is not part of the platform. User requests continue to stream in for things like a user interface for configuring proxies and browsing in multiple tabs (a gotcha because the tab browser control is also specific to Firefox). From what I’ve heard, building a usable browser on top of WebKit is at least as onerous, requiring the implementor to reinvent the finer points of the browser’s user interface and high-level functionality one painstaking line of code at a time.
Any preconceptions about where the underlying platform ends and the actual browser begins are likely to be confounded immediately by some unanticipated real-world use case. Future browser architectures should simply do away with the issue altogether by making the entire codebase reusable, right up the finer details of the user interface. Deploying something like an SSB should require an hour or two of tweaking, not weeks or months of intense development.
Some might argue that SSBs are an exception because, for all intents and purposes, they are just normal browsers that happen to restrict which sites you can visit (and do away with some of the UI elements made unnecessary by these constraints). But we didn’t anticipated the idea of an SSB when today’s generation of browser architectures were conceived, so what reason do we have to assume that we are able now to foresee what the future of browsing might bring?
4 Responses to “Redrawing the Browser’s Borders”
tabbrowser not being part of toolkit is largely a political decision, not a technical one. It was decided that it was too onerous to decouple tabbrowser.xml from browser.js, basically, and that browser.js didn’t want the compatibility constraints that “the platform” has.
By Boris on Apr 26, 2008
Thanks for the clarification. I’m guessing that most of the stuff in browser is there for mainly historical or “political” reasons. Hopefully we’ll see more stuff migrate into toolkit or elsewhere over time.
By Matthew Gertner on Apr 26, 2008
A huge issue for web application developers is not currently on anyone’s radar AFAIK: text editing.
In short there is no standardised (rich)texteditor just textarea. All the midas, contentEditable and whatever crappy non-compatible APIs out there are not going to fix this.
Ever tried authoring a simple multi-column, multi-row table inside a blog post?
As an alternative short term solution, I thought I would get the best crappy existing rich text editor that works in Mozilla. Then I thought I’d marry it with Prism and voila I would have a web app admin that is reliable and highly functional. A user could simple install “my website admin software” and have a shortcut on their desktop to load the ‘editor’ regardless of which browser they normally use.
Mark Finkle literally said that Prism cannot do this and that I should look to AIR.
Conclusion:
1. Get texteditor standardised now, as part of HTML5 and get it implemented consistently across browser; or
2. Give me a CCK-style wizard for creating a custom build of xulrunner that takes the form of an installable SSB-like web app admin environment and allow us to build the best rich text editor we can possibly build out of the Mozilla APIs.
By pd on Apr 29, 2008
Yeah, I totally agree about editing capabilities in the browser. In fact I blogged about this three years ago: http://www.allpeers.com/blog/2005/04/13/ready-aim-edit/. I’m not sure that so much has changed since then.
I tried to create a document in Google Docs the other day with a straightforward table-based layout and I nearly went nuts trying to get it formatted in some semi-acceptable way. This is bound to (continue to) be a major impediment to adoption of Docs. Maybe we can expect Google to include a fully functional cross-browser editor implementation is some future incarnation of Gears?
By Matthew Gertner on Apr 29, 2008