What you are creating is a client application that needs to be able to handle
displaying and navigating through an increasingly diverse network information
sea, and part of the functionality required is going to be local client
processing of interaction.
You should note that I didn't say "implement a fully scriptable viewer," nor
did I say that I even wanted such a beast. What I was attempting to discuss
was the potential to have bindings to the new functionality you're implementing
and doing that binding in such a way as to leverage the ability of the
document creator.
Anyway, keep up the good work.
dcm
--------
Marc Andreessen writes:
David C. Martin writes:
> Completely agree! But eventually I want to see local processing of
> actions from the user (e.g. indicating zipcode and getting state
> defaulted correctly :-) We need to start discussing the ability to
> download a script to accompany the document, e.g. in a stripped down
> TCL with TCL hooks into client (e.g. Mosaic) functionality for
> making the buttons, scrollbars, etc... *do* something interesting at
> the local machine.
Too much (and, in any case, too soon). I feel like reposting my
"kitchen sink" speech -- we are not creating an actual full-featured
user interface builder (or building environment) here. We are getting
close in *some* respects, but we aren't going to be able to offer the
range of functionality needed to deliver true GUI-building
capabilities, including flexibly and customizably reactive interfaces.
Therefore, I'd like to veto both the idea of arbitrarily tying
submission to any interface element (there are user interface problems
there, also -- it's not going to be clear to a user what's going on
and why) and the idea of forms behavior scripting.
Anticipating objections to my objection: During WWWWW this summer, I
was termed "closed minded" by at least one person for trying to draw
the line as to what we're willing to implement and support. It's not
closed-mindedness, it's triage -- we just can't do everything.
Cheers,
Marc
> dcm
> --------
> Dave_Raggett writes:
>
> Frans van Hoesel has pointed out the value in being able to
> use a checkbox or an icon or whatever to submit forms. In
> a tax return there might be a load of questions that become
> irrelevant when you click the checkbox to indicate that you
> are "single". In this case the form would be submitted and
> the server would then return it with the irrelevant questions
> greyed-out:
>
> Single? <INPUT NAME="single" TYPE=checkbox SUBMIT>
>
> The idea here is to make SUBMIT an independent attribute
> that can be used with arbitrary field types. You could
> have multiple "submit buttons" in the same form. This way
> authors can choose whether the form contents gets checked
> after each field on a per field basis.
>
> How about it?
>
> -- Dave