Image submit buttons and form data set

[John Dunlop]

(Note crosspost and follow-ups to ciwah.)

Nicolas Keller wrote in thread "Difference s in form handling btw
Mozilla and IE?":
[color=blue]
> The problem: I'm using a form that submit's (POST) its data via three
> different image buttons (depending on which button you click,
> something different should happen):
>
> <form action="id.php" method="post" name="form2">
> <input name="id1" type="image" id="id1" value="id1" src="id1.gif">
> <input name="id2" type="image" id="id2" value="id2" src="id2.gif">
> <input name="id3" type="image" id="id3" value="id3" src="id3.gif">
> </form>
>
> (This is kind of a summary of the code!)[/color]

Eh, since I've moved this discussion to ciwah, I'll question whether
that summary involved removing alt attributes. :-)
[color=blue]
> Now while with Mozilla everything works perfect, the Internet Explorer
> can't handle this: Not one of the variables id1, id2 or id3 is set in
> the target script - but it is in Mozilla.[/color]

My interpretation of the HTML4.01 specification leads me to believe
that Internet Explorer behaves incorrectly [1]. The INPUT that's
used to submit a form *is* a successful control, which, by HTML
rules, means its control-name/current-value pair is included as part
of the form data set: "Every successful control has its control name
paired with its current value as part of the submitted form data set"
(HTML4.01, sec. 17.13.2).

By searching for previous comments, I came across:

http://www.cs.tut.fi/~jkorpela/forms/imagebutton.html#submit

J. Korpela says "the value of the VALUE attribute is ignored, and the
coordinates of the clicked location are passed instead". I can't
find where this is written in the specification. Section 17.4.1
states:

| The submitted data includes name.x=x-value and name.y=y-value where
| "name" is the value of the name attribute, and x-value and y-value
| are the x and y coordinate values, respectively.

So, the submitted data *includes* the coordinates of where the
pointing device was when it was used to submit the form [2]; the
spec. does not say the control-name/current-value pair of the image
submit button is not also included as part of the form data set. J.
Korpela then goes on to say that whether this information should be
included "is somewhat debatable and depends on the interpretation of
wordings in the specification". I cannot see why this is the case.

In the thread <http://groups.google.c om/groups?th=e5f4d c91c1b1eda2>,
linked to by the above document, it's explained why an image submit
button's control-name/current-value pair should be submitted as part
of the form data set, and why browsers not doing so are in violation
of the specification. I agree with this conclusion.

On the other hand, A. Flavell's document:

http://ppewww.ph.gla.ac.uk/~flavell/www/trysub.html

says that "it would be unwise to try to rely on this behaviour, as
it's not in the specifications" .

I'm confused. Is my interpretation wrong?


[1] What makes me think twice are the browsers that don't behave in
accordance with my interpretation (among others, no doubt): Opera
7.10, Opera 6.0, Opera 5.12, IE 6.0, Netscape 4.74.

[2] The exact words of the specification are: "When a pointing device
is used to click on the image...". Is there any reason why a
pointing device *must* click to activate something?

--
Jock

[Alan J. Flavell]

Re: Image submit buttons and form data set

On Fri, 20 Feb 2004, John Dunlop wrote:
[color=blue]
> http://www.cs.tut.fi/~jkorpela/forms...on.html#submit[/color]

I'll get back to that in a moment...
[color=blue]
> J. Korpela says "the value of the VALUE attribute is ignored, and the
> coordinates of the clicked location are passed instead".[/color]

This was a statement of fact, at least, in relation to older browsers.
[color=blue]
> I can't find where this is written in the specification.[/color]

You're right: reviewing HTML/4.01 in the light of this argument, it
isn't clearly stated one way or the other.
[color=blue]
> On the other hand, A. Flavell's document:
> http://ppewww.ph.gla.ac.uk/~flavell/www/trysub.html
> says that "it would be unwise to try to rely on this behaviour, as
> it's not in the specifications" .[/color]

I have to confess that what you're reading there, and in its companion
page http://ppewww.ph.gla.ac.uk/%7Eflavel...ype-image.html , is
based on an original writeup that goes all the way back to
HTML2.0/RFC1866.

In RFC1866, section 8.1.2 says:

The <INPUT> element has a number of attributes. The set of applicable
attributes depends on the value of the TYPE attribute.

and section 8.1.2.5 for TYPE=IMAGE makes no mention of the VALUE
attribute, neither as a required nor as an optional attribute. That
not only codified what browsers were doing at the time, but also set
the signals for subsequent browser developers, it seems.

The Lynx developers tried for quite a while to establish the
convention that submission of name=value instead of name.x and name.y
co-ordinates was a signal that an INPUT TYPE=IMAGE was being submitted
from a text-mode browser. But their attempt was finally abandoned.
[color=blue]
> I'm confused. Is my interpretation wrong?[/color]

Not necessarily; but in practical terms it seems (on the basis of
present reports) that you're still not going to get reliable results
if you try it.

But it's clear that my page could do with a fresh coat of paint...

Meantime, Jukka's page (as they always do) provides some reliable
information and comment, and I have to admit that my reply on the
cited usenet thread was more forceful than, I now realise, the HTML4
specification really justified. I was misled by my earlier
familiarity with RFC1866, but on re-reading HTML4.01 in the light of
this discussion, it's certainly not conclusive, and those who argue
that name=value should _also_ appear do seem to have a sound argument.

But if browsers are in use which don't support it, then, by conceding
that, I really haven't offered very much practical help!

[...]
[color=blue]
> [2] The exact words of the specification are: "When a pointing device
> is used to click on the image...". Is there any reason why a
> pointing device *must* click to activate something?[/color]

No; presumably the term is being used in some kind of generalised way
to refer to any action, whatever it may be, which activates the "form
control" in question. They're trying to distinguish the *actioning*
of the form control, as opposed to merely putting the focus on it,
hovering over it, etc., and it's hard to choose a form of words that
doesn't imply some specific user interface - thus annoying the users
of some other interface. ("Kick here"?)

[Jukka K. Korpela]

Re: Image submit buttons and form data set

John Dunlop <john+usenet@jo hndunlop.info> wrote:
[color=blue]
> J. Korpela then goes on to say that whether this information should
> be included "is somewhat debatable and depends on the interpretation
> of wordings in the specification". I cannot see why this is the
> case.[/color]

I'm not sure of what exactly I meant then, but in general, the
definition of "successful controls" is rather vague.
"A _successful control_ is "valid" for submission. Every successful
control has its control name paired with its current value as part of
the submitted form data set. A successful control must be defined
within a FORM element and must have a control name."

http://www.w3.org/TR/html4/interact/forms.html#successful-controls

The markup is
"A <dfn>successf ul control</dfn> is "valid" for submission."
so it says that a definition of "successful control" is being given.
But is that a _definition_? It just says that a successful control is
"valid" for submission. Defining a term that way isn't very rigorous,
is it? And then the specification proceeds to telling what "controls"
are _not_ successful or not required to be processed as successful!

Does this mean that every "control" that has a name is successful,
unless some specific rule says that it is not? This seems to be the
conclusion if we note that every control has, somewhat surprisingly,
a value: "Each control has both an initial value and a current value,
both of which are character strings."

http://www.w3.org/TR/html4/interact/forms.html#h-17.2

It seems that this interpretation is what they actually mean, and it
would imply that for an image submit button, name=value should always
be sent (and apparently name= when the value is not specified, which
apparently needs to be seen as defaulting to an empty string).
I had always tried to read it "positively ", so that a "control" needs
something to become "successful ". But this seems to be the more
problematic approach.

But the other approach isn't crystal clear either. Consider checkboxes.
Any checkbox that has a name and isn't disabled is by default
"successful ", isn't it, under this approach? Then we see (at 17.13.2,
paradoxically under "However,") : "All "on" checkboxes may be
successful." Well, that doesn't change anything, does it? But we're
getting suspicious. And looking closely, in 17.2.1, far away from the
purported definition of "successful ", we find:
"When a form is submitted, only "on" checkbox controls can become
successful."
Well, they need not become successful, since they were born successful,
right? :-) But apparently there's quite a lot we need to read between
the lines, or at odd places, to see what should be, or might be,
"successful ". Hence, I don't think it's that far-fetched to conjecture
that image submit buttons were really meant to contribute only
name.x=... and name.y=... and not name=value.

The practical conclusion is that authors should not rely on name=value
being included _or_ on its not being included.

What browser vendors do is actually more or less irrelevant then.
I don't think there's much use in including name=value for image
buttons, since those buttons can always be distinguished by name alone.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Alan J. Flavell]

Re: Image submit buttons and form data set

On Fri, 20 Feb 2004, Jukka K. Korpela wrote:
[color=blue]
> I'm not sure of what exactly I meant then, but in general, the
> definition of "successful controls" is rather vague.[/color]

I've done a bit of a work-over of my page

http://ppewww.ph.gla.ac.uk/~flavell/www/trysub.html

although *not* yet done anything about the associated

http://ppewww.ph.gla.ac.uk/%7Eflavell/alt/type-image.html

Comments, of course, are welcome (but if folks want to criticise the
antiquated markup on these old pages, then they'd be expected to offer
a modern replacement, OK? I can't do everything in my "ample" free
time...)
[color=blue]
> "A _successful control_ is "valid" for submission. Every successful
> control has its control name paired with its current value as part of
> the submitted form data set. A successful control must be defined
> within a FORM element and must have a control name."[/color]

I think we'd have to rate an input type=image that has actually been
used to submit the form, as a "successful control" within the meaning
of that spec, as indeed it seems the Moz developers chose to do.

But other browser developers have acted differently, so I don't think
there's anything productive that web authors can do with this.
[color=blue]
> Does this mean that every "control" that has a name is successful,
> unless some specific rule says that it is not?[/color]

Well, MS's interpretation of <button> appears to make just that
assumption!!! But, seriously...
[color=blue]
> What browser vendors do is actually more or less irrelevant then.
> I don't think there's much use in including name=value for image
> buttons, since those buttons can always be distinguished by name alone.[/color]

Older browsers used to take the name or value texts and use them for
display as their "alternativ e" text when images were not shown, but
presumably we can forget that and just use ALT nowadays...?

However, one thing _did_ strike me about the spec for input
type=image:

When a pointing device is used to click on the image [...] the
submitted data includes name.x=x-value and name.y=y-value

One might interpret that to mean that if the image is actioned by any
means other than a pointing device, the name.x and name.y data has to
be omitted. Which is exactly the principle that Lynx was trying to
establish many years back, but finally gave up after version 2.6.

The Mozilla developers, however, seem not to have interpreted the
HTML4 spec in that way. If I use TAB and Enter to action my
type=image, I get name.x=0 and name.y=0 submitted, even though I did
not use a "pointing device". IE6 and Opera 7 (to take other examples)
did the same.

all the best