> joe@trystero.art.com (Joe English) wrote:
> [...]
> >The presence of this section in the specification
> >is widely interpreted by users as offering carte blanche
^^^^^
> >to invent whatever new tags and attributes they feel like.
(As an aside, I wasn't referring to the implementors
of Netscape, Mosaic, emacs-w3, or any other browser here.)
> >How about: "In the case of an unknown tag, the
> >results are undefined." That better reflects
> >the true situation -- some browsers are known to do
> >strange things with unknown tags, like making
> >the content blink or centering it.
> [...]
> Well, while many of you perceive that this section has been
> abused by Netscape additions, it also serves as a VERY valuable
> way for all browsers to phase in new tags that are added in
> later specs (such as HTML 3.0).
I didn't mean to imply that this section has
been abused by Netscape or other browsers.
(If anything, Netscape *violates* this section
by failing to ignore tags not in the spec. :-)
> If this section was change to just say the behavior was undefined,
> then I can easily see future browser developers programming to the
> spec, and then being completely messed up when some tags from the
> "next generation" spec come along.
I really don't think that will be a problem.
What *could* a browser do with unrecognized elements, other
than ignore them? Barf? That's not very robust. Flag
them as an error? That might even be useful. Invoke a new
experimental feature? That's been *demonstrated* to be
useful.
Ignoring unrecognized elements and attributes is clearly a
good implementation strategy, and it is appropriate to
assume that browsers are implemented this way when
designing HTML extensions. However, a specification
defining a *document format* has no business describing
what implementations should do with documents that *do not
conform* to that format.
--Joe English
jenglish@crl.com