Things holding me back - part 2
Last week I wrote part 1 of this essay
, essentially comparing iCab and Mozilla Firebird.
In the end iCab came out on top. Without Firebird's plug-ins there would be no contest. Comparing just the browsers iCab is vastly superior for web authoring, even though it's lack of CSS
checker, validating pages on the fly, no clicks needed. It also offers contextual menu integration with BBEdit
, the king of text editors.
Yet there is a problem with this, and it is support for standards and going forward. Currently I design almost exclusively using tables based layouts. There's loads of things I do using CSS but no positioning. But the more I learn about CSS, the more I become impressed and the less I do in tables. Now I can accept that some things just plain don't work in a browser, at least in a visual way. As long as all the content is there it should be OK. If the code validates there's really nothing to do except hope for a new browser version or else it's a safe bet that the users of these challenged browsers are quite used to odd-looking websites and they won't care too much about yet another one. It may be annoying but there's only so much you can do as a developer.
In this light it is extremely important for a company like iCab to move forward on it's promise of CSS support for iCab 3, if they deliver they will be, beyond doubt, the best single browser available for the Mac that will deliver the modern web to users of aging technology in the form of the millions of pre-OSX Macs still out there, doing a day's work and being useful to those with less money to burn.
I believe they can do it. They have shown they know what they're doing. iCab still has the best support for HTML4 of any browser, on any platform. It puts Safari to shame in it's rendering of pure HTML. iCab's comprehensive preferences and filtermanager make Mozilla/Netscape curl up in a corner and weep. Sure some of it's extreme configurability takes some getting used to, but this is the power a user gets when she downloads the 2.4 megabyte of an iCab install. You don't have to use it all, just the parts you need.
So what does this mean for the state of the web in the near-by future? iCab will get there, and if it takes a while it's users will cope. If we design for the future who will be left out? In the last few years I've learned that if I write valid code I will minimize problems. I make some safe assumptions though: I use tables for complex lay-outs; I use loads of tags like
, even though there are some browser out there who don't render this well or at all. In the end I always make sure the important content stays visible, even if the browserssoftware doesn't do anything with things like title attributes in certain tags. So be it. I don't worry too much about the Mac side of things anymore, there's loads of good browsers for Macusers, they have choice, and now that Apple has released Webkit
, the rendering engine of Safari, making your own browser is fairly trivial, I know, I've got one here on disk a friend of mine made in a few minutes, it may be bare bones, but I can tell you it's fast.
Moving forward means supporting and writing according to specifications laid out years ago. Such is the state of browserdevelopment. I feel the browsermarket as a whole is moving forward at last. There's some cross-platform Mozilla-based browsers that not only deliver on standards support and rendering quality, they also deliver on usability in the form of intuitive user interfaces and speed (start-up speed that is, who has time to use a browser that takes a minute to load?). Opera's offerings to *nix and windows are impressive. Now all I need is for Microsoft to move forward in a significant way. Not because I use their browser but because my visitors do and it is for them that I work the web.
Next week read more about the problems all of us may face with Microsoft's winning of the browserwars. I may also rant about quircks mode versus standards mode if the mood strikes me.
Forgive them father Berners-Lee for they know not what they do.