It's that time of year again. The quarterly trip. This time I'm
going first to Boston for the May 2004 CSS working group face-to-face,
and then on to the bay area to eat Grandma's Especial and (probably
more to the point) to attend a workshop on Web Applications and
Compound Document.
A pretty standard trip: an SAS flight from Oslo to London Heathrow
on a 737-800 (with, as most of the SAS fleet, a small poem-like
writing at the entrance: On a round planet, / your destination /
will always / bring you home) followed by the normal paperwork at
Heathrow before boarding the 777 to take me to Boston.
Heathrow is such a mess. Seriously. Imagine one of those science
fiction movies where the city is dark and bustling with non-descript
industrial activity: things barely working due to a long slide into
disrepair, kept working by patching as little as possible, as cheaply
as possible. Corridors lead nowhere; derelict equipment lies unused in
passenger waiting lounges; "temporary" structures have become part of
some of the permanent structures; toilets are concealed behind load
bearing columns that look as if they were added as an afterthought
during construction (or even later) when the building threatened to
collapse (mind you, given recent events, I suppose that could be
worse); signs clarify other signs; the public announcement system
regularly informs passengers that everyone else in the terminal is
intent on stealing their baggage, or maybe giving some to them, and
that one must thus be vilgilant at all times... When we landed we had
to actually step onto the runway to get into the terminal because for
some reason our gate had no extending arm thingy.
It continuously amazes me how the British can have such an
obsession with doing things cheaply. "Maintenance", in the
UK, seems to mean "repair", not "preventing failure". Things that are
functional are good enough. There was a television screen at our gate,
showing BBC News 24's coverage of some royal wedding or other. It was
a pretty good quality large widescreen plasma display with a
pseudo-surround-sound system. But of course the picture was delivered
via analogue cable, in 4:3 ratio and stretched to fit the 16:9 frame,
an affront to the televison's abilities (and to BBC News 24's
producers, since they have been broadcasting in 16:9 for years).
Anywhere else, the technicians would have refused to even install such
a system; a plasma TV needs a digital feed, not coax. In Britain? Coax
is cheaper.
While I'm whining, I think I'll transition smoothly to a critique
of Along Came Poly, one of the films we were provided
with on the American Airlines entertainment system. A mediocre movie,
which could have been saved by featuring more of one of the
characters, a ferret, but which unfortunately utterly failed to use
even a fraction of its potential.
First of all, I must emphatically point out that ferrets do
not sound like squeaky toys. They are in fact largely silent.
It's one of the features that makes them look so innocent and
mischievous at the same time. They make a sound when you step on them
or drop them (a kind of indignant "epp epp epp!") and occasionally let
out muted cries while fighting, but that's it.
Secondly they never stand still (except when they're looking at you
waiting for you to either feed them or play with them). If you put a
ferret in a harness on a leash and attach the leash to the door
handle, one of three things will happen within about twenty seconds.
First, and most likely, the ferret will somehow manage to get the
leash off the door handle and start exploring the surroundings,
especially any dark and inaccessible places. Second, less likely but
still quite common, the ferret will magically get out of its harness
and again start exploring. Don't ask how they manage to get out of
their harness. It is a perennial mystery. I'm not a ferret expert but
my understanding is that the leading theory is that they possess short
range teleporting technology of some sort. The third possibility is
that the ferret will begin exploring with the leash still attached to
the door handle, and, through climbing atop nearby boxes or through
nearby pipes, will manage to either entangle itself in a knot that
will take significant effort to undo, or will slip and end up dangling
in mid air. (I'm sure more ferrets get killed by curiosity than
cats.)
What will never happen is them just standing there
patiently waiting for whatever humans have in mind for them. So you
would never find a ferret sitting in the middle of a hallway.
Thirdly, ferrets don't run into walls. They run along walls. If
they find a wall, they run towards it then follow it to find out where
it leads. They follow walls almost as religiously as they explore
holes.
And finally, ferrets sleep. As far as I can tell most
ferrets spend no more than thirty minutes awake per day. No movie that
purports to show someone, whose first guess when he sees a ferret is
to think it is a rat, dating a ferret feeder (you don't own ferrets
anymore than you would own a cat), could possibly omit the line "do
these things do anything but sleep?". Well, I mean, obviously it
could, since this one did, but such an omission would always be a
major error.
I arrived in Boston having read about half of Peter F. Hamilton's
latest book, Pandora's Star. This is a nearly 900 page
book, part one of the Commonwealth Saga. I absolutely
loved his first saga, the Night's Dawn Trilogy. So far
this book is promising to be just as good.
Getting to Boston itself from the airport was quite easy, due to
convenient public transport. Unfortunately, Boston reminds me
of Heathrow. It's American, of course, so it's on a bigger
scale. But it has all the same features of looking temporary. A few
months ago I heard that The Big
Dig was complete, but it seems that they forgot to let the crew
know.
I went for a long two and a half hour walk around the city to see
what it was like. One of the most confusing things I came across was a
couple of big old iron pipes coming out of the ground and spewing
dirty steam. Why would there be steam underground? And why would you
want to release it all over the place?
For dinner, I had a burrito. Europeans don't know how to make
burritos. They try to serve them on a plate with garnishes, or with
the rice on the outside, or with sauce poured over the burrito. That
would be like serving a ploughman's lunch as individual parts around a
plate (mind you, I've had that done too). Burritos should be
self-contained. Just one big lump of goodness filling a
leak-proof yet edible wrapper.
It was a good burrito.
The next day, today, I woke up refreshed, watched Finding
Nemo on TV (Pixar rocks), then walked around Boston some more.
Some of us working group type people are planning to meet for dinner
tonight. In the meantime I think I'll sit down at Boston Common and
read my book.
The CSS working group meeting is now over, and so I've now flown
over to the bay area for the workshop. I'm
staying at dbaron's, who
kindly offered to let me use his couch. We have both been asked to
give short presentations at the workshop next week, so I've been
thinking about some things to help underscore our point about how
backwards compatibility is a requirement, at least for solutions that
are to come in the near future.
I think the best way to explain it is to use examples.
CSS2
Look around the Web. What parts of CSS2 are used? (Not counting
those that were already in CSS1.)
The answer is "absolute positioning". Pretty much none of the
other new features from CSS2 are used. Why? Because of those new
features, pretty much only absolute positioning is supported by
Windows IE6.
Many sites still use HTML table elements for layout. Why? Because
the CSS2 table model isn't supported by Windows IE6. Authors often
ask how to do things like fixed positioning, but lose interest when
they are told Windows IE6 does not support them.
XHTML
Many pages on the Web claim to be XHTML (according to their
DOCTYPE) but they are almost all sent as text/html
instead of the more correct application/xhtml+xml,
despite all browsers except Windows IE6 supporting the latter.
PNG
Authors use PNG. Authors don't often use PNGs with eight bit
alpha channels. Windows IE6 only supports PNG that don't have eight
bit alpha channels. Authors frequently ask how to use semi-transparent bitmaps with their site designs, but again lose interest when told that Windows IE6 won't render them correctly.
Flash is frequently used on the Web
Windows IE6 ships with a binary plugin for rendering Macromedia
Flash files. Flash is very widely used on the Web, especially for
application-like content, in particular games and interactive
multimedia.
SVG is rarely used on the Web
Windows IE6 does not ship with a binary plugin for rendering SVG
files, although one is available at no cost. SVG is rarely used on
the Web, at least compared to Flash.
Non-standard features
Many pages depend on features that aren't in the
specs, but are implemented in IE, despite the features being
available in the specs using other methods, and despite those other methods being implemented in
IE. For example,
document.all is used all over the place despite its
standards-compliant equivalent getElementById being
implemented in Windows IE6.
Similarly many pages use offsetTop,
innerHTML, and the like, which has forced other browser
vendors to implement support for those features.
I think these examples demonstrate quite strongly the need for any
successful solution to be one that can be deployed in Windows IE6.
Adding new functionality to Windows IE6 without using binary plugins
is quite possible, as demonstrated by the quite impressive IE7 project.
The long term solution would be to move users from the dead IE
platform and the proprietary Windows platform to the actively
developed, open, and standards-based alternatives. Once users are
using products with (relatively) rapid update cycles, it will be
possible to introduce more radical new technologies, and expect to see
them adopted by authors.
However, moving users to a different platform is an entirely
different problem than providing authors with new technologies. Users
use Windows because vendors use Windows as their default operating
system. Users use Windows IE6 because Windows uses IE6 as its default
Web browser. Very few users ever change either of these, much like
very few users ever change their preferences, mostly because they
simply are not aware that the alternatives exist.
Therefore before we can create a long term solution for authors
developing Web applications we need operating system manufacturers and
Web browser manufacturers to significantly step up their marketing
campaigns and significantly increase the effectiveness of their
lobbying of vendors. Until that happens, there is not much point
inventing new languages, since they won't be used in the near future,
and will probably no longer be adequate when they can be.
However, in the meantime, authors still want to write Web
applications, and the currently deployed standards are inadequate.
Since completely new standards won't cut it (as discussed above); this
leaves us with the solution we (Opera and Mozilla) have been
advocating: updating HTML and the DOM.
Yesterday I was dealt my first hand of poker. An interesting game.
Should be easy to write a decent Web-based version. I wonder how easy
it would be to write an artificial player.
Today, we are going to be playing Monopoly, with our
all-deals-allowed rules. Loans. Insurance. Shared rent agreements. I
can't wait. (I always lose, but that's not the point.) I've already
written an Internet-based version of Monopoly.
Yesterday I saw Miracle,
today I'm probably going to see Soul
Plane.
Earlier today I also went to Fry's Electronics in Palo Alto to see
if they had a Linux-based PDA. They didn't, unfortunately.
Now I'm off to La Fiesta for lunch. Grandma's Especial
Enchiladas.
I managed to convince Pavlov to see The Day After
Tomorrow instead of Soul Plane. It was pretty
good. I was quite impressed with the CG — nearly every shot had
them. (After listening to lots of SG-1 audio commentaries, I
appreciate effects a lot more.)
I had a Grandma's Especial with flour tortillas for lunch, and we
just got back from another run to Burrito Real for dinner. I'm getting
my year's fill of Mexican food all at once in this trip, I think.
We spent the evening playing Monopoly. The first proper game for 3
years! You can see the results on our results page
(it's the 2004-05-28 game).
I have no idea what we're going to be doing this weekend, but I
think it'll involve some sleeping, given the length of this game.
The weekend. David had bought himself a Linksys wireless router
when we went to Fry's on Friday, and on Saturday he installed it. It
was disappointingly easy. Where's the fun if things Just Work?
(Actually it turns out it didn't Just Work; the ethernet ports were
broken.)
In the afternoon Ben, Kerz, David and I went up to the Lick Observatory
on Mount Hamilton. It was a really nice ride with some great views of
the valley. I hadn't realised quite how much smog there was here. It's
rather scary. I don't remember seeing smog back in Norway.
We were given a nice talk by one of the amateur astronomers lucky
enough to get himself a job at the observatory, and then drove back
home. On the way, Ben was annoyed by a Toyota driver who was weaving
all over his lane.
Yesterday evening David and I went to Andale Taqueria in Palo Alto.
I had a small chicken taco. It was good. Today I'm planning to go to
San Francisco to meet Bloo and
see Shrek 2. Ought to be fun.
The agenda for the
workshop is now available. Looks like David and I are
going to give a joint presentation tuesday afternoon. We're right
before Microsoft, which could be interesting.
I'm very much at a loss as to what to expect from this workshop. On
the one hand I really can't see us convincing everyone else that the
solution is to continue down the HTML path. After all, it's not in the
interests of most of the other attendees. Many of them are wanting to
sell SVG, XForms, or XHTML products, and most of those who aren't are
probably more concerned with developing a good theoretical solution
than addressing the unfortunate pragmatic needs of today's
authors.
After ditching bloo we then went back to Nadia's and Kevin's (who appears
to not have a URI) to play DDR. I sucked. Pav
and dbaron were a bit better. Nadia and Kevin have quite clearly
practiced this a lot and were quite impressively coordinated, which
was scary.
Tomorrow afternoon we're probably going to go see Soul
Plane since Pavlov is really set on seeing it.
In between all these good times I've also been doing some work on
the CSS2.1 test suite, converting the CSS1 tests to the new format
(more on that later when I've finished doing it). I'm getting there
— only 28 more tests to convert!
I've been reading through some of the position papers putting
together some notes for the workshop
tomorrow.
Applications and documents are distinct
Why are they distinct? Microsoft Word documents can be used as
applications. Interactive encyclopedia multimedia applications can
be viewed as documents. Spreadsheets have long been both
simultaneously. Help systems now are able to interact with the user
and control other applications to help them along, but are clearly
still documentation.
In fact I would posit that users do not really understand the
difference between "applications" and "documents" at this stage, and
I would argue that they need not.
We
need a virtual machine that is defined using declarative mark-up,
rather than any particular language
How much is in the meta-language? Would you describe SVG in this
language? Would you describe CSS in this language? XPath? XML
Schema? XML itself? DOM?
Would this be able to describe XHTML2? XForms? What about XForms'
custom XPath functions?
How is this better than XBL?
It also seems that this would encourage a much wider range of
languages to be delivered over the Web, breaking the principle that
the number of Web
formats should be limited, which is important for
accessibility.
Presently,
three incompatible forms specs (Adobe eForms, Microsoft's Infopath,
W3C's XForms) are out in public view, yet none are supported by
assistive technology
It is not scripting that is inherently bad for accessibility, it
is device-specific APIs that are bad for accessibility. Any
technology that makes device-specific solutions easier than
device-independent ones will result in poor accessibility, as
authors use the simplest solutions.
With this in mind, the best solution might just be to redefine
parts of the existing scripting APIs to be device independent. For
example, redefine onclick to trigger whenever an
element is activated, not just when it is clicked.
We need profiles for mobile devices
If desktop and mobile units have different profiles, then mobile
units will not be able to view all the content aimed at desktops (as
most content is). It seems that in fact device independence would be
far better for mobile users than device-specific profiles.
SVG is the answer
SVG (or rather a drastically simplified version) is a possible
solution for the vector graphics requirements of an overall Web
Applications technology.
However, it would in my opinion be a bad solution for the core
technology. SVG is poor in terms of accessibility and semantics. For
example, how do you mark a part of an SVG application as an ordered
list? As a paragraph or header? As a dialog box or tabbing
control?
SVG is also much less suited for styling. For example, it is not
possible, with SVG, to do the radical changes in appearance as seen
in the CSS Zen Garden.
The ability to do this (without changing the markup) is an important
part of the Web.
Today I listened to a good dozen
presentations from various groups on the subject of Web
Applications and Compound Documents.
Some interesting things came out. First, the only sustained
spontaneous clapping of the entire day came as someone suggested, in
response to my brief statement of how backwards
compatibility is critical, that it was about time to drop HTML and
Windows IE6 from the roadmap.
So I can assume from that that most people don't agree with the
whole backwards-compatibility thing!
Second: I was quite amused to see that, of all companies,
Microsoft, Red Hat, and Sun Microsystems actually agreed on
something. Namely that trying to standardise an API for sophisticated
applications is simply a non-starter. The argument, which I agree
with, is that such APIs are simply insanely complicated, and that making
interoperable implementations is nigh on impossible. Just look at the
trouble WINE has had trying to implement Win32 again — now
imagine if you had to write a spec to actually describe the entire
Win32 API in terms that could actually be implemented interoperably
without reverse engineering the first implementation as the WINE
people do.
What was funny was watching the other people then disagree with
them. Hint: If three of the most bitter rivals in the marketplace
— all of whom have extensive experience in the subject in
question — agree on something, then it is probably
true.
What we (Opera and Mozilla) want to do is simply extend HTML, DOM,
and CSS a bit so that the most common things are easier to do. Things
like my Web
Forms 2 proposal or my
server sent events proposal. These are simple extensions, not an
attempt to provide comprehensive platform APIs.
Another point that came out of the discussions is that, in case
there was any doubt, Internet Explorer in Longhorn will not support
XHTML or SVG. (Microsoft suggested they would need some significantly
more comprehensive test suites before they started working on
standards compliance again.)
After the meeting, a bunch of us had dinner at La Fiesta. Our table had three
Microsoft employees, two Red Hat employees, two Mozilla Foundation
employees, and an Opera Software employee. I bet you won't see
that very often.
Tomorrow we have another dozen presentations. I expect to see more
of the same; mostly people expounding on the virtues of XForms, SVG,
XHTML2, or their own radically new proprietary technologies, and explaining how Web
Applications would all be much better off if the W3C would go down
their chosen route.
We, of course, want the W3C to go down our chosen route.
Since there doesn't seem to be much consensus on doing that, though,
the question is what should we do now? Should we do our own
thing (in public of course) and then submit it to the W3C (or IETF or
ECMA) at some future point once we have initial implementations?
Should we simply do our own thing (Opera, Mozilla, and a few
interested parties) and forget standardisation altogether? Should we
just take part in whatever Web Applications working group the W3C sets
up and implement whatever comes out of that in several years' time,
despite being fully aware that few people will ever use it? (Which is a
foregone conclusion since it wouldn't work in Windows IE6.)
I'm learning towards the first of the three at the moment. I guess
the Opera and Mozilla people will have to discuss this in more detail
before we decide anything though.
Travelling east is painful. I woke up around 05:40 on Thursday, and
went to bed around 15:00 on Friday, nine time zones away. My brain now
thinks that 23:00 is a good waking time. Also, it meant I had three
breakfasts yesterday, which successfully smashed my fast so that I
wasn't hungry even though I should have been. Quite the biological
clock confusion.
The second day of the workshop had more
discussion. We had some straw polls; of the 40 or so people there,
around 8 said they wanted to work on the work Opera and Mozilla have
been proposing recently, and about 11 said that not only did they not
think it would be worth working on this, but they actively thought
that the W3C should not work on it.
In my opinion that's pretty short-sighted, but as Steven Pemberton
pointed out, six year ago, the W3C decided that HTML was dead, and the
way forward was a host of new languages (what is now XHTML2, XForms,
MathML, SVG) that would lead the world's population to a clean new
world. So at least they are consistent.
Of course I had to point out that six years ago, I was in school,
which got a good laugh. My point, though, was that times change. In
the last six years we have seen that authors simply didn't agree:
Mozilla has supported MathML for years, but it is still very rare to
see any MathML content on the Web. Mozilla, Opera and Safari all
support XHTML1, in fact Mozilla has supported XHTML1 since before it
had an assigned namespace and MIME type, but again the amount of
application/xhtml+xml content on the Web is trivial.
The truth is that the real Web, the Web that authors write for, is
the Windows IE6 Web. The only way to change that is to reduce the IE6
market share, and new technologies don't do this. Marketing does. Once
users are primarily using a browser that is being regularly updated,
then we can start introducing radically new technologies. Until then,
such technologies simply aren't going to become popular.
There were a lot of rather confused statements during the meeting.
For example, it is clear that a lot of people think that the
browser is dead and that the way forward is transparent "runtimes"
that execute remote applications securely. But then these same people
demand to know why Mozilla, Opera and Safari don't support XForms and
SVG, saying that their lack of support is crippling their standards'
adoption.
Surely if the browser paradigm is dead, it doesn't matter what we
implement?
What I think most of the people at the meeting actually want is a
standard that combines XHTML, XForms, SVG, and SMIL (and CSS, DOM, and
ECMAScript, although they rarely if ever actually mention those by
name), and then adds enough APIs to make the host into a platform in
its own right.
Java tried the "provide lots of APIs that are interoperable across
lots of platforms" and failed. Some people thought this was because
Java, as a language, is too complex for most applications. And Java
doesn't have a detailed spec (not detailed enough to write an
interoperable implementation accurate to the level that is needed for
applications).
The detailed spec problem is the big issue. There has simply never
been a Web specification written in enough detail for this kind of
work. Even "DHTML", which does just a fraction of the number of APIs
needed for the kinds of applications these people are imagining, is
completely inadequately specified. For example, if you have an
object element followed by a script block,
will the script execute before or after the object has loaded? This is
the kind of behaviour that scripts depend on. (Answer: In IE, the
script will block waiting for the object, and if the object doesn't
load, it will be removed from the DOM. The exact behaviour
depends on the extension of the filename in the data
attribute and the local computer's registry. Feel free to explore this
yourself using
these testcases...)
Making these specs more detailed is the work that Opera and Mozilla
want to do. But to do this for a sophisticated application platform on
par with, say, Longhorn, is simply unfeasible. Notice how WINE has to
reverse engineer Windows to determine how it should work. Or how the
various Java clones have to reverse engineer Sun's Java to get
interoperability.
Of course, if they want to do this, I wish them the best of luck. I
might even want to participate in the working group, since
someone will have to look out for the Opera and Mozilla
interests!
Sadly there does seem to be a growing opinion in certain circles
that the W3C is becoming more and more out of touch with the Web. In
many ways, this makes sense: the membership has many more server-side
people than client-side people, and most of the client-side people are
plug-in vendors, not browser vendors. (All the browser vendors present
at the meeting were in favour of variants on the Opera/Mozilla ideas,
but they were easily out-numbered by the non-browser members.) Since
most people consider "the Web" to be what browsers show, it's only
natural for an organisation of people who are largely not doing Web
browser work to appear to be "out of touch".
Really it's not that the W3C is out of touch with the Web, but that
the W3C membership is solving problems that every day Web users don't
see. For example things like CC/PP and SOAP are very much back-end
technologies.
I've also heard a lot of comments recently from people asking if
the SVG working group realises that SVG 1.2 is becoming a dumping
ground for anything and everything, instead of remaining just a
graphics language. For example, SVG 1.2 drafts feature raw
socket APIs and a
Window interface. So I asked people at the conference whether the
SVG working group shouldn't, instead of adding every feature under the
sun to SVG, simply define how SVG should interact with other languages
like XHTML. The answer I got was highly dismissive. Basically: "Well
we want it in SVG".
You'll note that Robert O'Callahan (one of the core layout
developers for Mozilla) sent
an e-mail last month pointing out the many areas of overlap
between SVG and CSS. He never got a reply to his last message. (Hmm...
this is reminiscent of the way the SVG working group effectively
ignored a
message I sent back in 1999 pointing out a problem in SVG 1.0 that
is still present in SVG 1.2 drafts — reply once, ignore further
e-mails on the thread, and don't actually address any of the
problems...)
Since many of SVG's features (like Window, or like the
way CSS properties are allowed to have lengths with no units) directly
conflict with existing standards (both ad hoc and de
jure), it's quite clear that browsers that implement SVG will only
ever be able to implement a subset of SVG.
Another point that was mentioned at the workshop was that DOM3 core
was a long specification, checking in at some 216 pages. The SVG 1.0
spec is 719 pages long. (More than twice the length of CSS2.1, which I
thought was already a ridiculously long specification.)
Still, it's a nice language if all you want to do is draw vector
graphics.
Anyway. The issues have been discussed, the positions have been
given, everyone knows where everyone else stands, now it's time to get
down and actually start doing work.
What working group is going to work on extending HTML...