This is a good point. I was actually attempting to do this, since
TEXTSEARCH is a defined HTTP method (it is described as "...a GET
method with appended query information", at least in some version or other
of the HTTP specs...). But: the HTTP specs say nothing about how
the data should be encoded, which means that the browser needs more than
just the method -- it also needs an encoding type. This is something
that I missed in my posting, but clearly the ENCTYPE attribute
used by FORM elements is the correct quantity.
But as you point out below, HTML 2.0 sees METHOD, at least in the context
of A and LINK, somewhat differently:
Can someone explain why, in a FORM, the attribute ACTION is used instead
of HREF?
> A recent HTML 2.0 draft says:
>
> "The METHODS attributes of anchors and links provide information about the
> functions that the user may perform on an object. These are more accurately
> given by the HTTP protocol when it is used, but it may, for similar
> reasons as for the TITLE attribute, be useful to include the information
> in advance in the link. For example, the HTML interpreter may chose a
> different rendering as a function of the methods allowed; for example,
> something that is searchable may get a different icon.
>
> The value of the METHODS attribute is a whitespace-separated list of HTTP
> methods supported by the object for public use."
This implies that METHOD has two interpretations -- FORMs takes it as
face value as the HTTP method to be employed, while LINK or A take it as an
informational quantity, or as a list of possibly supported methods. In the
latter case, the specs don't say what the browser should actually do if
more than one method is supported.
To my knowledge, the METHOD attribute is not implemented for A or LINK
elements. Does anyone know otherwise?
> Stylesheets are a good place for information about presentation, and
> optional browser behavior.
>From what you've just said, I now think that the information contained
in METHOD attributes to an A or LINK element, and assumed to be simple
browser-behaviour/rendering information, should be best placed elsewhere,
so as not to conflict with the functional meaning assumed by FORM. I am
not sure that style sheets are the best place, but am willing to be
convinced. Personally, I'd rather have an HTML attribute that can imply
browser actions, which could then be overridden by stylesheets or browser
defaults. Perhaps this is only because I think this would be implemented
more quickly than stylesheets.......
> I would hope that their use would be totally optional: there would be
> nothing in a stylesheet, which ignored if, would totally break a document's
> structure.
>
> If we want to do something with proposals that will specify totally new
> browser behavior when clicking on a <A ...> link, I think we need to put
> new markup in some version of the DTD. (Not likely for HTML 2.0)
A good question. Some simple things could be done using METHOD and
ENCTYPE attributes to an A element, but that's about it -- there is
not obvious path to more sophisticated models. However, I don't
see that as a problem, as A is not (to my mind) intended to be the
optimal linking solution.
> ---
> Albert Lunde Albert-Lunde@nwu.edu
-
Ian
-- Ian Graham ................................. igraham@utirc.utoronto.ca