I agree. One of the reasons that the "bleeding edge" browsers are starting
to diverge is that there isn't much of a stake in the ground. I would prefer
to concentrate on HTML 3 over working on a 2.1, before people start clamoring
for standardization of tied-dyed or marble backgrounds and the like :).
Many people are pushing Netscape's extentions over the efforts of this
working group simply because they can use them today, for better or worse.
I think it would behoove us to move on to 3.0 without an intermediary stop
along the way.
> Tables - must have, work still to do
> Styles - no consensus yet
> Footnotes - OK
> HyTime links - no consensus reached
> Client-side scripting - no proposal yet
> Full SGML in the client - no proposal yet
> Unicode support - no consensus reached
> FIG extension - OK
> client side image map - no consensus reached
Looks like a good start to me. FIG definitely looks good, and is a reasonable
stopgap for client-side image maps for many purposes. I'm personally a Unicode
advocate (our client already has Unicode support designed and ready to
implement as soon as I see a consensus on how Unicode pages will be labelled
and encoded).
Full SGML in the client is something I oppose (in the sense of requiring the
client to interpret arbitrary chunks of SGML, not in the sense of requiring
HTML to be a conforming profile of SGML), mainly for pragmatic reasons.
Right now I can interpret HTML as fast as I can read it from disk or off
the network, because I know in advance what constraints apply to the input,
and can thus hard-wire my parser in those ways. Full SGML, because of its
generality, poses a much higher cost of implementation.
Amanda Walker
InterCon Systems Corporation