- From: Al Gilman <asgilman@iamdigex.net>
- Date: Fri, 04 Jun 1999 09:58:42 -0400
- To: WAI ER IG List <w3c-wai-er-ig@w3.org>
At 09:32 AM 6/4/99 +0200, Daniel Dardailler wrote: > >> In terms of client-side proxy filtering, I've been looking at the following >> five-piece plan: > >My experience (working with other W3C groups, like Ecommerce) is that >there isn't a portable solution for client-side proxy, and you have to >adapt your setting and filter to IE, to Netscape, to Lynx, etc. > >For Lynx, for instance, there's a way to compile it (so not supported >in every binaries) so that it recognizes some URI schema (say >xhttp://) as special and runs a filter thru them. See lynx documentation. > >For Emacs/W3, you need to write you own piece of elisp. > >For Netscape, there's a panel (Automatic Proxy Configuration) that >let's you play with client side script. (see >http://www14.netscape.com/navigator/admin/v3.0/proxy.html) > >etc. > >It's too bad that there isn't a simple client side CGI interface, >fired thru some .mailcap file, like for helpers, that would let anyone >install a filter on the client side. > Incidentally, this is the argument for relational programming or investing in the overhead of a Problem Solving Environment framework. In the abstract you define once the outcomes in terms of the relationship between UI behavior and the document content. Then the PSE generates for you a solution that delivers these outcomes built in the native resource vocabularies of the different execution environments. Al
Received on Friday, 4 June 1999 09:53:31 UTC