Well, I gather that html-mode.el is the most popular way to compose
HTML today. RTF2HTML, FM2HTML, LaTeX2HTML and that ilk are closing,
though.
My problem with all of these is that folks don't use an SGML parser to
validate their documents. Even the conversion tools generate invalid
stuff. To me, as long as the doc is valid, I don't care how you built
it.
I don't like the idea that HTML source goes right from somebody's
fingertips into a file, across the wire, and into a client browser
without ever being validated. This means client browsers have to deal
with a lot of noise. It means a lot of redundant processing. The
burden of generating valid HTML should be on the producer, not the
consumer.
> => If so, and if he's right, then this changes the language
>design.
I don't mean to change the language design. HTML has always been a
language for the _transmission_ of hypertext. That people use text
editors to generate it is an artifact.
> => How widely available *are* these tools? Are we talking Microsoft
>Word here, or the SGMLs tools?
I'm not sure what you're asking here, but: (1) I think MS Word is a
viable platform for HTML development. If it's not, it soon will be.
(2) I see the SGMLs tools as _very_ widely available. It's a high
quality source distribution requiring an ANSI C compiler and almost
nothing else.
>2) including explicit DOCTYPE is a good idea.
It was a really bad idea to leave it out in the first place.
>3) I can see no benefit whatsoever to making an incompatible change
>to the anchor syntax.
Point taken. To get closure any time soon, we're going to have to
stick to strictly status quo.
[Fine comments about link maintenance deleted... we'll stick all that
in a spec AFTER we've got good mechanisms in place]
>4) There is a large demand from the user community for inline tables
>and images. If HTML does not provide these, people will stop using HTML.
>(I do not know how much demand there is for inline math)
I really made a bad choice of words with "inline." The <IMG> element
is great. What I don't want to see, yet, is stuff like:
<image-gif notation="base64">232034o2ij2oi3j4o2i34j2o3i4</image-gif>
nor
<eq notation="tex">e=m*c^2</eq> <!-- apologies to TeXperts -->
nor table markup in HTML -- yet.
>5) as for the claim that forms should be a separate DTD - I don't see
>the benefit.
I'm wary of making HTML to big for simple applications. Right now, for
example, an HTTP client is required to handle text/plain and
text/html. If we make forms part of text/html, then any HTTP client
that doesn't do forms is "broken." I don't think that's the way it
should be. I think forms should be an optional feature, and a client
should advertise support ala:
Accept: image/gif
Accept: application/html-form
and documents that use forms should be labelled as such, ala:
<!DOCTYPE HTML-FORM PUBLIC "...">
<title>...</title>
<h1>My Form</h1>
<form> ... </form>
> HTML with forms is rapidly becoming a powerful way to
>implement application interfaces. there is a big demand for this feature.
>Indeed, I expect it to grow - The current forms behavior is a step
>towards fully programmable clients, and we may go that direction. When
>HTML is used in this way, it becomes something different from SGML +
>hyperlinks.
I see all this as an argument that HTML-FORMS should be a differnt
document type from HTML.
Forms are newer and more unstable (though I gather a certain set of
elements is pretty stable...). I don't get the impression that anybody
has a good handle on a kernel of elements that span the entire space
of applications.
I'm leaning towards making the HTML-FORM document type a superset of
HTML, and including it as a sort of appendix to the spec.
Dan