I'd like to see us move on with the HTML 2.* series and HTML 3.0.
I really think that that's what the market needs too.
Murray
>
> In message <ab0130080a0210041170@[192.246.238.160]>, Eric W. Sink writes:
>
> >I was under the impression
> >that what we sent as an Internet Draft was a "draft", and changes will be
> >made before we actually call it HTML 2.0. It is still not clear to me when
> >that time arrives, but I assumed it was tied to the time when this document
> >reaches RFC status.
> >
> >To put it another way: We want HTML 2.0 to be an RFC, whichever track it
> >ends up in. Surely there will be opportunity for a few more changes
> >between the Internet Draft and the RFC, right?
>
> The HTML 2.0 document has missed its marked window, in my
> opinion. When I started this effort, I had hoped that HTML 2.0 is what
> all the vendors would use in their marketing stuff and documentation.
> It would be the common feature set among the commercial
> implementations.
>
> But the first round of commercial browsers are already released.
>
>
> I see two options:
>
> 1. Continue to edit the 2.0 document until all the little nits are
> hammered out. Sort through the boat-load of documents resulting from
> the Internet Draft released in San Jose, looking for those few
> comments actually in the 2.0 scope among the zillions of enhancement
> requests.
>
> We end up with a nice, neat specification of a language that some
> browsers sort of supported about six months ago.
>
>
> 2. Let the 2.0 document go. Publish it as an informational RFC. Let it
> be known that we tried real hard, but we were after a moving target,
> and we never got all the editorial kinks out. But the DTD is
> available: you can validate your documents against the official,
> released, published, blessed, 2.0 DTD.
>
> Start fresh with 2.1 -- the spec that the _next_ release of commercial
> browsers will support. Add the ICADD stuff. Add and
> ­. Maybe add <super> and <sub>. Maybe even add tables.
>
> Maybe trim some of the fluff out of the document. Maybe split the HTTP
> interactions and such off into a "browser spec" ("WWW User Agent
> Spec," more precisely.)
>
>
> I'd like to go with option 2.
>
> But the critical thing about this document is endorsement of the major
> vendors. How do the folks from SoftQuad, NetScape, Spyglass, Spry,
> EIT, MCC (the consortium in Austin, not Mosaic Comm Corp) etc. feel
> about this? Which way should we go?
>
>
> Dan