EDIT 9 Janvier
Le comportement de MSIE 6 et 7 est beaucoup catastrophique que prévu. Je révise ma conclusion dans mon commentaire.

Bon. Là, je suis un peu vénèr.
Je me suis forcé à me lever tôt pour entamer une batterie de test sur mes fonctions toutes neuves. Et j'ai eu droit à une belle plaisanterie de MSIE (pas uniquement de MSIE6, MAIS AUSSI dans MSIE7). J'ai passé 3 jours à développer des systèmes de formulaire, pour me retrouver avec tout le système incompatible avec le navigateur le plus pourri donc le plus répandu du marché.

Ooooh, MSIE se targue d'être parfaitement “compatible” avec des règles css comme :

(CSS)
* html {
mso-random-crap : true;
mso-more-unnecessary-wankery : 15;
mso-non-standard-selector : naturally;
}

Mais dans un formulaire, c'est autre chose.

Disons que vous avez un balisage du genre :

(HTML)
<form action="post">
<button name="LogBox" value="login" type="submit"><img src="interface/profileicon.png" alt="" /> Log in</button>
</form>

Vous vous attendez à avoir en retour :

(requête HTTP)
LogBox=login

ben non, sur MSIE j'ai :

(requête HTTP)
LogBox=<IMG alt="" src="interface/profileicon.png"> Log in

Farpaitement normal...

Chez Microsoft, on trouve tout à fait normal que tous les éléments d'un formulaire doivent renvoyer leur .value, sauf un qui doit renvoyer son .innerHTML. Vous pouvez tester vous même sur cette page
Pourquoi lui et pas un autre de ses petits camarades, mystère...

On rigole dans le fond, mais ce matin, ça m'a mis dans une rage folle.
Et encore, je viens de m'apercevoir (12h53) qu'en fait, il ne renvoie pas EXACTEMENT le code HTML, mais une version interprétée à sa manière : au lieu d'avoir <img src="" alt"" />, j'ai <IMG alt="" src="">...
Le plus surprenant... euh pardon, plus rien ne me surprend de Microsoft (Jusqu'où iront-ils ?) Ahem... Donc ce comportement a en plus la plaisanterie d'être incohérent. Car si dans votre formulaire vous n'avez qu'un élément <button></> , et pour peu que la lune soit rousse, votre serveur recevra :

(requête HTTP)
LogBox=login

Ne pas craquer... ne pas... craquer.

Pourquoi un <button> est mieux qu'un <input>

Styliser les éléments d'un <form></> est déjà assez pénible...
Faut quand même pas charrier, mais la balise <button></> apporte un indéniable plus sur <input type="submit"/> : on peut styliser à loisir, avoir un texte différent de celui envoyé au serveur (donc variant suivant les langues), y incorporer des images, faire de très chouettes boutons et .

En fait, les possibilités de stylisation sont largement supérieures, et tout webdesigner préfère largement utiliser une balise aussi malléable (qui d'ailleurs sur Mac OSX ne sont pas des boutons du GUI ce qui est plus simple à gérer, comparez avec l'autre) plutôt que l'austère <input type="submit"/>. Car cette dernière affiche dans son corps uniquement le contenu de l'attribut value= qui d'ailleurs est renvoyé dans la requête en cas d'appui.

Et un pti' coup de JScript te va m'arranger ça ma bonn' dame !

Heureusement, il existe un workaround pour que <button></> réagisse normalement dans MSIE. Mais en passant par un javascript : « Using Multiple "buttons" Elements in IE6 »

(Javascript)
function buttonfix() {
  var buttons = document.getElementsByTagName('button');
  for (var i=0; i<buttons.length; i++) {
    if (buttons[i].onclick) continue;

    buttons[i].onclick = function () {
      for(j=0; j<this.form.elements.length; j++)
        if ( this.form.elements[j].tagName == 'BUTTON' )
          this.form.elements[j].disabled = true;
      this.disabled=false;
      this.value = this.attributes.getNamedItem("value").nodeValue ;
    }
  }
}
window.attachEvent("onload", buttonfix);

ça fait lourd dans la balance, ça :

En espérant que votre code ne fasse pas partir en sucette MSIE et surtout que Javascript ne plante pas. En plus, tout dépend de là où vous le lancez. Si un <button></> génère un évènement Javascript (genre un système qui empêche une double validation, ou qui vérifie côté client que tous les champs obligatoires du formulaire sont bien remplis) ben forcément... ça marche pas.

Et dire que certains se plaignent de la disparition de Mozilla Netscape 0.93. On va quand même pas être obligé d'utiliser <input type="submit"/>
Hem...

Heureusement, il existe une autre voie : Pallier à ce souci côté serveur.

Server side : Solution inside ?

Cette méthode a l'avantage de marcher à tous les coups, sans renoncer à la balise <button></>, ni utiliser de méthodes particulièrement ésotériques qui va bloquer les gens normaux. Pour cela nous utilisons une étude comportementale du nEunEu dans son environnement scatologique.
Voici mon code en PHP, on arrête de rire derrière, c'est agaçant. Je tiens à signaler aux fanatiques de la boîte à cons MS-MVP qu'il leur sera aisé de traduire ça en Visual Basic :

PHP
function IEbugButtonValid($name,$value,$innerHTML)
{
  // comment palier aux bugs de MSIE sur le comportement de l'élément <BUTTON></BUTTON> par de l'accessibilité côté serveur
    // par défaut, on est pas bon
  $ok = false;

    // bonus : je fais en sorte que cette fonction marche dans les deux méthodes formulaires
  $retour = !empty($_POST) ? $_POST[$name] : $_GET[$name];

  if ($retour==$value) $ok=true; // le comportement NORMAL de la balise <BUTTON></BUTTON>

    // et maintenant, on déploie la rampe pour handicapés mentaux
    // d'abord, on vérifie qu'on a pas déjà eu une validation par le comportement NORMAL (rappelons que nEunEu est aléatoire)
  if ((!$ok) && (strstr($_SERVER['HTTP_USER_AGENT'],'MSIE')!=false))
    // c'est bien, nEunEu sait épeler son nom. On va pas lui en demander plus.
    // J'aurais pu tester Mozilla/4 , mais certains téléphones s'en servent encore sans s'appeler nEunEu
  {
      // on prépare la soupe dans le goût de nEunEu : on vire les balises HTML
      // parce que sinon, on va pas en sortir avec les inversions de paramètres et le changement de casse des balises
      //je vire aussi les espaces pour ne pas me faire avoir par ma propre indentation de code
    $innerHTML=ereg_replace('<[^>]*>','',str_replace(array(" "," ","\t",' '),'',$innerHTML));
      // kiii couïc kiii couïc kiii couïc
    $retour=ereg_replace('<[^>]*>','',str_replace(array(" "," ","\t",' '),'',$retour));
      // et une comparaison
    $ok = strstr($retour,$innerHTML)!==false;
      // kiii couïc kiii couïc kiii couïc
  }
  return $ok;
}

Oui, je sais, c'est parfaitement gruiiiiik comme méthode, mais moi, j'assume complètement. Et apparemment, ce code est parfaitement fonctionnel.
Moralité de cette fonction, au lieu d'avoir un joli code genre :

(PHP)
if ($_POST['LogBox']=='login')

je suis contraint d'avoir à la place :

(PHP)
if (IEbugButtonValid('LogBox','login','<img /> Log in'))

D'après vous, avec un “héritage” pareil, comment voulez-vous que Microsoft attire des développeurs vers ses nouvelles technologies web (C#, .NET, XALM, OpenXML, silverlight) s'ils les font enrager de cette manière-là ? Ça me semble évident que de moins en moins de gens s'intéresse à toutes ces merveilles quand on voit un fonctionnement fondamental aussi mal branlé passez-moi l'expression.

Et maintenant, exercice pratique :

Soit la déclaration suivante dans le blog officiel de l'équipe de développement de MSIE8 :

Nous avons la responsabilité de respecter le travail que les sites ont déjà fourni pour être utilisable avec MSIE. Nous devons améliorer notre support des standards et garder la compatibilité avec les anciennes versions de manière que (1) MSIE8 continue de marcher avec les milliards de pages du web qui marchent déjà avec MSIE6 et MSIE7 et (2) rendre le développement des prochaines milliards de page de manière interopérable encore plus aisé.

(Dean Hachamovitch, General Manager du IETeam)

D'après vous, après une telle déclaration, est-ce que ce bug fondamental[NB] va être corrigé ? Moi, je parie que Microsoft va le laisser tel quel pendant des décennies.

[NB] : À mon sens, ce bug est fondamental, car il intervient au niveau de l'interprétation des balises HTML et de la réponse HTTP. Ce qui veut dire que ni les spécifications ECMAscript ou CSS n'ont de prise sur lui, et que donc Microsoft peut clamer haut et fort qu'ils valident le test Acid2 et tout ce que vous voulez alors qu'ils sont complètement foireux sur la couche de base du web.