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.
I have always assumed that if a browser parses according to the rules,
a known tag in the wrong place is an error and parsing should halt
(interpretation and display can of course continue); if it is not
doing a formal parse then it just performs the action that it normally
associates with that tag, and continues regardless.
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;,
That is the problem...the evidence leads me to believe that many of
those engaged on browser design and authoring simply couldn't be
bothered with the rules about what goes where: so long as it looks
cute on-screen who cares about content models.
I'm sorry to labor the fact, but we do seriously need to let go of the
idea that we have some kind of duty to model or cater for all the
unparseable tags that people invent. I don't know where it came from
(was it imposed by the IETF or did we take it on voluntarily?) but it
is hamstringing the work of this group. We should make it quite clear
that some of the suggestions that have been made simply won't work (or
are irrelevant because they're already catered for), and that others
are good ideas which we are putting into the DTD. The whole business
of being forced to model every broken document on the net is a chimaera.
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...
Naturally. You may recall that when we started this group, I was
marked down on the list as a "HTML educator" because I'm neither
computer scientist nor programmer nor information architect nor flesh
nor fowl. And even now I think we're only beginning to realise the
scale of the task we face.
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!
Sic loquitur. "Who the hell cares so long as the suits from Marketing
think it looks cute and buy lots of product." This is a phase and will
pass (in several years). _I_ care, _you_ care, but let's be realistic,
there are many more things that are much more important to a company
in the browser/server business (like making money) than worrying about
whether the software obeys the spec.
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.
Maybe we should push psgml-mode harder.
///Peter