Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 31302 invoked from network); 15 Nov 2000 06:25:34 -0000 Received: from rdu26-36-096.nc.rr.com (HELO akira.webslingerZ.com) (66.26.36.96) by locus.apache.org with SMTP; 15 Nov 2000 06:25:34 -0000 Received: by akira.webslingerZ.com (Postfix, from userid 501) id DE3822866; Wed, 15 Nov 2000 01:27:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by akira.webslingerZ.com (Postfix) with ESMTP id DB8371B839 for ; Wed, 15 Nov 2000 01:27:18 -0500 (EST) Date: Wed, 15 Nov 2000 01:27:18 -0500 (EST) From: Donald Ball To: cocoon-dev@xml.apache.org Subject: Re: Better and Better and RT In-Reply-To: <004001c04a93$b20eb490$bd00a8c0@infoplanning.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On Thu, 9 Nov 2000, Berin Loritsch wrote: > > any luck searching for an open database of browsers and their > > capabilities, or do we still need to write our own? :) > > I believe that is the wrong approach. HTTP requests are > accompanied by certain parameters that web servers > automagically turn into CGI variables and such. I could > have Netscape 4.7x with the Adobe SVG plugin, and can > accept SVG files. However, the person in the next office > could have the same browser but no plugin. Beyond that, > Netscape 4.x on Unix can accept gzipped streams while > Netscape 4.x on Windows and MacIntosh can't. > > Use the variables that the web server gives us, and we > don't have to have a database of what browser does what. it's the wrong approach, but the the right approach doesn't work in the real world yet. not all of the information sent via the HTTP headers is knowledge without peeking into a browser capabilities database. there is information strongly implied by the format of the user-agent string (e.g. this browser supports DHTML) that's sometimes very useful to know, if only to guess at proper defaults. of course it's bad form to constrain a browser based on what you think it can do, you should always provide ways for the client to override you. and in the long term, the right approach, namely a richer client capabilities disclosure protocol, will supercede the hack of browser capabilities databases, but right now, a hack is better than nothing. i'd like for there to be an open one. everyone always says that they're sure there's one out there - but i haven't found one that's complete (say, contains netscape, explorer, arena, opera, konqueror, lynx, and w3m) and maintained. - donald