Re: distinguishing browser types

On Sat, 22 Apr 1995, Kee Hinckley wrote:
> As I understand (correct me if I'm wrong), that facility let's you
> negotiate on a broad scale - e.g. HTML2.0 vs. 3.0 or particular file
> formats. That however, is not really the major issue.  We just finished a
> site which has some pages which make heavy use of Tables and Forms
> (http://www.salemfive.com/salemfive/calcs.html).  We tested it with
> Netscape 1.1, Arena .96 and Mosaic 2.5b2. We ended up having conditionals
> based on whether the browser supports Tables, whether it supports Tables
> within Tables (that crashes/hangs the Cern and NCSA browsers), whether it
> supports Forms within Tables and whether it supports Images within Tables.
> 
> Content negotiation is certainly necessary, but it isn't sufficient.

I dunno - this is like NBC saying "well, there are some brands of TV's 
out there that can't do NTSC completely, so we're going to have to make 5 
different versions of the NBC Nightly News to compensate".  Broken 
browsers are broken browsers, whether they're in beta or not, and the 
only way to convince broken browser authors to fix them is to not cater 
to the bugs in their code.  Eventually we'll have a web where the most 
popular browsers are not the experimental ones.

Yes, content negotiation works in an environment where browsers don't lie 
about their capabilities, or if they do their users can live with the 
consequences.  Look at all the effort you spent in determining what 
browsers can do what - are you going to keep this list updated?  When you 
set a conditional that "All versions of NCSA Mosaic for Windows don't 
support tables in forms", how long does it take for your table can be 
updated when a new one does?  Believe me, I sympathise and admire the 
effort, we had to do it at HotWired, but eventually I just gave up (it 
was probably when I had trouble with HTML in the quoted value sections of 
hidden form fields with some browsers).

> Which leads me to another question. Are there any browsers out there that
> actually set the Accept fields based on the helper applications?  I know
> Netscape doesn't. It makes it rather difficult to determine what formats
> can be sent to a browser.

Actually, I think NetScape does it as close to correctly as any other 
browser - the HTTP spec says (at 
<URL:http://www.w3.org/hypertext/WWW/Protocols/HTTP1.0/HTTP1.0-ID_24.html#HEADING36>):

  5.4.1 Accept 

  The Accept header field can be used to indicate a list of media ranges
  which are acceptable as a response to the request. The asterisk "*"
  character is used to group media types into ranges, with "*/*" indicating
  all media types and "type/*" indicating all subtypes of that type. The set
  of ranges given by the client should represent what types are acceptable
  given the context of the request. The Accept field should only be used
  when the request is specifically limited to a set of desired types (as in
  the case of a request for an in-line image), to indicate qualitative
  preferences for specific media types, or to indicate acceptance of unusual
  media types. 

  (lots more interesting stuff)

It's not entirely clear whether Accept: should be used just for inline
objects or for all possible objects that can be sent to external
applications.  NetScape sends */*, image/gif, image/x-xbitmap, image/jpeg,
which besides */* is all it can inline (at least my X version - the windows 
version might send image/x-bmp or the mac image/pict or something).  When
NetScape's browser can handle inline PDF I hope they send application/pdf
- and now that they're doing tables we wish they'd send text/html;
version=3.0 (or at least 2.1, maybe, if that's what was decided in
Darmstadt :( ).  Other browsers are much worse with their Accept: headers,
yes, even Arena (c'mon, guys, why the application/x-island-paint,
application/x-island-draw, and application/x-island-write??).

A couple of recommendations for WWW browser authors:

1) First and foremost, set accept headers for all data types that your
browser can inline, with high q values if needed (default is 1).  And if
your implementation of experimental data types (HTML 2.1 or 3.0) is such
quality that you are billing it as a feature to your clients, specify that
in your headers with the appropriate q levels. 

2) On most platforms the number of data types that can be sent to 
external applications is much smaller than the default .mailcap files 
might suggest.  The browser should determine, based on a simple test for 
the existance of those applications listed in the default and user 
mailcaps, which mime types can really be passed off, and include those in 
the headers with small q values.

3) Allow the user to configure the q values and create new mailcap mapping
within the browser's preferences settings. 

4) Enable use of the "mxb" setting, so that people can determine the
maximum amount of information they're willing to accept for a given type 
of object, and the provider can scale what they provide accordingly.  No 
more "click here for a lower resolution version of the home page"!  The 
user can say "I really would prefer 50K or less for each HTML access", 
then the server can pump out a page with smaller inline images.  Apache 
doesn't support this yet, but just wait.... (or maybe it does?  Rob T.?)
Better yet, someone could say "I really only want MPEG movies below 2 
megs" and the server can scale the data accordingly.  

Guys, this is *all*in*the*current*specs*.  All these proposals are
designed to give the users more power in expressing their preferences and
abilities.  Content providers are dying to be able to meet their needs. 

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Received on Saturday, 22 April 1995 21:37:34 UTC