Oh, OK, sorry -- sounds great.
> I'm not quite sure what to do with forms. But what I'm suggesting
> is that normal text/html _not_ include forms -- we make a separate
> type application/html-form or some such and another DTD that includes
> the form elements (plus most of the normal HTML elements).
>
> Forms don't fit several requrements that I had in mind:
> * One should be able to write an HTML->RTF converter. What
> happens to forms there?
> * What happens when forms get printed?
>
> But I don't mean to be adamant about anything. If there's a clear
> consensus on how forms work, I'm all for it, I guess.
>
> I guess I just haven't worked with them enough to know _exactly_ how
> expressive they are.
The point I was making in my somewhat abrupt earlier messages is that
it has in fact turned out that people have found a multitude of uses
for forms inside ordinary documents, and being able to provide that
functionality was a big step forward. I can provide example URLs if
it would be helpful.
There are basically three languages we can define:
(a) HTML "pure"; no forms.
(b) HTML "pure" + forms; I call this "current practice", and this is
what I'm encouraging should be frozen long enough to be shipped
out as an informational RFC.
(c) HTML+.
I think (b) is the most important to lock down at this point in the
project, because it documents and semi-standardizes something that has
achieved widespread use (there are somewhere around 1,000,000 users of
browsers that support or almost support (b) at this point in time).
It is, I think, an important and logical plateau for us to establish
on our climb into the future, for that reason.
Cheers,
Marc