I see what you mean now. This is pretty close to what I suggested the
other day: there should be replicated databases, indexed by
HTTP_USER_AGENT string, that return *something* describing the
browser. I agree that the DTD could and probably should be among
those things, but see no reason why it must be limited to that.
Returning a text document that describes, in simple terms, something
like the contents of
<A HREF=http://objarts.com/cgi-bin/webmac.exe/browsercaps/index.html>
David Ornstein's Browser Caps database</A> for the browser in question
also seems potentially useful. Nobody is required to use it -- only
people who really want to. It's not pretty, it's not nice, it's just
something you need if you want to get this level of control.
It's a way to represent not just features, but bugs too. DTD's don't
do that. Whether you wish to exercise this level of control is
between you and your library functions.
I am not at all sure I believe style sheets have much of a part in
this right now. The reason is that the installed base of browsers
knows nothing about them. This is not to knock style sheets at all --
it is just my view that a solution to this problem has to help in the
present world, not just "the glorious future".
> >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.
>
> Yeah, that would be a good idea if the info is coming from the browser.
> But does it need to?
>
No -- it appears it shouldn't. I disavow any previous comments to the
contrary.
...
> 1. If you want to send _one_ page that just about anybody can read,
> send HTML/2.0. (This is no negotiation.)
> 2. If you want to take advantage of HTML/3.0, send it only to those
> browsers that include "text/html;version=3.0" in their Accept header.
> (This is Internet Media Type negotiation.)
> 3. If you want to take advantage of experimental tags and
> particular versions of draft standards, get the browser's DTD and see if it
> can render those tags. (This is DTD negotiation.)
> 4. If you want to influence the presentation of those tags, issue a
> site-wide style sheet. (This is one part of cascading style sheets (CSS);
> some other parts include the user's own preferences, which aren't for you
> to worry about.)
> 5. If you want still-finer negotiation, write a page for every
> browser about which you care. (This is user-agent negotiation.)
> 6. If you want absolute control, send PDF. (This is no negotiation.)
> Obviously, this structure is not in place today. #1, #5, & #6 are not
> protocol issues; nor are they desirable. The rest need to be implemented
> in order to work. If they are implemented, I think this structure would be
> a complete solution.
>
Seems entirely reasonable, except for what you said about 5.
A case in point is the handling of multiple submit buttons.
It is entirely conceivable for a DTD to specify that a name field
occurs in this element, however the browser may fail to send that name.
It's a bug, but it needs to be represented somewhere, hopefully not by
a case statement for that browser in my code.
> M. Hedlund <hedlund@best.com>
>
> [1]<URL:http://www.w3.org/hypertext/WWW/Style/>.
>
Shel Kaphan
sjk@amazon.com