Five things that are still broken in browsers, ten years later

I’ve been on the ‘net for a good while (even before it was called the Internet), so I’m pretty used to technology taking a while to sort itself out.

Nevertheless, considering all the hoopla regarding (for instance) Firefox 3, whatever-is-the-working-version of IE and Safari (or should I say Webbed Squirrel Fish Kit?), I am astounded that it’s 2008 already and nobody has fixed (and by “fixed” I mean really fixed) these five things:

The utterly idiotic, asinine and counter-intuitive file browse field/button combo ought to have been replaced by a multi-file drop target years ago.

We have the technology to do that in every major operating system, and yet people keep having to reinvent the wheel and use funky Flash uploaders and whatnot.

Guess what, none of those are the right solution. The right solution, as far as I’m concerned, would have been for the HTML5 committee to get off their collective arse and deliver something better than “RFC 1867”:RFC:1867 (dated 1995) now instead of doing stupid things like writing a specific codec name in their spec, whether it’s a free one or not (yes, “Ogg”:Wikipedia:Ogg_Vorbis zealots, I’m looking at you).

And yes, I know about this. It isn’t done yet. And it’s only half a solution.

WYSIWYG editing

This, too, ought to be standard by now, and yet there are a bazillion workarounds – none of which can cope with inserted images or cut & paste from desktop applications properly.

All I ever wanted was a textarea replacement that POSTed a MIME multipart with the images and text I insert, and by the looks of current efforts, I’m going to be lucky if I get rich text with re-usable CSS styles, let alone something that can deal with images.

Again, this should be an integral part of every browser. I am utterly fed up with ActiveX editors for corporate intranet apps (which handle cut & paste from Office beautifully, but generate hideous markup and opaque data blobs) and dinky JavaScript editors that sort of do WYSIWYG HTML until you try to add an image or paste something from a desktop app – at which point they become slightly more useless than your typical X application circa 1991 (i.e., cut & paste sucks).

Everyone does it differently: some save MIME multiparts (as they should), others sets of files inside a folder, and others serialize their internal browser data structures.

Shock, horror, Microsoft is the one doing it properly!

Yes, you read that right – .mht files are (gasp) more standards compliant than Safari .webarchive files.

If you have a Mac, go see for yourself – I’ve mentioned before that there is code to convert between .mht and .webarchive files, by dint of unpacking the MIME structure and loading it into a browser context.

I fervently hope that one of these days my hard disk will stop getting littered with folders entitled random page_files every time I save a page in, say, Firefox (that stalwart of web standards).

I don’t want to care about VML, SVG or canvas – I want something that just works across browsers, and wish people would stop faffing about with plugins and reinventing the wheel.

And yes, I know that some JavaScript libraries are trying to fix that. I think I’ve listed them all in this Wiki, and despite the technical brilliance of most of them, they’re all doing the wrong thing – fixing something that ought to be common across browsers.

It kind of reminds me of the GIF wars, except that the SVG spec has become a political quagmire rather than a troll patent gate.

Again, I couldn’t care less about Dashboard, Opera widgets, Widsets or the current hysteria surrounding desktop widget engines, personalized start pages, and (of all things) postage-stamp-sized widgets for mobile phones.

And yes, “widgets” have been around for a while. Even before Microsoft tried to get Digital Dashboard (and its quaintly named “nuggets”) off the ground¹, there were a bunch of people trying to build HTML snippets with a life of their own.

And we’ve been at it on the desktop since Konfabulator (which was the first serious cross-platform effort), and it hasn’t really taken off or turned into a business model for anyone.

I just want it all to stop. It’s pointless, it’s a waste of time and energy, and it doesn’t improve any kind of experience for anybody. If we must have widgets, then please let’s have some kind of agreement as to exactly how sucky they will be regardless of platform.

Someone needs to sit down and define a DTD (or equivalent) for an HTML widget and exactly what it’s DOM can (and can’t, ever) do and pick a decent packaging and deployment method to end all this misery of umpteen incompatible widget platforms, pronto.

And that’s it, really.

Oh, and I’d just like to take this opportunity to say, to all of you out there raving and foaming at the mouth about web applications and storage APIs that I don’t want browser-side storage. That means turning the browser into a fat stateful client, and down that path lies madness – and the negation of what brought the browser into being in the first place.

But I guess that some people will push on regardless, since “they clearly cannot remember the past”:Wikipedia:George_Santayana.

—

¹ I’m not going to mention the unmitigated disaster that Active Desktop turned out to be and focus on ways to define widgets, OK?