Re: Forms support in clients

Dave Raggett (dsr@hplb.hpl.hp.com)
Wed, 28 Sep 94 15:11:01 BST


This issue of client-side scripting is something I tackled quite a while
back now. For HTML the approach is simple, you add a SCRIPT attribute to
the FORM element that specifies the URL of a script. The browser then
uses the Accept header to specify which scripting languages it supports.

What we should be spending air time on is the abstract API between
the browser and the script interpreter. Trusted scripts can be recognised
as such as they will carry a digital signature plus certificates in the
HTTP header. I will therefore concentrate on untrusted scripts:

o scripts can read a set of browser environment variables
e.g. the user's name, email address, time of day etc.

o scripts can read the contents of form fields and their
associated status flags (in-error, disabled).

o scripts can set the contents of form fields and their
associated status flags (in-error, disabled).

o scripts can get/set the current focus

o scripts are passed various classes of events, e.g.
get/release focus, mouse clicks, keyboard events

o scripts can set/clear a system error message

o scripts can access a few well chosen library routines

o scripts are limited in the amount of memory or screen
resources they can consume

o scripts interpreters are linked to the browser via
a (scripting) language independent API

o form fields belong to a well defined set of classes
but there is a way to define new classes that are
painted by the script

o scripts can't send messages

I don't have time to refine this, and would love to see other people
work together on refining this into a detailed proposal, rather than
arguing on which language to choose.

p.s. why not Visual Basic :)

--
Best wishes,

Dave Raggett

----------------------------------------------------------------------------- Hewlett Packard Laboratories email: dsr@hplb.hpl.hp.com Filton Road tel: +44 272 228046 Stoke Gifford fax: +44 272 228003 Bristol BS12 6QZ United Kingdom