Okay, I think this is an important point. I was saying before that "the
way the browser chooses to render" should be left out of this discussion
and reserved for style sheets. If there are other subtleties that are not
properly style-sheet problems, let's here about them.
> > If so, can't we just derive this information from DTD's[1]? DTD's already
> > exist for Mozilla and Hotjava -- see <URL:http://www.halsoft.com/html/>.
>
>That seems like a good idea, and as has been mentioned before, the
>URL of such documents could be made available to servers, though I
>kind of like not having to go find a document out there in hyperspace,
>where it might not be found reliably, etc.
I certainly agree, but URLs change. The URL of the DTD seems better
reserved for "Release Notes" or the like -- do we really need that URL in
every request from this browser? The idea of using the DTD identifier was
to provide a lasting reference, one that could be archived long after the
MyBrowser project is abandoned or whatever. Also, that identifier maps
directly to the DOCTYPE tag that should be at the top of each HTML
document, so everyone's using the same identifiers.
>It also seems like it
>might be simpler to have a summary available that is more relevant to
>the task at hand than to have to have a SGML parser the server
>software, which is, I presume, what it would take. A list of
>(attribute, value) pairs ought to do adequately, and would be really
>simple to parse.
Wouldn't the DTD itself contain more useful information (this contains
that, etc.)? In any case, who gets to parse the DTD is a detail -- I'm
trying to narrow the complaints about content negotiation to a workable
area. The question is:
Would a DTD describing experimental HTML tags provide
enough information for fine-grained content negotiation?
M. Hedlund <hedlund@best.com>