- From: Shel Kaphan <sjk@amazon.com>
- Date: Thu, 9 Nov 1995 09:03:45 -0800
- To: hedlund@best.com (M. Hedlund)
- Cc: www-talk@w3.org
M. Hedlund writes: > At 8:23 PM 11/8/95, Shel Kaphan wrote (quoting me): > > > Does "browser capabilities" == "HTML tags and attributes recognized"? > > > >It certainly *includes* that, but it also includes information > >that has to do with the way the browser chooses to render, and > >possibly other subtleties I can't think of at the moment. > > 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. > This further subdivides into two categories: (a) browser peculiarities that are constant properties of the browser (+ version + platform), and (b) more dynamic browser "choices" that can vary (due to user control or configuration) from one instance to another. I think that (a) needs to be encompassed to say we have a complete solution to this problem. As examples, does the browser always break the line on </form>? How does text flow around images? These properties are not going to be found in a formal description, but they can be relevant to the way a server wants to render pages. > > > 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. > I don't get this. Are you saying that there is a universal repository of DTD's out there somewhere? If you don't have the description, you have to get it *somewhere*, don't you? And no, I don't think any of this kind of information should be sent on every request. I already proposed one method, using the existing Redirect machinery, for servers to "request" this information from clients. > >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? > I think not, nor would the DTD + a style sheet containing, I presume, preferences and configuration options. An additional set of properties describing the hardwired rendering choices the browser makes is also needed. (If you want a complete solution, that is). > M. Hedlund <hedlund@best.com> > > --Shel Kaphan sjk@amazon.com
Received on Thursday, 9 November 1995 12:23:10 UTC