Cougar: ideas for <A>,<INPUT>

A while back, there were murmurs of the following attribute extensions to <A>:

METHOD   - Method to use when dereferencing this anchor.

ENCTYPE  - Media type to use if dereferencing anchor transmits an
           request-entity-body.

SRC      - Source of request-entity-body for anchor.  Could be proposed data:
           URL or, with proper privacy protections, file://.

Additions to DTD:

<ATTLIST A
        ...
	method	(%HTTP-Method) GET
	enctype	 %Content-Type;
	src      %URL  #IMPLIED
        ...

Suggestions for <INPUT>:

FOR      - IDREF pointing to the form to which this <INPUT> belongs.  Allows
for
           placement of <INPUT> elements outside of <FORM>...</FORM> container.

InputType = ANCHOR
         - Behaves like InputType = SUBMIT or IMAGE.  Allows for a hot-link
type
           widget to submit a form.  TITLE attribute contains anchor text.

ACCEPT   - Specified in RFC 1867 (Form-based file upload) as a limitation to
           media types that a form-based-file upload file may have.  Was
RFC1867
           successful (or at least not a failure) enough that this should make
           it into Cougar?

Additions/changes to DTD:

<!ATTLIST INPUT
	...
	for	IDREF   #IMPLIED  -- matches form ID value --
	accept	CDATA #IMPLIED --list of content types
	...

<!ENTITY % InputType
        ...
	ANCHOR |
	...

Stuff I've been contemplating for the past year or so, but hadn't had time to
write up:

For completely new FORM functionality, it'd be nice to see numeric ranges of
both type slidebar and knob available as <INPUT> for <FORM>.  Min, Max and step
(step = 1, .1, .01 etc) would be attributes.

Also, in the case where one had a large set of <OPTION>s for a scrolling list
(say a multi-megabyte controlled vocabulary), the ability to specify an object
containing the <OPTIONS>, a starting-SELECT <OPTION> (perhaps expressed as a
query_string URL) and a range of options around the browse window that would be
dynamically downloaded and inserted as the user paged through the list.

Using the range facility of HTTP/1.1, this should be easier than it would have
been.

-marc

--

Received on Monday, 29 July 1996 15:51:56 UTC