> Any good suggestions on what to do when the user opens a <HEAD> and forgets t
> close it? At what point should we assume the closure of the <HEAD>? We can'
> do it at the first thing that the browser thinks shouldn't be there, because
> in that case, a browser that didn't understand <STYLE>data</STYLE> would
> assume closure of the HEAD as soon as it saw "data". I suppose we can assume
> it at the <BODY>, but we still leave the opportunity for a doc with <HEAD>,
> not </HEAD> and no <BODY> which would just disappear into limbo inside the
> browser. It sure worries me.
I think the current heuristics -- ignore unrecognized tags
in the <BODY>, and ignore unrecognized tags and content in
the <HEAD> -- should still work, if you add another heuristic
that unrecognized elements do not cause the parser to imply a
</HEAD> end-tag or a <BODY> start-tag. In the scenario just
described -- missing </HEAD>, missing <BODY>, and the first body
element is unrecognized -- the first body element *would* get ignored,
but, since the undefined element is an "experimental feature" --
by definition, since it's not in the DTD -- the burden is on
the author to ensure interoperability with browsers that
don't understand it. That's a reasonable burden if all
that's required is </HEAD><BODY>.
This is the sort of thing that weblint can (and does) catch.
Sgmls/SP won't, since, strictly speaking, it's legal.
Maybe HTML 3 should make the <HEAD> and </HEAD> tags mandatory.
After all, they're only omissible now for compatibility with HTML 1!
--Joe English
joe@trystero.art.com