This is the monthly archive for December 2007.
Alex talks about the upcoming IE release, and points out the cause of Microsoft's tight-lippedness (is that a word?): We have harshly (and rightly) rebuked MS in the past, and they don't want to make any false promises again. The easiest and safest way to do that is not making any promises at all. That's what's happening right now.
Alex also wonders about priorities for new browser releases, and he places innovation above standard support; that is, if a browser vendor has a great innovative idea, it shouldn't be forced to go through interminable W3C procedures before being allowed to implement it.
One can agree or disagree with Alex's thesis (I tend to agree), but the really important point is that the standardisation process has become kind of stuck. True, W3C has been mending its ways for the past year or so, but it's still going too slow.
And we all know what happens when there aren't any standards: browser vendors invent their own. Nowadays we can at least hope they'll pay attention to each other's efforts, but the essential problem is the same that plagued us during the Browser Wars.
Nonetheless, this situation has advantages as well as disadvantages. The most obvious advantage is a new wave of innovation, and that's always a good idea.
Will W3C and the web standards movement be cast in the role of opposing innovation in the name of the standards? That would be bad.
I feel that we're on a crossroad now. Standards support, though still important, isn't the be-all-end-all of everything Web any more. We've basicaly won the standards war—browser vendors now pay attention to us. Nonetheless, winning the war might have brought us a whole new set of problems, problems that are mostly centred on W3C being (or having been) so slow.
Which road do we choose? Strict adherence to the standards in all respects—which brings along a certain slowness; or a more innovation-driven approach—which may lead to proprietary extensions (in the sense that they aren't in the specs; but not necessarily in the sense that they differ from browser to browser).
Something's about to change. Something HAS to change.
Let's see where it's headed.
Well, the news is out: the next version of IE is coming and it's called IE8. (Personally, I wonder why they make such a big deal of the name, but the MS marketing department is not to be denied.)
IE8 isn't actually ready yet, and Microsoft asks a bit more of our patience:
In the meantime, please don’t mistake silence for inaction.
Laclan Hunt explains a few key concepts of HTML 5 in this ALA article. Good to know what's coming.
Now that mobile phones have entered the mainstream of web development (well they haven't, not quite yet, but let's pretend they have), David Storey turns to the next frontier: the Web on TV. Having tested a few proprietary systems way way back in 1998, I already know it's not as easy as it's supposed to be.
James Edwards makes the remarkable discovery that IE doesn't support the DOM with complete correctness; even if we forgive it for not implementing part of it.
Maintaining a major set of compatibility tables over the past seven has already taught me the same. James adds a few interesting notes, for instance about a second argument to the
getAttribute() method, which leads him to conclude that Microsoft hasn't even implemented its proprietary stuff correctly.
Figuring out exact levels of DOM Compatibility is SUCH fun, and I'm glad somebody else is feeling the strain, too. BTW: except for me, James is just about the single person on earth who's going through the major hassle of creating compatibility tables, so I'm glad he's coming to the same conclusions as I have. Misery loves company.
Liorean gives a very useful overview of who said what in the increasingly impossible-to-follow ECMAScript 4 debate.
Excellent idea, especially as they already have done a basic test of the most important email clients. Surprisingly (to me, at least), most clients handle their acid test really well.