Discussion :

[s.n.a.f.u]

Bon de toute façon je dis des bêtises étant donné qu'un formulaire ne peut avoir comme descendant direct (enfant) que des éléments de niveaux bloc.

Pourquoi ? C'est une spécification ou y a-t-il une justification ?

[Erwan31]

Pourquoi ? C'est une spécification ou y a-t-il une justification ?

Je dis encore des bêtises puisqu'il a un élément fieldset qui englobe tous ça

http://giminik.developpez.com/xhtml/form.html
ou encore http://www.la-grange.net/w3c/html4.0...html#edef-FORM

C'est nécessaire selon les spec HTML4.0 quant à savoir pourquoi, ben là il faudrait demander à un des membres du HTML Working Group du W3C

[Candygirl]

Bon de toute façon je dis des bêtises étant donné qu'un formulaire ne peut avoir comme descendant direct (enfant) que des éléments de niveaux bloc.

oui, mais non

Du moment que apt affiche un doctype transitionel, les input peuvent être enfants du form, si je ne m'abuse.

[Deallyra]

Encore mieux (mais ça dépend du contexte...)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<input name="Accept" type="button"  value="Accept3" class="submit"/>
<input name="Refuse" type="button"  value="Refuse3" class="submit"/>

Hum... Ne manquerait-il pas un espace avant le /> ?

[Erwan31]

oui, mais non
Du moment que apt affiche un doctype transitionel, les input peuvent être enfants du form, si je ne m'abuse.

Oui c'est vrai tu as raison mais pour des raison de compatibilité ascendante, autant viser
une validité en strict AMHA. Voilà un type d'erreur qui ne pose a priori pas de
problèmes mais pourrait en poser dans certains User Agents actuels ou à venir.

EDIT

Hum... Ne manquerait-il pas un espace avant le /> ?

Oui oui mais je n'ai fais que copier le code

[apt]

Bon de toute façon je dis des bêtises étant donné qu'un formulaire ne peut avoir comme descendant direct (enfant) que des éléments de niveaux bloc.

Donc il faut bien imbriquer les 2 input dans un div ou un p (plus commun).

Apt > préfère la solution de jlm694.

Ta derniere solution correspond bien à celle donné par jml94.

Et puis j'ai essayé trois solutions dont les deux premières ont bien fonctionnées

[apt]

Hum... Ne manquerait-il pas un espace avant le /> ?

Oui, les éditeurs ajoutent toujours un espace avant le />

mais même sans ça fonctionne !

Y'aura-t-il une inconvéniant en supprimant cet espace ?

[Deallyra]

La question était plus pour Erwan31 ^^

En fait, de ce qu'il me semble avoir apprit quand je me suis mise à jour pour le xHTML, les balises qui n'était pas fermée en HTML sont fermées en html par " />"

Maintenant, ça ne change peut être rien sinon à la validation W3C.

edit : je viens de voir ta réponse

[apt]

La question était plus pour Erwan31 ^^

J'ai répondu parce qu'il a dit :

Oui oui mais je n'ai fais que copier le code

Mon code

Merci pour ta réponse.

[Candygirl]

Maintenant, ça ne change peut être rien sinon à la validation W3C.

Non , la syntaxe sans l'espace est correcte et passe la validation. Cependant, dans l'Appendice C (Règles de Compatibilité HTML) de la recommandation xhtml1.0 il est indiqué qu'il vaut mieux inclure un espacement avant le / d'un élément vide pour une question de compatibilité avec certains (vieux?) agents utilisateurs.