Reprise du message précédent :
Nan

Me***
 
Tant pis. Merci

ben l'autre (celui qui valide pas) tu en fais un type="button" qui fait du JS, je vois pas le problème

Bon tu arretes de faire ton crade, il peut tres bien tester la valeur renvoyée par le submit pour savoir lequel a été cliqué, mais la question était de savoir comment différencier celui qui valide de celui qui valide pas quand on appuie sur ENTREE pas quand on clique

Justement, un appui sur entrée ne se soumettra que par l'input de type submit

oui, nan parce que sinon tu vois, l'utilisateur, il fait entrée et ca fait un truc aléatoire (à priori je vote que ca envoie les valeurs des deux submits), donc c'est pas tout à fait ce qu'il veut, je suppose.

Ceci dit, ca fait exactement pareil ma solution

Je peux pas utiliser un "button", il faut que ce soit un submit.
 
En fait le 1er submit n'apparait que lorsque JS est désactivé (c'est pour aller cherche une liste de valeur correspondant à la valeur entrée), chose qui se fait sur un onchange en JS.
 
Quant au 2ème submit, qui lui apparait tout le temps, c'est pour valider le form pour de bon.

c'est plus simple de detecter si le js est activé et de renvoyer vers un autre formulaire multi page si il l'est pas non?

Pas trop envie de faire du multipage juste pour 1 champ. Et puis 2 forms différents c'est pas génial pour la maintenance je trouve.
 

J'ai eu une idée pendant la nuit (la nuit porte conseil hein )
 
Tout simplement une copie du 2ème bouton submit en haut du form... soit en apparent, soit en hidden, et ça roule.

Petite question : comment faire en sorte qu'un contenu de type "block" s'adapte en largeur, comme cela est fait automatiquement avec les contenus de type "inline" ?
Le problème est illustré ici (bloc encadré en vert : "Chargé de projet ..." ) :

Je ne sais pas si c'est possible. Essayes voir un avec un width: auto; mais j'ai des doutes.

Edit : Je viens tester, c'est bien ce qui me semblait, ça ne marche pas.

'tain, ça fait moultes fois qu'on en parle...ya rien de tout à fait standard.
inline-box et -moz-inline-block.

 
Bon ben avec un visibility: hidden; ça ne marche pas sous IE Sous FF oui, meme avec un display: none; d'ailleurs

 
Apparement ça a pas été assez répété pour que tu l'assimiles : c'est inline-block et -moz-inline-box    
Par ailleurs, son effet n'a pas très concluant : sous firefox, ça me bouffe tout ce qui suit un <br /> dans le bloc en question, et ss IE7, ça n'a apparement aucun effet !  

mon clavier a dû fourcher.
 
'fin bref, chez moi ça marchait pas trop mal, me semble-t'il...

sous emacs non ?

c'est facile de rejeter la faute sur ce pauvre clavier ! :-P
 
chez moi ça marche pas bien Donc la question est toujours ouverte ...

Pfff j'en ai marre de me battre avec IE

Bon, j'ai un script JS d'ajout de bbcode, je l'ai testé en "brut" sous IE, avec juste un form fait à l'arrache, ça marche. Toujours sous IE, j'essaye de l'intégrer à mon form déjà existant, ça ne marche plus correctement, ça insère bien les balises, mais AVANT le texte sélectionné (sous FF ça marche)

Voilà la partie incriminée :

Le "alert" c'est moi qui l'ai ajouté à des fins de debug

Sur ma page brute, j'ai bien une alerte avec la portion de texte sélectionnée.

Sur mon form déjà créé, j'ai bien une alerte, mais vide ... qu'est-ce qui fait que sur l'un ça peut être vide et pas sur l'autre ? D'autant plus que la fonction "document.selection.createRange()" n'est liée à rien (aucun ID ou autre chose) ...

Maintenant que j'y pense, il y a bien une petite difference, mais bon...

Sur la page sur laquelle ça marche, le script est integré à la page, alors que sur la page sur laquelle ça ne marche pas, il est appelé par <script src...

Ça pourrait venir de ça ? Parce que j'en doute quand même

Edit : sinon pour info, un alert(range) me donne bien [object]

J'ai trouvé \o/

Dans la 1ère page de test, mon <a onclick="... il avait un href, et pas dans ma 2ème page

Et quand on clique sur un "a" sans href, ça de-sélectionne le texte du textarea avant d'appliquer la fonction... alors que si un href est présent, le texte reste sélectionné

Edit : Ce qui est bizarre d'ailleurs, parce que sur HFR aussi ça de-sélectionne le texte ... mais bon, HFR c'est l33t

Un a sans href c'est spécialement naze Ca montre une utilisation incorrecte d'un a

 
<a c'est aussi la définition d'un anchor. Genre <A name="section2.1">

Kadregowned.

<a name="section2.1"> est bon , d'apres mes cours qui ne sont pas si vieux que ça
 
et <a id="section2.1"> est invalide ( un id qui contient . c'est mal )

 
En principe je mets toujours un href à mes a ... Là j'avais fais une liste de bouton pour tester le script, donc j'ai testé vite fait <a onclick... ... je ne pensais pas que ça aurait une incidence. De toute façon j'utilise des images

Salut à toi, homme de 1996 ! Savait-tu que depuis, la technologie avait évolué, et qu'on fout directement un id sur l'élément, pour faire une ancre ?

 
Euh, c'est l'homme du href qui dit ça ?

T'as un problème contre l'homme du href ?

 
Le href c'est dépassé mon bon monsieur, demain il n'y aura plus de liens, juste des tags, partout des tags pour égayer nos vies

Nan mais portnawak
 
En XHTML2 tu peux foutre un href sur tout. Oui, sur tout

 
Fini les conneries du style menu en <ul><li><a href="">truc</a><li><a href...

il manque <:ul>

encore pire quand tu veux remplacer le menu par des images
<ul><li><a href=""><span>truc</span></a><li><a href...

 
Le 2 c'est dépassé mon bon monsieur, les conférences du Web 3.0 ont déjà eu lieu, et la feuille de route du Web 4.0 est déjà en cours d'écriture chez les apôtres de la blogosphère toute puissante. De toute façon on fera tout avec des microformats, pour définir et délimiter nos microvies.

J'aime pas cette expression du Web 2.0, ça veut rien dire

 
D'où l'idée de passer directement au Web 3.0

dans le <li>

 
Les <a> imbriqués étant interdits, ça va se passer comment les elements ayant des href imbriqués ?

 
On ouvre tous les liens dans des tabs