Building your own browser sounds like a terrible idea, especially if you’re a front-end developer by trade and don’t know any C++ or other native language. Even so a couple of years ago I decided to see if I could and by now my browser has developed into a serious project. How’d I get the idea? In…
The great divide
A long time ago, there raged a war. At the time I was too young to notice much of it, but there were a great number of casualties. While the two major forced kept making new rules, the innocent inhabitants were forced to pick a side and fight along.
I am, obviously, talking about the Browser Wars of lore, between Internet Explorer and Netscape. At the time, both browsers were rapidly innovating and adding new features, — however, they both implemented different stuff, never the same thing in the same way. This caused web developers to develop for one of the two, two different sites for two browsers, or one sub-standard website that worked in both.
Luckily, This is all over now
Now, with increasing standards based browsers, this should be a thing of the past, right? wrong!
While we’re all piling over the new stuff the Big Four, Safari, Opera and Firefox (and, IE8, I ‘spose. At least, some people. I think…) come up with, both in own ideas and in standards support, there is an increasingly divergent pattern visible.
It seems that with every new nightly build, Safari (Webkit) adds a mindblowing new feature that’s still lacking documentation but oh my, it’s shiny and f-ing cool.
Firefox is, well, playing catch-up with the above two, adding a bit of the idea’s from safari, opera or, if you’re lucky, both. To be honest, it’s also making great headway on SVG.
And IE isn’t even trying, adding their own non-conforming microformats and just getting round to CSS2.1. well, whoop-dee-doo! Now go to bed and stay there, this is grown-up time.
What do you want to be?
Opera is heading towards ultra-super-duper standards support. Safari wants to take over the desktop. Firefox wants to integrate the desktop and the web. Internet explorer… just wants to play with the big kids.
But because of these goals (as they are perceived by me, anyway) all the browsers have different priorities in what features they support. This makes business sense, but it’s incredibly frustrating for developers. Web standards are of course supposed to be the baseline here, but in reality they are not, and standards-based feature support is just as diverse as home-grown innovations.
What can we do
The way I see it, for developers, there are a couple of options:
- We can stick with HTML4 and CSS2.1 for the foreseeable time, they’ve solid support nowadays
- We learn every feature of every browser and serve (slightly) different pages to each
- we give up and all start using plaintext.
Obviously the latter isn’t going to happen, but the first two look suspiciously like the choice the martyrs in the Browser Wars had to make. Only instead of two browsers, we now have four to support. (Being extremely positive and forgetting about IE6 and IE7)
This is not a choice we should make
I’m all right with different browsers having different goals, and them needing different features for it. However, we thought up standards for a reason. The reason being interoperability.
What I think needs to happen, is an even larger degree of openness concerning features. Not business goals, just features. With 50% of the Big Four being open source, this shouldn’t be hard. Both Webkit and Firefox already have a lot of documentation, and Opera, despite being closed-source, offers a tremendous amount of documentation as well. (Notice who’s missing…)
All I’m asking for…
…Is a single document, outlining the baseline support in the browsers for the coming years (increasing the baseline each year), agreed upon by the Big Four. That’s is all that’s needed to help mature the web in a developer and user-friendly way and will still allow each individual browser to focus on it’s business goals.
Head over to Polypane.rocks to sign up for the beta …
This notation works with both 8 digits and 4 digits (shorthand notation) …