da scritch net works - Les < button > d'acnée de Microsoft Internet Explorer - Commentaires

[ping] Les < button > d'acnée de Microsoft Internet Explorer - da scritch net works

da scritch net works — Sun, 21 Mar 2010 23:41:19 +0100

Propriétés en tests et préfixes de vendeurs

De leur histoire, leurs usages, leurs inconvénients et de ma petite contribution à solutionner le problème....

[ping] Les < button > d'acnée de Microsoft Internet Explorer - da scritch net works

da scritch net works — Thu, 11 Dec 2008 16:55:26 +0100

Microsoft Internet Explorer ou l'inflation dans la

Je ne sais pas comment ils font. Malgré tous leurs efforts pour rendre leur navigateur acceptable, ils arrivent à faire en sorte de devoir reprendre tous les anciens sites pour qu'ils fonctionnent comme avant....

Les < button > d'acnée de Microsoft Internet Explorer - Grobert

Grobert — Fri, 05 Dec 2008 12:47:20 +0100

Je viens d'être confronté au problème et un peu dans les même conditions (on croit que tout marche et puis... on teste avec IE ;-)
Il y a une autre solution qui convient à IE7 et aux vrais navigateurs. Elle est adaptée si
- la valeur associée au bouton est une chaîne ou un entier
- on traite le formulaire en PHP (peut-être adaptable à d'autres langages)

Cela consiste à «mettre la valeur dans le nom de la variable», via une table associative.

Au lieu de coder
name="lenom" value="qqchose"
on peut coder
name="lenom[qqchose]" value="qqchose ou peu importe quoi"

Au niveau du traitement PHP, cela devient
if (is_array($_GET['lenom']))
$valeur = key($_GET['lenom']);

On peut donc mettre plusieurs boutons submit avec des name="lenom[xxx]" divers. Si un seul est renvoyé comme cela devrait , cela fonctionne bien.
Dans le cas d'IE6 qui renvoie, parait-il, des value pour tous les boutons submit, mieux vaut revenir aux input !

[ping] Les < button > d'acnée de Microsoft Internet Explorer - da scritch net works

da scritch net works — Tue, 10 Jun 2008 12:19:51 +0200

Regardez : transparent... comme avant !

Afin d'être totalement transparent (et pas que dans les PNG), ce texte comporte du Microsoft-bashing rétrograde (concernant leurs produits avant 2006). Faut reconnaitre qu'ils ont fait des efforts, et qu'il est temps de moderniser les... visiteurs....

Les < button > d'acnée de Microsoft Internet Explorer - Mitch 74

Mitch 74 — Sun, 04 May 2008 10:14:18 +0200

Ah, la source de l'info est le blog de l'équipe IE, mais aussi (et surtout) que je l'ai testé dans IE8 beta 1 - et ça a l'air de marcher (en tout cas, dans ma VM).
Quant à dire quand il supplantera IE 7 (ou même 6, qui est toujours le navigateur par défaut d'XP, et la version maxi supportée par 2k), y'a pas moyen.

Les < button > d'acnée de Microsoft Internet Explorer - Da Scritch

Da Scritch — Tue, 22 Apr 2008 22:50:23 +0200

1- Je demande à voir (tu as la source de l'info ?)
2- Faudrait déjà que les parts de marché d'IE7 rendent ceux d'IE6 négligeable pour qu'on aie une bonne estimation de quand IE8 va remplacer IE7...

Ou alors, faire le forcing auprès des utilisateurs.

Les < button > d'acnée de Microsoft Internet Explorer - Mitch 74

Mitch 74 — Sat, 29 Mar 2008 10:38:54 +0100

Ouééé! IE 8 va corriger <button> en mode Uber Super Top Mega Standard (qui ne réussit pas Acid2, mais c'est une autre affaire).

Les < button > d'acnée de Microsoft Internet Explorer - Da Scritch

Da Scritch — Tue, 15 Jan 2008 15:41:20 +0100

Une autre page de tests, plus explicites : http://krijnhoetmer.nl/stuff/html/b...

Les < button > d'acnée de Microsoft Internet Explorer - Da Scritch

Da Scritch — Thu, 10 Jan 2008 09:02:17 +0100

@Hadrien : méchant, c'est la seule chose qu'ils savent faire sans bugs.

Nick Cowie vient de me donner plus d'éléments historiques :
«
The problem with MS is they don't want to break anything that worked before - backward compatibility. When MS released IE4 they badly implemented the button element. So to make sure any web page that used the button element that worked in IE4 kept working in IE5, IE5.5 IE6 & IE7 they retained the bad implementation.

It did not help that Netscape 4 did not implement the button element at all, even though it was in the HTML4 specs. So with no competition MS just kept making the browsers backward compatible, so the button element never gained any traction.

With mobile browsers, the people writing the XHTML-MP 1.0 specs excluded the button element, probably because no one used (It is now in the proposed XHTML-MP 1.2 specs, but that is still some time away). So people building browsers to the XHTML-MP 1.0 standards rightly did not included the button element. So button does not function in IE for WM5, Blazer for Palm OS, I believe and some other other browsers.

Opera Mobile and Mini as well as Safari for iPhone and probably the S60 Nokia browser (seeing it is based on webkit) and some other mobile browsers follow HTML4.01 / XHTML1 standards and button does work.
»

Les < button > d'acnée de Microsoft Internet Explorer - Hadrien.eu

Hadrien.eu — Wed, 09 Jan 2008 09:08:35 +0100

Chez Microsoft, il préfèrent faire des vidéos pas drôles de leurs chefs…

Les < button > d'acnée de Microsoft Internet Explorer - Da Scritch

Da Scritch — Wed, 09 Jan 2008 09:03:15 +0100

J'avais écrit à Nick Cowie sur les difficultés que j'ai rencontré, sa réponse est encore plus édifiante :
«
I found out about MSIE bad behaviour with buttons at the end of researching that presentation, so I never added it to the presentation. But it does make a very difficult case to use the button element in any project and you work just reinforced that for me.

However, what really put me off ever using the button element, was mobile web browsers. The XHTML-MP 1.0 specifications do not include the button element. It includes all other form elements and marquee and blink tags, but not the button element. So mobile browsers which conform to the XHTML-MP 1.0 specs like Internet Explorer for Windows Mobile 5, just ignore the button element and make the form useless.
»

Les < button > d'acnée de Microsoft Internet Explorer - Da Scritch

Da Scritch — Tue, 08 Jan 2008 23:09:05 +0100

@Mitch64 Ton analyse est erronée :
<Select></> ne renvoie pas leur contenu mais la valeur de la balise <option></>/ choisie (et non pas le texte affiché) et j'ai bien précisé VALEUR
<textarea></> renvoie sont innerHTML, mais il n'est pas ré-interprété. D'ailleurs, il s'agit en fait de la VALEUR qui est renvoyé. Et heureusement.
Alors que <button></> ... bon, déjà la recommandation HTML4 est floue mais surtout que dans le modèle DOM, MSIE voit bien une VALEUR (c'est ce qui est exploité par le javascript) mais ne renvoie pas cette VALEUR mais totalement autre chose. Qui plus est, il le renvoie systématiquement, même si <button></> n'a pas été enfoncé. Réessaie avec MSIE mon exemple et regarde le source. C'est franchement édifiant. Exemples encore ici : http://www.thescripts.com/forum/thr...
Nick Cowie note dans sa présentation pour le Perth WSG des petits “ajouts” de positionnement avec MSIE

On a un élément qui est cohérent sur tous les navigateurs sauf un, qui est reconnu bourré d'erreurs. Je veux bien croire que le W3 n'est pas très précis, mais vue l'ampleur de la catastrophe, je parie pour la grosse couffe qui ne sera jamais corrigé, pour contenter des sites qui sont totalement incompatibles avec les navigateurs actuels (Opera, Firefox, Safari,...).

Pour des raisons de style, je ne vais pas faire des boutons radio quand cela ne m'est pas demandé, et surtout, quand cela impose un clic supplémentaire. Qui plus est, dans ton commentaire plus haut, tu proposes d'utiliser un :before qui n'est pas compris par MSIE6. Si encore j'avais le moyen en css de faire une substitution par background d'un élément <input /> en n'affichant pas sa value (et si possible sans hack css disgracieux genre “-9999px”), je serais heureux... sauf que le rendu sur les Mac serait complètement foireux, puisque sur cette plateforme, un <input /> est rendu comme un élément Aqua, à la différence d'un <button></>.

Donc j'en suis venu à la conclusion que pour un formulaire avec un seul élément de validation, un seul <button></> fonctionne (avec mon code php plus haut) et est l'idéal quand le texte affiché n'est pas forcément celui du value.
Pour tous les autres éléments publics, on retombe dans <input />.

Désormais, je n'utiliserais le <button></> que quand je fais/ferais une interface complexe (au moins deux <button></> validant avec value) pour moi, pour un/e ami/e qui va s'en servir en direct et qui utilise déjà intensément un vrai navigateur (certains ne veulent pas ou ne peuvent pas et c'est exclu pour mes clients, mais d'autres en ont fait la demande, j'ai même une proposition pour une interface en xul).
C'est uniquement si son utilisateur utilise quotidiennement autre chose que MSIE.

Il faut continuer de faire du bruit autour, pour démontrer que l'époque des comportement propriétaires et incomplets des normes (HTTP, Javascript, PNG, SVG) et recommandations (XHTML, CSS, APNG) est révolue. Si on veut que MSIE aille dans la bonne voie, il faut secouer violemment Microsoft pour qu'ils corrigent leur navigateur s'ils veulent vraiment paraître modernes et performants, au lieu d'être exclus du web.
La TeamIE est sûrement de bonne volonté et a besoin d'être encouragée
Au fouet.

Les < button > d'acnée de Microsoft Internet Explorer - Mitch 74

Mitch 74 — Tue, 08 Jan 2008 20:35:54 +0100

en relisant de plus près, je dirais que, mine de rien, IE est assez consistant dans ses réactions à ce niveau-là; pour être précis, les <INPUT> sont des balises autofermées - donc sans contenu. Il est donc normal qu'elles ne puissent renvoyer leur innerHTML. Les 'seuls' autres éléments d'un formulaire (de tête) non autofermés sont les <SELECT> (renvoient la valeur de l'option sélectionnée) et les <TEXTAREA> - dont la 'value' serait de toute façon égale à l' .innerHTML, puisqu'il s'agit d'une zone définie du document pour contenir des enfants définis par l'utilisateur (à l'inverse d'un input type texte dont la valeur est modifiée par l'utillisateur - nuance subtile au niveau du DOM).

Ce qui doit te faire pester, c'est que IE te renvoie un extrait du DOM tel qu'il le constitue, et non la valeur exacte présente dans le noeud - ça, c'est plus gênant.

Parce que sinon, en ce qui concerne les valeurs différentes selon le bouton 'submit' pressé, il serait plus sûr au niveau de l'interface et des infos transmises d'utiliser des boutons radio, lesquels déclencheraient l'event 'submit' afin de t'assurer que 2 boutons 'submit' ne sont pas pressés en même temps (si c'est possib' et ça arrive) et à ce moment, ton internationalisation pourrait se faire au niveau des LABELs associés à ces boutons radio (dont tu dissimulerais la valeur affichée, laquelle pourrait alors rester la même. Tu transmettrais le langage actif via un inut 'hidden', dont la valeur peut aussi te servir à savoir si JS était actif, fini basta).

Tu laisses le bouton 'submit' apparaître uniquement dans les cas où Javascript n'est pas actif, et hop problème réglé...

L'avantage des boutons radio, c'est que tu peux aussi les mettre où tu veux (pas forcé de les grouper).

Les < button > d'acnée de Microsoft Internet Explorer - Hadrien

Hadrien — Tue, 08 Jan 2008 16:15:20 +0100

"Impossible d'obtenir un code propre et internationalisable sans effort." Si le web dev se faisait sans effort, on serait au chômage ;)

Les < button > d'acnée de Microsoft Internet Explorer - Da Scritch

Da Scritch — Tue, 08 Jan 2008 13:56:06 +0100

Typiquement le problème qui me bloque : plusieurs boutons de validations (pour plusieurs actions possibles sur le même formulaire) et avec plusieurs versions linguistiques du même site.
Si <button>texte</> marchait bien, j'aurais aucune difficulté.
Là, je suis en train de ruser entre soit plomber mon code par x valeurs possibles retournée par <input type=submit value="texte" />, doubler le nombre de réponses possibles avec <button>, ou ruser en css en effaçant le texte affiché par <input /> et en ayant plusieurs fonds stylisés.

Proprement débile. Impossible d'obtenir un code propre et internationalisable sans effort.

@ xylpho
désolé. j'aurais dû hurler "gros béta"

Les < button > d'acnée de Microsoft Internet Explorer - xylpho

xylpho — Mon, 07 Jan 2008 11:41:06 +0100

J'ai jamais dit que c'était stupide :)
C'est juste que c'est contre-productif sur ta facture finale.
Et c'est toi qui m'a traité d'idiot mon cher Xavier

Salutations

Les < button > d'acnée de Microsoft Internet Explorer - Da Scritch

Da Scritch — Mon, 07 Jan 2008 11:07:23 +0100

@ouf : eeeh ! réveille-toi : Netscape est mort. Mort et enterré. ( http://blog.netscape.com/2007/12/28... ) Quant à Javascript selon Microsoft, le langage n'est pas réglé par une recommandation (comme le W3C pour le HTML), mais par une normalisation (par l'ECMA, d'où le nom ECMAscript), et il te suffit de chercher dans mes billets sur javascript pour te rendre compte de l'incohérence de Microsoft.

Par exemple, une chaîne vide renvoie forcément "". Sauf pour MSIE : "null"
Super vide ta chaîne de caractère, non?
Microsoft a beau avoir des gens talentueux (ils peuvent se les payer, ou les laisser s'échapper comme Window Snyder), ils ont des managers qui n'y connaissent rien et qui refusent de remettre en cause leurs opinions foireuses.

Les < button > d'acnée de Microsoft Internet Explorer - Hadrien

Hadrien — Mon, 07 Jan 2008 10:57:45 +0100

@ giz404 : Ce qui est grandiose, c'est de facturer au client du temps passé à rechercher quelquechose que tu ne sais pas faire et qui va te resservir plus tard mais dont le client n'a que foutre.
Il avait pas signé un devis avec un nombre prédéfini d'heure ton client ?

Les < button > d'acnée de Microsoft Internet Explorer - ouf

ouf — Sun, 06 Jan 2008 19:11:29 +0100

Ouf ... Cette fois mon système n'est pas mis a mal. Microsoft a la facheuse habitude de décider que telle ou telle autre fonction javascript devait être ... L'équipe IE (attend toujours un exemple concret du au code) a décidé que le codage de mes exemples (suis pas webmaster donc fais juste pour fonctionner) provoquait des erreurs ... Pas une d'erreurs sur le navigateur IE8 et Autres mais une bonne vitesse de rendu. Il est vrais que ... pour contourner les verouillages ie il existe un assembleur de script dans la version FX. Sinon marche bien dans le format dévelope pour netscape ... Pour un navigateuir qui marche .. optez pour netscape.

Le tout PHP est la meilleure solutions pour controler internet via des bases de donnés .. Petit a petit .... Renoncer a html pur et Javascript peut avoir des conséquence nuisible pour le net en général.

Allez ... J'est l'habitude des expertises ...

Juste entre nous ... Faut pas aller dans l'exé .. malgrés le côté un peut snob de microsoft .. ceux-ci bossent bien.

Les < button > d'acnée de Microsoft Internet Explorer - Mitch 74

Mitch 74 — Sun, 06 Jan 2008 13:24:00 +0100

Perso, j'ai fait l'impasse sur <button>; j'utilise <input type="submit">, avec une bonne dose de CSS pour lui donner le contenu que j'ai envie. Déjà, je trouve 'button' redondant: j'ai même du mal à comprendre comment il a pu être conservé en HTML 4.0.

Perso, pour moi il tombe direct dans la catégorie 'Quirks' - et même si je suis 100% d'accord avec toi pour dire qu'IE est une merdaille sans nom, je trouve inutile de pester sur une cagaille pareille - il serait plus efficace de donner une méthode CSS pour styler un input, comme 'border', border-radius, background-attachment, input[type="submit"]:before {url="icone.png"}, etc.

Ben oui - ça marche comme ça. Et si ça marche pas, au moins tu n'as pas un affichage imbitable sur le navigateur cible.