These are style sheet[1] issues. If we tried to negotiate on every single
feature of a browser, that would be no better than User-Agent negotiation
(see my recent message in the "DTD's in RCS" thread).
>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?
I don't know of any such current repository, but one would certainly spring
up if we went forward with this. I am not proposing a way for a server to
automatically retrieve a browser's capability sheet.
If you send _one_ URL that describes browser PopuBrowser's capabilities,
and a new version of PopuBrowser comes out, that one URL gets flooded with
requests for the new capabilities sheet and is nearly unusable for weeks.
One the other hand, if you send a document identifier, then the PopuServer
people can maintain a DTD repository, as can the Browser Caps people, as
can W3C. Each server maintainer can find a DTD repository that is close
and available, and set their server to request new DTD's from there, by
identifier. The "Accept-URL" proposal is not a distributed solution.
>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?
> > 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.
Style sheets are meant to overcome "the hardwired rendering choices the
browser makes." Forgive me if I'm misinterpreting the above, but I'm
certainly not saying the server should get to see the user's style sheet
and make HTML decisions based on it! That completely defeats the purpose.
Here is the structure I am proposing:
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.
M. Hedlund <hedlund@best.com>
[1]<URL:http://www.w3.org/hypertext/WWW/Style/>.