Re: Round 2: moving HTTP 1.0 to informational

On Jan 9,  8:11am, Benjamin Franz wrote:

> A thought occurs to me - the artificial distinction between
> 'A HREF' and 'FORM' is at the core of more than one problem with HTML
> (like URLs that choke SGML validators with imbedded '&' chars because
> the defined standard for passing parameters seperates them with '&'
> chars).

But the attribute 'HREF' of the anchor 'A' is declared as 'CDATA', as is
the attribute 'SRC' of 'FORM'.  Am I missing something in your explanation
that I don't this this should cause a validating parser to choke on an '&'
in the attribute.  I am aware that sgmls will attempt entity replacement
within 'CDATA', but like so many issues that come up on www-html this
seems like a situation where the DTD is blamed for problems with tools.

Perhaps I'm exhibiting a naive understanding of SMGL, as I have never had
the opportunity to consult the ISO standard document.  But I'm under the
impression from [1] and [2] that 'CDATA' allows markup characters including
'&' without any activity from the parser.  The explanation from [1] seems
to note this as the main distinction between 'CDATA' and 'RCDATA'.

The HTML 2.0 RFC [3] and the HTML 3.0 draft [4] both use 'CDATA' as the
content model of 'ACTION' and 'HREF'.  In [4], in fact, they use the same
entity to parameterize their content.  I'm perhaps a bit confused about
why this does not address the problem you call "the artificial distinction
between 'A HREF' and 'FORM'."

I'm interested in hearing an expansion of your ideas concerning this
distinction.  While I don't agree with the content model of 'CDATA' for
these attributes -- I'd like to use entities to refer to my links -- I
disagree with your suggestion that the distinction between an anchor
and a form is "artificial."

> Why not re-visit 'A' containers and relieve the URL overloading
> by adding 'INPUT' type elements as allowed content and adding the
> 'METHOD' attribute to 'A' (not to be confused with 'METHODS', although
> dangerously close in spelling)?

This confuses me as well, since 'A' is already a container.  I'm not
sure if what you're suggesting is making it a container or changing the
content model substantially.  While the 'A' content model does have
many failing from the perspective of hypertext development, I'm not
certain that the inability to use 'A' for user input is one of them.

I think it is important as the DTD for HTML evolves to keep merge like
concepts and keep/strengthen the distinctions between unlike concepts.
Both forms and anchors provide for user interaction, so perhaps they
could be combined.  But the chief distinction that I see between them
is that a form allows for user input that may or may not alter the
outcome of the transaction it facilitates, while an anchor does not.

> Or alternatively, define a new TYPE="INLINESUBMIT" attribute value for
> 'INPUT' in forms that is explicitly defined to display as 'inline
> text', (what a bizzare concept ;-) ) rather than the 'big buttons' pretty
> much every graphical browser now use. Thinking about it, this seems the
> superior approach. It takes fewer changes to the DTD and allows
> greater long term flexibility by leveraging off of forms.

I'm thinking of two distinct points that call this type of change into
question:

	1.  The use of "big buttons" should be controlled by a style
	sheet rather than a new value for the type attribute -- if a
	user chooses to see submissions as "inline text" rather than
	as a button, then this would be best, I think.  Consider the
	following:

		<form method=post action="http://host.domain/foo.cgi">
		<input type=hidden value="bar">
		<input type=submit value=gimme>
		</form>

	which captures a form that contains post information with a
	hidden field and lets you click a link.  This seems to fit
	with the direction the standard is heading.

	2.  A "big button" or other distinction between submitting a
	form and an anchor allows for constructions of the form (pardon
	the pun):

		<form method=post action="http://host.domain/foo.cgi">
		<input type=text size=50 value="bar">
		<p><a href="http://host.domain/foo-help.html">help
		me!</a></p>
		<input type=submit vale=gimme>
		</form>

	where clicking on "help me!" does not submit the form info.

	In this case, the distinction between a submit button and
	following a link could have important implications.  Suppose
	I key my Visa number into the field and then want to check in
	the help file to see how it is used or whether or not the
	transaction is secure -- I'd like to know for certain (w/o
	resorting to view source) that my card number is not going to
	go out just because I asked for help.

This second point underscores the semantic value of keeping 'A' and
'FORM' as distinct elements.  Given the current state of form usage,
there are reasons I may wish to know whether or not I am following a
link or submitting the form.  Another example would be filling out a
form to order a "blat" from a company and then deciding not to buy it.
I may still wish to follow a link on the page that contains the order
form, and the current method allows me to be certain that my input is
not transmitted.  Should I have to clear the form in order to follow
a link with complete confidence?  With "type=inlinesubmit" the answer
is yes.  Current practice says "no."  I rather like it that way.

Chuck


References
----------

[1] Practical SGML. Eric Van Herwijnen.  Kluwer Academic Publishers (Boston,
    1994), pp. 85-6.

[2] A Gentle Introduction to SGML.  Text Encoding Inititative.
        <URL:http://etext.virginia.edu/bin/tei-tocs?div=DIV1&id=SG>

[3] RFC 1866. Proposed Standard. "HyperText Markup Language
    Specification -- 2.0", T. Berners-Lee and D. Connolly, November 1995.
        <URL:http://www.ics.uci.edu/pub/ietf/html/rfc1866.txt>

[4] Internet Draft. "HyperText Markup Language Specification Version 3.0",
    D. Ragget, March 1995.
        <URL:http://www.w3.org/pub/WWW/MarkUp/html3/CoverPage.html>



-- 
Chuck D'Antonio
Assistant to the Director
Harvard Data Center
(617) 496-3847

Received on Wednesday, 10 January 1996 14:23:47 UTC