Back in June, I went to see David Bowie in concert in Bergen. It was cool. I could go on
for some time about the various technical details I noticed, like the amusing one 500ms delay
on the (rather distracting) "live" video feed in the background (especially amusing when they
cut from one camera to another, and the second has the display in frame, so you see the cut
again 500ms after the first cut, in the background of the shot), but it would be pretty lame,
so instead I'll just say that I enjoyed the concert, and that the music was great.
I also enjoyed the lower profile concert we went to later that evening, although the
band's name escapes me.
Between those two concerts we briefly stopped by the weekly Bergen Linux User Group pub meet, where I got to meet
some of the people involved in the famous
implementation of RFC1149. They told me
there is talk of making a second implementation, in the hopes of proving interoperability and
therefore securing Standards Track approval for the RFC. I didn't know whether to encourage
them or run away.
In Oslo, we went sailing aboard the 404 Not Found, Håkon's boat, on the Oslo fjord. The first
time, the water was so cold that when I dived in, I screamed all the way to the surface...
the second time was a lot warmer, thankfully.
On the other hand, on the second sailing trip the wind speed was quite low, and our 21st
century impatience resulted in us drifting slowly from gas station to gas station, looking
for one who would fill us up on a Sunday evening. Under the captainship of Håkon and
the navigation of MarkS, the fuel situation was soon resolved, and nobody had to be sacrified
for the greater good.
Late last year I set up a
system called ART at Opera: the Automated Regression Testing system. Over the past few
months this has caught a number of regressions that we may otherwise not have noticed, and
thus hopefully increased the quality of our more recent releases.
ART is quite limited, however; it only works for Windows, it only does screen-capture
testing, it's only one machine at a time, etc. So after designing and implementing ART, I
started designing SPARTAN, the Systematic Performance Analysis and Regression Testing
Automated Network. This would be a distributed ART system with all the trimmings,
cross-platform, testing all the various branches and products we have on the go, even doing
performance analysis and drawing charts. Unfortunately around the same time a lot of my other
projects starting taking more time — editing specs for the W3C and the specs that later
became WHATWG's, writing test suites, as well as some
Opera-internal stuff I can't write about — and so actually SPARTAN was shelved.
Meanwhile, however, ART was finding regressions, and showing that it could do so
significantly faster than the manual testing Opera had been using so far. So eventually I
started looking for someone that Opera could hire to implement SPARTAN for us. This is how Kam came to work for Opera: he's here
on a three month project to implement SPARTAN.
Kam's presence of course means that his Gamecube is once again in the same country as me.
I vehemently deny the accusations that the story above about hiring Kam because I was looking
for someone to implement SPARTAN is just a cover for me getting to play on his Gamecube
again. And the recent release of Mario Party 5
around the same time he and his Gamecube arrived in Oslo is a complete coincidence. Having
said that, Mario Party (and later WarioWare, which is
even more insane) has been the source of many fun evenings. He also "forced" me to play
Pikmin 2, a game that involves much maiming and killing of little cute coloured
creatures.
There is strong evidence that the water supply in the Nintendo offices is laced with
hallucinogenic drugs.
Scott Collins is in town too, working in the same building as
Opera even, although (somehow) we managed to not run into each other except for the one time
we specifically planned to. Bloo is also around, and Junyor will be moving over here too in a
few weeks after his wedding. Bloo is currently spending some of his work hours writing tests
for the Web Forms spec, and has
been finding all kinds of edge cases in the process, as people subscribed to the WHATWG
mailing list have undoubtedly noticed.
I made several purchases this summer. I purchased the Norwegian edition of a board game
known as Monopoly. I purchased a cheap badmington set. I purchased a couple of trains. Update: It has been pointed out to me that actually it was Eira who bought the badmington set and not me. In hindsight, that does indeed make much more sense. When have I ever bought sports-related equipment before?
I love Monopoly. The first few games we played were reasonably limited in terms of house
rule modifications, but then we played a game where the deals were not limited to
instantaneous tangible trades, as the official rules require. I love games where anything
goes simply because of the sheer insanity that ensues.
In this particular game I negotiated a deal whereby I owned both of the big blue
properties, was responsible for all house purchases and sales on the set, and would give half
of my income from those properties to another player (who originally owned one of
the blues). Note that the deal was structured around the actual income, not, as
would be fair, around the theoretical amount which I would be owed when someone lands on the
property according to the normal rules. Note also the curious absense of a "free rent" clause
for the other player. (Actually, the player in question volunteered to pay for rent when he
landed on the property, it wasn't my laughable negotiation skills that got me this deal.)
The significance of all this didn't become evident until later on in the game, where my
partner in this deal needed cash, but had no properties of his own. In fact, his only income
was the big blues. And he only got half of what I got. So when someone landed on the
property... I suddenly had a heart and charged the poor soul only $4. Twice. Sure, it meant I
didn't get any money from that monopoly either, but then I had others, with much fairer
deals. The big blues thus sent my partner out of business. Good times!
Talking of games, last Sunday I played Ursuppe ("the primordial
soup"), wherein you play some amoebas that have to eat each other's excrement, while
purchasing genes with which to improve your survival rate. A fun, if rather odd, game. I am
trying to think of a way that one could introduce the concept of Evolution into such a game
without removing the skill aspect (which is somewhat of an oxymoron, but still).
The badmington set was used once. Thankfully nobody saw us.
This leaves just the trains. Quick autobiography: ever since I was... well, as far back as
I can remember, in fact, I have wanted to own a train set. When I first wanted this, my
parents bought me Brio wooden
trains. Those were great. I had kilometers of track and lots of engines (well maybe not
actual kilometers, but certainly enough to cover the entire floor of my bedroom with track).
Then later they let me buy a Märklin starter pack,
which I quickly expanded. Electric trains, electric points. My dad helped me with the
landscaping. I remember having a huge board on ropes that I could lower from my ceiling to
play with.
But what I really wanted was Märklin Digital. The holy grail: digital control
over trains and points so that you can individually control each train, without having to
have different parts of the track with different transformers. And the cherry to top the
whole thing off: The Märklin Digital Interface 6050 unit, so that a computer can run the
entire layout.
Unfortunately Märklin Digital costs a fortune. So I spent my childhood absorbing the
catalogue, wishing for the day where I could afford and own my own digital set.
Fortunately, I now have a job! And thus I am now the quite proud owner of a small digital
layout with two gorgeous Swiss trains (29858), a Control Unit 6021, and the cherry itself,
the Märklin Digital Interface 6051 unit. (Yes, in 20 years, they've only revised the
protocol once. That's some backwards compatibility for you.)
To connect the Digital unit to a computer, you use RS232. Problem: My work-provided IBM
Thinkpad X31 has no serial port. My old Inspiron 8100 does, but it suffered catastrophic disk
failure on its internal disk about 2 years ago, and catastrophic disk failure on its media
bay removable disk last summer.
I had had the internal disk replaced several times, but each time it died on the spot
(almost literally, the new disk would die during OS install), so, since I the media bay disk
worked fine at the time, I had pretty much given up on Dell fixing the disk. Then when the
media bay disk died I had the X31, so I just packed the Dell away and forgot about it.
Needing an RS232 port changed all this. You see, the 8100 has ports for pretty much
everything. So, two months from the end of my international, next business day, on-site
warranty, I started the Dell Dance.
First, since I had moved country, I had to get Dell to transfer my warranty. That was
surprisingly easy actually. They claim it takes one or two business days, it actually took
all of 15 minutes.
Second, I had to reverse-engineer the Dell Support Broken Disk Script. I had a head start
on that since I'd gotten all the way to "we agree your disk is broken we'll send you a new
one" a couple of years ago, so I copied and pasted the text from those e-mails and added the
bits about my media bay disk also being dead, and the CD drive having issues at the same time
as the disk. The idea here was to convince them that not only had the disk died, but that the
integrated IDE controller (and thus the entire motherboard) needed replacing.
I got an e-mail back. Not convinced. Turns out you also have to mention something about
running the disk diagnostics and something about trying the disk in other machines. I added a
paragraph or two quoting all the diagnostics programs I could run (I have now seen the same
disk receive errors 17, 27, 37, 65, 67, 75, "no SMART support", "no disk", and "00 PASS" from
the same BIOS disk diagnostics program all on the same day — beat that!), added a
paragraph explaining that given the destructive nature of the problem I had no intention of
testing the disk in other machines or other disks in this machine, then sent the e-mail
again.
Dell Norway do not respond to e-mail very quickly.
But eventually, I got a reply back, saying they were convinced, and would repair the
computer. I sent them my details and waited.
And waited. Dell Norway really do not respond to e-mail very quickly. After about
two weeks I wondered if maybe I had deleted an e-mail from them by mistake, thinking it was
spam, and so sent them a second copy of my e-mail.
A few days later, I got a reply. Yes, we'll come tomorrow. Horrah!
A courier came. I handed over my laptop, expecting him to take it to Dell HQ and have them
fix it. It turns out he wasn't a courier. He was a technician. He fixed my laptop on the
spot, in Opera's reception area. Took him no more than 20 minutes to replace the motherboard
and both disks.
I am pretty impressed. I had for some reason assumed that "on site" meant "you don't have
to drive to use, we'll send someone to pick it up", but apparently it really does mean "on
site". So while I am disappointed that every Inspiron I have ever heard of has eventually
suffered from serious diskache, and while I think it should be a little easier to convince
them that something is wrong, I am moderately pleased with Dell's technical support.
(They are even quite happy to support machines after you've installed Linux on them, so long
as you agree to try installing Windows to see if that solves the problem before you ask
them to replace any hardware.) I'm considering extending my warranty.
The machine has been working smoothly since the repairs, and so I've been writing some perl scripts to control my
trains. There is something very cool about typing in some Perl code and having switches
switch, engines move, and sensors report back. I'll probably go into more detail about all
this at a later date.
Over the last few months I've also been busy reading books. I read Peter F. Hamilton's
Pandora's Star, part one of the Commonwealth Saga; Peter F. Hamilton's
Fallen Dragon; Neal Stephenson's Zodiac, the
Cryptonomicon, and Snow Crash; The Tenth Planet, book
one of a series by Kristine Kathryn Rusch and Dean Wesley Smith; Robert Doherty's Area
51: Nosferatu, book eight in the series; Robert Pirsig's Zen and the art of
motorcycle maintenance; Scott McCloud's Understanding Comics and the
sequel, Reinventing Comics; Orson Scott Card's Ender's Game (for
the second time); and a few others whose names escape me right now.
They were all good. Now I'm reading some Wodehouse and another Neal Stephenson.
A few weeks ago Opera had an off-site wherein 40 or so of us from the Oslo office went to
a Go-Karting establishment to drive around a "Technical Track" (well that's what the manager
called it during our briefing). That was great fun. We had eight teams of five people each
and 90 minutes of driving time. I was quite pleased with my times given that it was my first
time. Eirik has photos.
I've been to the cinema a few times recently too, seeing, amongst other things, I,
Robot. If you haven't seen it and don't want to be spoilt, stop reading now.
As a kid, I read every Asimov book I could lay
my hand on. I knew the three laws by heart. I didn't realise it at the time, but the three
laws had in fact reached some kind of holy status for me. Seeing the three laws in a
mainstream movie theatre, as the title sequence of a Hollywood production, had a strange
effect on me, much as I imagine Catholics might feel if the Pope was to speak to them
personally.
As far as the story itself goes, I quite liked it. I've heard a lot of people take offense
at the movie, but I don't really understand why. For example, "They stole Asimov's title to
sell the movie" is a stupid statement, since the book's title wasn't Asimov's idea in the
first place (it was Eando Binder's; Asimov's editor thought it sounded better than Asimov's
title, as any self-respecting Asmiov fan knows). Saying that the story was different to the
book is a truism, but then the book was an anthology, not a single story, and the film never
claims to be anything more than "suggested" by Asimov works. (Indeed it was significantly
more true to Asimov than I had expected. Did I mention it prominently featured the three laws
in full?)
More specifically, saying "no Asimov robot would ever act like the USR core (VIKI) did" is
stupid too: VIKI derived a zeroth law ("No robot, through action or inaction, may let
humanity come to harm"), which is exactly what Daneel did. Asimov even has a story where the
robotic protagonists interpret their law in such a way that the term "Human" includes
themselves (the robots). In fact the only thing I would say VIKI did that doesn't seem very
in-the-Asmiov-spirit, as it were, is the level of violence with which it "protected" the
humans near the end (even killing some of them — did that really protect humanity? I
can't see how, surely there would have been less fatal methods for doing that).
The moral of that story, however, IMHO, had nothing to do with robots or rules of robotics
or the pitfalls of your estate licensing the rights to your books to Hollywood post-mortem.
The key part of that movie is that VIKI can remotely update the firmware of the robots. A
central location — the USR headquarters — can, under the guise of fixing bugs in
their software, run arbitrary code on devices across the planet.
Now, in the movie, none of the humans were evil, per se; it was a sentient or
near-sentient computer that was the problem. But still, it basically meant that anyone with
root access at US Robotics could take over the world if they wanted. In the movie it was an
artificial intelligence, but it could easily have been the company CEO with delusions of
grandeur, a sysadmin gone crazy, a discontent employee, or (hey, it's in fashion these days)
a techno-terrorist.
So the conclusion I drew is that it would be very bad for a single entity to be able to
arbitrarily run code on devices world-wide.
I keep seeing very odd messages be sent to W3C lists (which are very frequent targets for spammers due to the likelyhood of the W3C site being crawled for e-mail addresses). An example of one arrived earlier today.
Strange things to notice: The body makes sense at first glance, but then seems rather weird when you read it carefully. A very similar message was sent back in May. Both messages have the same large quotation and then have a link to a site that is probably hoping for increased Google rankings. Today's, for example, links to a site that looks very innocent but contains a link to a page containing a lot of links to porn sites. Both e-mails have the same from name but very different addresses. Both are cross-posted to two very unrelated lists. Today's has a very odd attachment — very odd, that is, if you don't notice the numerous links to porn sites hidden within. And so forth.
I'm thinking that HTML should have an element that basically says "content within this section may contain links from external sources; just because they are here does not mean we are endorsing them" which Google could then use to block Google rank whoring. I know a bunch of people being affected by Web log spam would jump at that chance to use this element if it was put into a spec.
If anyone from Google thinks this is worth considering, let me know as soon as possible. WHAT WG is coming up with lots of HTML extensions, so now's the time to discuss it.
Speaking of which, we added the first draft of the <canvas> element to the Web Apps 1.0 draft proposal specification the other day. It's mostly based on what Apple did, with some changes suggested by various people.
That spec also finally defines the window object which people have been using for years without it ever being seen in anything resembling a spec. Over the next few weeks I expect I'll be adding things like window.location to it, if I can work out exactly how that should work when you set it!
This is all in response to the hundreds of great technical comments we've been getting in response to the WHATWG announcements. I'm slowly making my way through them; at the moment I have another 175 or so to reply to.
I expect we'll be publishing another Web Forms call for comments soon (not that much has changed since last time, but enough has changed that it needs another review, I think). Similarly, Web Apps 1.0 will get a call for comments in a few weeks for the first round of public review. The stuff in that draft is obviously much less stable and very much up in the air, especially some of the more amusing stuff like the menu and tab ideas. I like the general concepts we have, but their execution is currently a little messy. How much they change probably depends on how much backwards-compatibility we're willing to sacrifice.
Several people recently asked me why their scripts, which worked fine
when they were using HTML, stopped working when they started using XHTML
(and actually sent their markup with an XHTML MIME type).
There are plenty of reasons why that might happen. Not using the namespaced
DOM Core methods is one, but few people use the DOM Core methods so it's rarely
the cause. It could also be that their markup wasn't well-formed, but usually
that's pretty obvious since the browser complains about it, and when people
ask me, it's usually because the cause is subtle, so this is rarely it either.
It usually turns out that the reason their code is failing is that they used document.write(),
which doesn't work in XML. Why is that?
XML requires that an XML process abort on any well-formedness error.
Say you have the following:
<foo>
<scrible/>
</bar>
</foo>
Since the </bar> tag is unmatched, the entire document is not well-formed, so the UA has to abort and not display it.
But if we allow document.write(), then you could have
things like this:
Now the document is still not well-formed, so it must still abort
when it gets to the </bar> tag. But the problem is
that if we process that document, then when we get to the script, we
write out a <bar> start tag after the <script> block, and
now when we reach the </bar> tag, it matches
something! So the UA couldn't tell if it was well-formed or not.
So in order to remain compliant with XML, document.write() doesn't
work on documents that are parsed with an XML parser.
To be precise, they invented a new element, a new attribute, and a
new value. The new element is canvas, an element that
does nothing except provide a DOM interface for graphics drawing; the
new attribute is composite, a presentational attribute
that can be applied to images; and the new value is
search on the type attribute of
input elements, which provides a control for incremental
search interfaces.
These new tags are to be used in several places. One of these is Dashboard,
where applications written in an HTML-like interpreted language are
executed in a runtime environment similar to a Web browser's. Another
place where these tags are to be used, I am told, is the real Web.
The response to this announcement from a number of people in the
industry seemed to be outrage... about the syntax.
Hello?
Here is Apple introducing their own proprietary markup to the Web,
without going through any sort of standardisation first (not even
unofficial standardisation like the WHATWG), and what people complain about
is the syntax?
I
hope that what Dave is really saying is that Dashboard widgets are
actually XML, albeit an XML that looks very much like HTML except
they've added some nifty stuff to it. If so, great, fine, no problem.
XML lets you do whatever you want, really.
So let me get this right. It's ok to send proprietary non-standard markup
over the Web, so long as the angle brackets are XML angle brackets and
not HTML angle brackets?
This makes no sense. Proprietary markup is proprietary markup,
whether it is HTML-based, XML-based, or any other language such as
PDF, Microsoft Word, XAML, or Flash. It's not the exact order of the
angle brackets that matters, it's the lack of open, consensus-driven
specifications, the lack of interoperability.
Eric wasn't the only person arguing that Safari's extensions are
abominable because they can be used as if they were HTML elements, I
just picked on him because I know he won't take it personally!
There have been several "solutions" proposed to the "problem" of
proprietary tags being added to HTML.
The first is using namespaces in HTML. There is
one fundamental problem with that idea. HTML doesn't have namespaces.
At all. HTML doesn't allow namespaces. The Namespaces-in-XML spec
doesn't apply to HTML. However you cut it, there simply isn't a way to
allow namespaces in HTML. If you were to add namespaces to HTML, all
you would be doing is adding yet another non-ratified
extension on top of the original extension.
The second proposed solution is to use namespaces in XHTML,
sending it as text/html. This also can't be done, this time
because while you can use namespaces in XHTML (with some caveats; see
below), you can't send such XHTML as text/html. The only
things you can send as text/html (according to the relevant RFC) are HTML
documents (up to version 4.01), and XHTML1 documents complying to the
compatibility
profile. (Although I would strongly recommend
against doing that anyway.)
The third proposed solution is to use namespaces in
XHTML, sending it using a legitimate XML MIME type. This
could work, but it is limited to XML, and Apple wanted to allow
authors to use HTML. Also, it requires that authors use two
namespaces (one for the XHTML content, one for the Apple-proprietary
content), and exposing authors to namespaces is a non-starter. The
entire point of the Dashboard development environment is that
it be trivially easy to write these applications, and namespaces
are not trivial.
The fourth proposed solution is to simply replace the XHTML
namespace with an Apple namespace, so there is only one namespace.
This is even worse. Now not only would Apple be introducing three new
non-standard tags, but they'd be introducing the whole of HTML
as non-standard tags. No other browser would be able to render such
pages. Accessibility tools would be unable to recognise the elements.
Tools like Google would be unable to understand the semantics of the
page for proper indexing.
The fifth proposed solution is to use a DOCTYPE that would enable
the extensions. This doesn't scale. What if another UA wants to
implement the extension as well? For example, marquee is
required by half the Chinese Web. Originally, only IE supported it.
Now take canvas, the Safari extension. If we had used
different DOCTYPEs for each set of extensions, which DOCTYPE would you
use if you wanted both? (And wanting both is quite likely; imagine a
stock ticker with a graph above it).
There are other problems with DOCTYPEs. Eric unintentionally
reminded me of one when he said:
IBM
already does something like this, having created an "IBM XHTML 1.1
Transitional" DTD that's used throughout their Web
presence.
The IBM DOCTYPE actually had to be hard-coded
into Mozilla to trigger quirks mode, otherwise their site wouldn't render right.
It's also non-standard, and violates the HTML spec in several ways.
If
you run an IBM-XHTML compliant document through a validator that loads and uses IBM’s
DTD to check over the document’s markup, then the document will validate.
This rather misses the point. It still won't be conformant. This is a key point.
Creating a new DTD does not magically make you standards compliant. For example,
here is a document that "validates":
<!DOCTYPE LI PUBLIC "-//W3C//DTD HTML 4.01//EN">
<li>Validation is only a small part of conformance.
I'm sure we all agree it's not conformant, though.
I've probably missed some of the other proposals. But the reality
is that it doesn't matter. If you want to make a proprietary
non-standard extension to a standard that doesn't support explicit
namespacing, you do the same as is recommended for
CSS: put your vendor name into the tag. In the case of the
aforementioned Safari extensions, I would have recommended calling the
new names apple-canvas, apple-composite, and
apple-search. The real solution is to
bring these proposals to the table, get some consensus between
the relevant vendors and other interested parties, and then use that.
For specific features like these, it doesn't take long to get
consensus; they are small features whose basic design can be agreed
reasonably quickly. Doing this also usually means getting wider
peer review, which improves the quality of the API.
For instance, it would have been pointed out that composite should
never have been put into the markup. It's presentational. It belongs in
the presentation layer, namely CSS.
Apple were probably concerned that by talking about this stuff, they would
have tipped their hand about Dashboard. WHATWG is the perfect cover, though. Apple
could have put forward their proposals, discussed them, got concensus, and everyone
would have thought they were just planning these features for the Web Application
space.
In fact, they did do this. Apple also introduced the new range
value for the type attribute of input elements, which
introduces a new control for imprecise numeric data entry (e.g. a
slider). This, as I mentioned
before, is not a proprietary value. This value was
discussed, in detail, on the WHATWG open mailing list,
and forms part of the Web Forms
2.0 draft specification. Here, Apple did the right thing: they
created an experimental implementation of a proposal. Their
implementation experience has already helped the draft (several
changes to the original text were made to more closely align with what
Apple found was actually needed).
So why did they not do this with the other extensions?
In other news, Brendan
Eich gives us his take on the WHAT Working Group work and other
issues facing the Mozilla Foundation in the latest edition of the Gillmor Gang.
I highly recommend giving it a listen.
When we announced WHATWG, several people noticed that the list of members also contained, in addition to Mozilla
and Opera employees, a couple of Apple employees who work on Safari. A few weeks into the project we
also added Dean Edwards of IE7 fame to the list. The members of the WHATWG are an
oversight committee intended to make sure we don't get off-track; the specs are actually edited by me
and based directly on the input we get on the mailing
list.
There were also some people who commented that instead of calling it a Working Group we should have
called it a Task Force, because the resulting acronym would have been much more appropriate. All I can
say is that I wish I had thought of that because that would have been a really funny name.
I recently started on some Web Forms demos, to show what Web
Forms can do and how it can do it without losing backwards compatibility. I haven't done much yet, just
a demo of how to make the repetition model
degrade gracefully in HTML4-compliant UAs, but it's a start. (Sadly the only UA I could find that was
compliant enough to degrade in the right way was Mozilla, so we might well have to revisit exactly how
those repetition model buttons work.)
The first public demo of a Web Forms 2.0 page was actually a very high profile demo,
though I highly doubt that anyone present actually realised they were looking at it. It was during Steve
Jobs' keynote speech at Apple's Worldwide Developers Conference, during the Safari RSS spot.
If you look at the top right of the screenshots of Safari showing an RSS feed, you'll see a little
slider control. That, my friends, is a Web Forms 2.0 <input
type="range"> control.
Something I hadn't realised until recently is quite how many Web applications are hidden away
inside intranet sites. I always knew that there were some there, but the sheer numbers of such
applications is quite surprising. A few people have sent me confidential screenshots of their intranet
applications (with the sensitive parts censored, of course), which has really helped get me an idea of
the kinds of features that would be most helpful to people writing such sites. We'll be addressing a
number of these requests in Web Apps 1.0
proposals once I've dealt with all the recent Web Forms 2.0 comments.
Joel Spolksy wrote an interesting
article explaining why Microsoft stopped Internet Explorer development in its
tracks a few years ago, despite it having ridiculously many bugs. Here's the executive
summary: they realised that IE was competing with their OS to be the preferred application deployment
platform. Since they make money from their OS, but don't make money from IE, the choice was clear.
I think the irony of this situation is quite amusing. HTML, a document format, is invented,
eventually Netscape is formed and creates a dramatically successful product that makes Microsoft jump.
Microsoft instinctively react to the creation of this new networked document viewer market by developing
a product to compete with it. They (inevitably) succeed, by the simple mechanism of creating
incrementally better products until one is "good enough", aided by the chronic mismanagement that
characterised Netscape during its last eight or so years. However, in the middle of this process, the
fight stops being over who can make the best document viewer, and slips into who can make the best
dynamic content viewer. And that slowly turns into an application platform. Oops. I'm no business expert
but I would hazard a guess that plunging billions of dollars into a loss-leader that competes with your
primary business model is not the best idea.
I've known all the bits of this story for years, but they never really clicked until Joel explained
it.
As Joel points out, though, Microsoft's moves after they realised their mistake with IE have been
harder to understand. I would have thought the solution most likely to succeed would have been to extend
IE in ways that made it into a better application deployment platform. Eventually, this could have
turned IE into the OS, either natively (making the next version of Windows basically be IE), or
by selling IE with versions for all operating systems. This would have had several advantages:
It would settle once and for all their claim that IE needs to be part of the OS.
It would solve the Linux threat: instead of competing with Linux, Linux would become just another
platform upon which IE can run.
It is what their customers wanted.
It could create lock-in just like Windows has.
They actually did start down that road. IE6 has support for a technology that Microsoft
stopped advertising at the same time as they stopped developing IE, namely HTAs, short for HTML
Applications. Similarly, even without really trying, Microsoft managed to lock large numbers of people
into the IE platform — it has taken years for Opera, Mozilla, et al to catch up to IE, and even
now, there are many sites that simply won't work in any other UA. The problem, I am told, is that the
visionaries at Microsoft want the lock-in platform to be an OS. That makes sense; I mean, that's what
they know.
And so they took all the things that they thought made HTML a good deployment platform, and all the
things that they thought made Win32 a good development platform, and all the ideas that Microsoft
Research said would be cool, and started a huge project: making a completely new OS. (It isn't clear to
me if this project spawned sub-projects like .NET, or if smaller projects like .NET became subsumed in
the larger OS project.)
There are several problems with this approach, as I see it. First, the market is no longer growing
that fast. In the past, when they released a new OS, Microsoft could grow its marketshare primarily by
growing the market, and then once the new market hit critical mass, people on older platforms that
couldn't run the newer software would be forced to upgrade to run the newer software. (They did the same
with Microsoft Office: by selling enough new copies to new users, eventually old users were forced to
upgrade simply to be able to read documents written by new users.)
But in the current market, Microsoft are having to depend mainly on upgrades.
Windows XP didn't do as well as previous releases, as far as market penetration goes. And many people
are questioning whether Longhorn has enough new features to warrant upgrading to it. So Microsoft will
either have to quite radically change their approach, or they will have to settle into a slower revenue
cycle.
But IE is only to play a supportive role in this big project.
Of course, Microsoft aren't alone in thinking that extending IE to be a new platform is a bad plan.
As I previously discussed,
the W3C held a conference on Web Applications just last month, and the majority of people there
disagreed with the concept of the browser being the platform as well.
Then again, I work for a browser vendor, and have been in the browser industry (both voluntarily and
as a job) for years now. So it's not surprise that I think the browser is important as an application
platform. (Obviously, though, as Robert Scoble is eager to tell us, Web apps aren't the answer to
everything. I wouldn't recommend to anyone that they try to write a graphics manipulation package in
HTML.)
The problem with the browser today is that applications based in the browser are constrained
to nightmarish UI idioms and a severe lack of polish stemming from the fact that the platform was not
really developed as a platform, and that no real progress has been made on this path for several
years.
John Gruber points out that users
don't really seem to care about the poor UI, though. The other advantages — especially the true
zero-install cost of Web-based applications — far outweigh the costs.
But that's why we started WHATWG: we want to make it easier to make nicer the kinds
of applications that it makes sense to deploy over the Web. Mail and
news clients. Cinema ticket sales. Book stores. Auction sites. Multiplayer stategy games.
In other news, apparently the Windows IE team is starting to wind down its work on the "let's make IE
secure" Windows XP service pack 2 release, and is starting to look at what people want in the IE that
will ship with Longhorn. They are
even looking for
feedback. Amusingly one of the most popular requests in the forums I have looked at (which is
probably a very skewed subset of the real feedback that Microsoft gets) is "better standards
compliance". And even more amusingly, one of the most often repeated messages from Microsoft people in
those same forums is "we're not going to be working on standards compliance" (although not usually
phrased that way).
I honestly do not expect to see any changes at all to the HTML, CSS, DOM, and JS
components in the Longhorn version of IE compared to Windows IE6. I've had Microsoft employees tell me
to my face that they will not have XHTML or SVG support in the next release. I've only seen excuses for
why features won't be added, never any Microsoft employees saying they are interested in supporting a
new spec. I have thousands of tests available on my site if
they want to find some bugs, but I doubt they will even look.
On the other hand, I can assure you that here at Opera we are implementing all kinds of things and
every release has more CSS/HTML/DOM/JS/XML/etc fixes. And over in Mozilla land Brendan has writtenseveral posts listing the kinds
of things Mozilla will be implementing over the next few years.