SitePoint Sponsor

User Tag List

Results 1 to 6 of 6
  1. #1
    SitePoint Member
    Join Date
    Aug 2006
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    <button> works differently in Firefox and IE

    I'm running into a problem with the different ways that IE and Firefox deal with button controls.

    I wrote my app using Firefox for testing and have now started checking to make sure it works with IE.

    Nope.

    The problem boils down to this bit of code:
    Code:
    <button name=disp type=submit value=yes><img src="disp.gif"></button>
    When the button is pressed in Firefox, $_POST['disp'] holds 'yes'

    When the button is pressed in IE, $_POST['disp'] holds '<img+src="disp.gif">'

    The w3c specs for the button control seem to point to Firefox doing this the right way, but because of the word "initial" in the spec, there might be some wiggle room for IE as well.

    Anyway, can anyone help me with this issue so that my button controls pass the same info to the app regardless whether the user has IE or Firefox?

    Of course my actual usage isn't quite this simple. I'm displaying a table with 1 record per row and using these buttons in a cell to let the user display, edit, or delete each record. The image for each type of button (display, edit, delete) is the same, but the "value=" contains the record ID, which is unique for each row.

    Something else odd about the way IE is passing the button info. It is passing every type=submit button on the page as if I had simultaneously clicked every one of them. With 30-some buttons named 'display', $_POST['display'] always gives the info from the last one on the page, regardless of which one I actually clicked. Completely useless behavior...

    Thanks,
    Gene
    Last edited by gleduc; Aug 29, 2006 at 13:44.

  2. #2
    Non-Member deathshadow's Avatar
    Join Date
    Jul 2006
    Location
    Dublin, NH
    Posts
    901
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    First off, I'm assuming you are trying to read the form from php - in which case I suggest you use $_REQUEST instead of $_POST. $_POST often returns the contents of the tag instead of the value - depending on the browser. I don't trust $_POST as far as I could throw Paul Wright (The Big Show)

    Quote Originally Posted by gleduc
    With 30-some buttons named 'display', $_POST['display'] always gives the info from the last one on the page, regardless of which one I actually clicked. Completely useless behavior...
    DUH - each item is supposed to have a UNIQUE name - naming a bunch of items the same thing doesn't WORK. It's like assigning multiple HTML tags the same ID. Generally this is why you see sites with radio buttons for selections and a separate submit button.

    ... and you should probably put all your values in VALID XHTML 'just to be sure' these days - in other words, start putting stuff in "double quotes"

  3. #3
    SitePoint Member
    Join Date
    Aug 2006
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for your response, deathshadow.

    First off, I'm assuming you are trying to read the form from php - in which case I suggest you use $_REQUEST instead of $_POST. $_POST often returns the contents of the tag instead of the value - depending on the browser.
    Yes, I am using PHP, but I've never heard that using $_POST is a Bad Thing. I'll look at using $_REQUEST instead. In my case, the problem is that IE doesn't even come close to handling <button> elements correctly. I found several posts on sites that pointed to this being a known IE problem.

    DUH - each item is supposed to have a UNIQUE name - naming a bunch of items the same thing doesn't WORK. It's like assigning multiple HTML tags the same ID. Generally this is why you see sites with radio buttons for selections and a separate submit button.
    This is nothing more than your opinion. It does, in fact, work. The reason it does work is that a browser may only return "successful" elements, and a submit button can only be "successful" if it is clicked (or has the focus when the user hits ENTER). Unless the browser completely ignores the rules and makes every control a successful one - like IE. When done in a sane manner, this can be used to pass unique values back via a known control name, like $_POST['display']. Just never try it using <button> elements.

    For instance.. My table has 200 rows. Each row includes 2 controls:
    Code:
    <input name=delete type=submit value=\"DELETE\" onclick=
      \"this.value=$rowNum; return true;\">
    <input name=display type=submit value=\"DISPLAY\" onclick=
      \"this.value=$rowNum; return true;\">
    So there will be 200 controls named 'delete' and 200 named 'display', but only 1 will ever be passed to the form handler - the one that is clicked. I just have to check to see which of the 2 "$_POST" values is set and the value will be the row number.
    Code:
      if ((isset($_POST['display'])) $action = "display:" . $_POST['display'];
        else $action = "delete:" . $_POST['delete'];
    If the DELETE button in row 3 is clicked, $action will be "delete:3" and if the DISPLAY button in row 17 is clicked, $action will be "display:17".

    The only workaround to my problem appears to be to change all of my <button> controls to <input type=submit> controls. It's a shame, too, because the <button> control makes it easy to use icons as buttons instead of klunky blocks with text in them. I also wouldn't have to mess with onclick methods because I could pass the row number in the "value=" field.

    Regards,
    Gene

  4. #4
    Non-Member deathshadow's Avatar
    Join Date
    Jul 2006
    Location
    Dublin, NH
    Posts
    901
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by gleduc
    Unless the browser completely ignores the rules and makes every control a successful one - like IE.
    which when that's 80-90% of the public, guess what?

    As it says in the WDG HTML 4.0 reference: "However, BUTTON is new in HTML 4.0 and poorly supported among current browsers, so INPUT is a more reliable choice at this time."

  5. #5
    SitePoint Wizard bronze trophy Immerse's Avatar
    Join Date
    Mar 2006
    Location
    Netherlands
    Posts
    1,661
    Mentioned
    7 Post(s)
    Tagged
    1 Thread(s)
    Off Topic:


    Isn't request just a combination of POST, GET and COOKIE?

  6. #6
    Non-Member deathshadow's Avatar
    Join Date
    Jul 2006
    Location
    Dublin, NH
    Posts
    901
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Immerse
    Isn't request just a combination of POST, GET and COOKIE?
    That's exactly what it is SUPPOSED to be, but I've found a good number of situations where $_REQUEST returns information being sent as postdata that $_POST doesn't seem to want to see.

    Which... is really screwy, but I don't argue with what works.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •