Hi, With minimal JavaScript code you could identify the browser's capabilities. Here is how you might approach the task.
If the browser is Lynx then send text only version otherwise send JavaScript browser "sniffer". The JavaScript sniffer can check for CSS, DHTML, DOM, plugins, etc... then redirect back to the server for the correct implementation. If you don't mind the redirection (in JavaScript of course) then you're all set. Redirection may not seem attractive but consider that JavaScript runs within the client (read: browser) right so you got to get the information back some how. Server side browser sniffing might be implemented through a database of browser supported features and user-agent strings. Just thought you might want to the idea. Good luck. : ) M ----- Original Message ----- From: "Per Einar Ellefsen" <[EMAIL PROTECTED]> To: "Joel Palmius" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, April 30, 2002 4:45 PM Subject: Re: Client capabilities > At 13:12 30.04.2002, Joel Palmius wrote: > >Is there a mod_perl API (or some other standard way) to determine what a > >client web browser is capable of displaying? (images, tables, plugins...) > > > >I am developing a web questionnaire system in mod_perl (1.26) and I'm > >thinking about maybe dividing the display code into different levels > >depending on what the client can handle (no graphics no css for lynx-like > >browsers, stylesheets and images for most browsers, and plugin extensions > >for more advanced browsers). > > The easiest is probably to ask the user. Tackling this in programming code > will probably fail as you have a too wide array of different user agents, > which each have their own options enabled/disabled. If the user won't > understand those questions (that might be normal), well, try to make > something that works for everyone. For example, you talk about CSS, but if > used correctly, text-based users will be able to use a page that has CSS > even if they don't have support for it. In the end, nobody really cares > about all the extra "stuff", and the way that works for everyone will > probably be the best (of course, don't be too conservative either; anyone > using lynx for example will know its limitations). > > > -- > Per Einar Ellefsen > [EMAIL PROTECTED] > > >
