- From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
- Date: Fri, 06 Sep 1996 13:33:49 -0400
- To: ianweb@smaug.java.utoronto.ca (Ian Graham), papresco@calum.csclub.uwaterloo.ca (Paul Prescod)
- Cc: www-html@w3.org
At 10:15 AM 9/6/96 -0400, Ian Graham wrote: >Instead, I believe it would be best to establish an easy-to-author form >interface description language (perhaps as part of HTML). There is then >no reason one browser could not render FORM element-like content using >an applet or a java-based plugin module, while another uses some other >mechanism to do so (e.g. another java plugin, designed for another interface, >or a coded-in interpreter, as is done now). This is an excellent idea (perhaps better than the original!), and I think it should be incorporated. Couldn't it be done through the standard "alternative text" mechanism for objects, the OBJECT's content? The UA would have to know that an INPUT in an OBJECT should be treated as an alternative and it should only query the OBJECT if the UA supports objects. But I also think that there is a place for Java form elements that CANNOT be represented as traditional form elements, just as there is a place for IMGs and OBJECTs that do not have a completely isomorphic text equivalent (i.e. here is a picture of my cat). I was going to suggest a NAME attribute on OBJECTs, but in looking at the spec, I realize that they already have one, and it is defined just as I would have defined it. Oops. The only thing missing is an explicit instruction that an OBJECT that participates in a FORM can have an alternate INPUT in its content and only one or the other should be submitted. Paul Prescod
Received on Friday, 6 September 1996 13:37:27 UTC