Re: Standards, Work Groups, and Reality Checks: A Radical Proposal.

Glenn Adams (glenn@stonehand.com)
Sat, 23 Sep 95 21:06:39 EDT
Date: Sat, 23 Sep 95 14:50:36 EDT
From: amanda@intercon.com

> So all I have to do to *totally* derail the standards process is put a
> new tag (or change an old one) in a popular browser and fail to file a
> DTD on it?

Well, that's what the evidence so far seems to indicate, yes.

I would not agree with the previously quoted statement. The handling
of unknown tags is clearly specified by the current draft -- ignore them.
Of course, this is a bit easier said than done in the context of using
a real SGML parser -- it is possible though without any great difficulty.

On the other hand, the draft is weak on what to do with known tags that
appear in contexts other than where they are permitted. It is this latter
problem that is much more insidious. Take for instance the CENTER tag
employed by Netscape. They failed utterly to specify the content model
or the context where this element is to be used, and, consequently, many
documents use it willy-nilly and depend on the quirky parsing of Netscape
to essentially treat format related tags as a toggle on a global formatting
state. As far as I can tell, CENTER is currently being used as a %flow;,
as a %block;, and as %text;. I'm not sure how Netscape intended it to
be used -- I would think as either %flow; or %block;, but certainly not
as all of these or as %text; -- but the sad fact remains that people are
using it all over the place nowadays. For example, I've seen it inside
TABLE as a container of all or some of a table's TRs?! I've seen it inside
ADDRESS, and then outside of ADDRESS. I've seen it inside a P, etc...

What troubles me further, is the fact that Netscape glibly accepts things
like:

plain <B> bold <I> bold italic </B> bold?!? </I> plain

This is madness!

Personally, I don't think it is a matter of people not caring about the
integrity of their HTML. Rather, I suspect it is a consequence of there
being no easily usable tools to validate documents in way that provides
for current tag extensions. As long as people are editing HTML with vi
or emacs (or, for that matter, a number of so-called HTML authoring tools)
and using most existing browsers to view the result, we are going
to be stuck with lots of invalid documents. On the other hand, if browsers
would offer validation services for these authors, I suspect most authors
would take the time improve the integrity of their documents.

If people are so concerned over the randomness of netscape security key seeds,
then shouldn't they be concerned with the fact that the following document,
due to someone forgetting to type a single '>' character, may end up
killing someone!

<title>Instructions for Patient Jane Doe</title>
<p>
<i>Warnings</i>
<p>
<b Do not inject this patient with penicillin. She will die!</b>

The browser user will not only not get the message, but will not know
anything is wrong -- at least on the majority of browsers out there. I
know your average mom/pop grocery store home page isn't going to be too
upset if their page fails to show their sale on eggs; on the other hand,
there are a lot more potential web data providers and consumers out there
that do care or would care if they only knew what risks they were taking!

Regards,
Glenn Adams