472,133 Members | 1,167 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,133 software developers and data experts.

<button> in IE

I'm having two troubles with the <button> tag in Internet Explorer on
Windows (I don't have access to a Mac to test it). It works as expected
in Mozilla both on Windows and Linux.

Here is the shortest example which exhibits the unexpected behavior:

<form action="index.php" method="GET">
<button type="submit" name="mode" value="criteria">Return to
Criteria</button>
<button type="submit" name="mode" value="page1">Go to Page 1</button>
<button type="submit" name="mode" value="page2">Go to Page 2</button>
</form>

Obviously there are other form elements which influence the behavior of
criteria, pages 1 and 2.

First problem is that IE sends in the HTML between the
<button> tags as the value instead of the attribute. Second problem is
that when _any_ <button> is clicked, IE passes in the values of _all_
<button>s in that form.

In other words, no matter what I click, my query string will always be:
?mode=Return+to+Criteria&mode=Go+to+Page+1&mode=Go +to+Page+2

Has anyone else come across either of these two bugs? How likely is
Microsoft to work on them if I report them (which brings up the question
of IE bugzilla's location)?

La'ie Techie
Jul 23 '05 #1
3 2643
=?UTF-8?b?TMSByrtpZSBUZWNoaWU=?=
<laie@win_remove_get_nospam_solutions.com> wrote:
I'm having two troubles with the <button> tag in Internet Explorer on
Windows
No wonder. It's fundamentally broken (though at times, it might work for
some users some of the time).
<button type="submit" name="mode" value="criteria">Return to
Criteria</button>
Use
<input type="submit" name="mode" value="Return to Criteria">
instead, and modify the form handler accordingly (to deal with the
name=value pair that will be generated).

If you wish to change the appearance of the submit button,
1) think twice - it is _good_ that submit buttons look boring, since
they look familiar and are recognized as submit buttons immediately
2) think again, if you still want to play with the appearance, and
3) if you really must, use CSS to style the appearance.
First problem is that IE sends in the HTML between the
<button> tags as the value instead of the attribute. Second problem
is that when _any_ <button> is clicked, IE passes in the values of
_all_ <button>s in that form.
Yes, those are two of the fundamental problems. Moreover, there are
probably _still_ some browsers that don't recognize <button> at all but
have no difficulties with <input>.
How likely is Microsoft to work on them if I report them


The probability might not be exactly zero, but hardly much bigger either,
and, moreover, the next version of IE will be available in not-so-near
future and only as embedded into a new OS-like product, which won't run
on your current computer, not to mention mine.

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

Jul 23 '05 #2
On Mon, 6 Sep 2004, [UTF-8] L??ie Techie wrote:
I'm having two troubles with the <button> tag in Internet Explorer on
Windows
No surprises there, I'm afraid...
Has anyone else come across either of these two bugs?
("Features", I suppose. Grumble.)
How likely is Microsoft to work on them if I report them


Negative, I would think. Take a look at
http://msdn.microsoft.com/workshop/a...cts/button.asp
and in particular the statement at the foot of the page:

| Standards Information
|
| This object is defined in HTML 4.0

A less suspicious person might suppose this to be a message from MS to
the reader, saying "we implemented the HTML 4.0 specification". But
no: the description of their implementation, just a few lines above
under "Remarks", describes an implementation that is in flagrant
contravention to the HTML/4.0 interworking requirements.

"Documented As Broken".

My serious advice to you would be not to use this in a WWW context.

(Although, some contributors have developed dual-pathed scripts to
cope with both WWW-compatible browsers /and/ that browser-like
operating system component... It's "do-able", but is it worth doing?)

As far as functionality is concerned, "input type=submit" is
universally supported wherever there is any support for forms.
There's a few hints and tips on its use (the most frequently asked are
those relating to "what happens when the user submits a form by
hitting Enter instead of using one of the submit buttons provided").

As far as cosmetics are concerned, well, submission of a form can be
quite a significant action in a WWW context: users get accustomed to
what a "submit button" (in the sense of "input type=submit") looks
like on their browser, and IMHO it's bad manners to interfere with
that for purely cosmetic reasons. Please don't get the idea that I
have any objection to good visual design - far from it (though I make
no claim to be any good at doing it myself); but in certain instances
it's better to go along with the regular design that this user is
accustomed to, and I'd suggest that this is just one of those "certain
instances".

Jukka has some good pages on HTML forms; I also cover some topics on
my pages, e.g start at
http://ppewww.ph.gla.ac.uk/~flavell/www/trysub.html (although they're
probably in need of a workover to take out detailed references to some
obsolete browser versions).
Jul 23 '05 #3
Thanks Alan and Jukka!

Before posting my original message, I did switch to <input type="submit">
tags with different names,as well as a <input type="hidden" name="mode">
to keep track of the current mode (not all "submit"s changed the mode).

I also tried to google for this bug, but with "button" being such a common
term I didn't find anything relevant and the first 5 pages (all links on
these pages were about buttons in the toolbar). I figured the regulars of
this NG would prove helpful, and indeed you have.

Mahalo nui loa,
La'ie Techie

Jul 23 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by not 2 swift | last post: by
3 posts views Thread by phil_gg04 | last post: by
2 posts views Thread by Christopher Benson-Manica | last post: by
1 post views Thread by CharlesA | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.