2004-06-02 06:48 UTC
Spring 2004 Travelog: Part 8 (First Day of the Workshop)
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.
2004-06-04 22:20 UTC
Spring 2004 Travelog: Part 9 (Return to Europe)
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...
Pingbacks:
1
2
3
4
5