I think he is, convincing Sun and Netscape, which seem to love adding new
tags, will be harder.
> >>Wait a minute here. I'm not following, at all, why there's any need to
> >change HTML for applets. Even an unmodified HTML 2.0 can do them.
> >(It can, of course be done MUCH better with <FIG> in HTML 3.)
>
> The only outstanding question is how to pass parameters to the
This is a *very* serious question and probably the motivation for adding
the APPLET tag. Clear means of passing parameters are not optional in
function-invokation mechanisms.
> script. As somebody pointed out, the #fragment identifier, or client
> side specializer will work just fine. The syntax could get hairy, so
> some <param> extension to <fig> might be a more scalable solution, but
> it'll work.
I would like us to find a solution that is scalable across different tags,
so that other tags that may need to 'take arguments' and pass them to some
shared function. I made this argument earlier, asking that we treat REL/REV
values as arguments to an internal browser function that implements the
LINK's behavior when activated, and that we find a general way to map
attribute values into arguments for functions that are associated with
tags. If <param> is the general solution, great. I can see a few other
tags that might eventually call client-side functions, notably in forms
and security support. I'd rather not encounter these needs in a reactive
way. Also, hairy syntax is not likely to inspire confidence nor forestall
proprietary approaches. A general solution to 'tags that imply calls to
arbitrary client side functions' is needed. Now seems to be the time.
--
Craig Hubley Business that runs on knowledge
Craig Hubley & Associates needs software that runs on the net
mailto:craig@hubley.com 416-778-6136 416-778-1965 FAX
Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5