Balise fermente </form> et saut de ligne.

Bonjour à tous,

j'ai un formulaire des plus basiques, mais je voudrais comprendre pourquoi la balise fermente saute obligatoirement une ligne.
Je voudrais par exemple que ça ne saute pas de ligne pour pour pouvoir écrire un teste à côté du bouton, après la balise.

Voilà le code que j'utilise :

<form method="post" action="index.php?page=resultats">
<input type="text" class=mailinglist maxlength=150 name="recherche" value="" />
<INPUT TYPE="image"  class=imgs NAME="envoyer" SRC="kit/envoyer.jpg" width="26" BORDER=0>
</form>texte à placer à côté du bouton ok

Je n'arrive pas à contourner ce problème. Je sais qu'on peux passer par javascript et Onclick, mais j'aimerais vraiment éviter javascript et résoudre ce problème en codant correctement.

Voilà, j'espère que je suis assez clair...

Merci à tous.
Modifié par lesfabuleux (05 Sep 2006 - 21:01)

Bonjour,

A la lecture de ton code, j'avoue être perdu, je ne reconnais pas le dialecte htlm employé, des minuscules ou des majuscules pour les éléments, tantôt des valeurs d'attributs encadrées de guillemets, tantôt non.
Je te conseillerais de revoir en premier lieu les bases des constructions des formulaires html et de html.

Quelques pistes:
-Des formulaires plus simples.

ps: avec un exemple en ligne il serait plus simple aux membres du forum de venir en aide. Une intuition me fait penser que côté html le problème est plus profond

Le problème n'est pas là, tu es sur un site qui traite des standards web, Igor te faisait remarquer que tu ne les respectait pas, c'était pas méchant.

Je comprends bien que ce site traite des standards, et je ne suis pas venu avec un site tout en tableau ou des balises non valables. Qu'un élèment soit en majuscules ou minuscules n'est pas une question de standard.

Le truc ici, c'est que ce genre de remarque est toujours fait avec agressivité et dédain, du genre " le dialecte htlm employé", en gros, c'est à chaque fois, va revoir les bases et ne pose pas de question. Mais alors quel est le rôle du forum ? Vendre indirectement les livres de Raphaël Goetter ?

Ce qui est lassant, c'est de voir la condésendence de certains qui font exprès de jouer à ceux qui ne comprennent pas, qui vont semblant de ne pas comprendre dans le but de rabaisser ce qui viennent poser des questions.
Les standards, c'est fait pour que tout le monde puisse acceder à l'information, quelque soit leur handicap leur équipement, etc. Et sur ce site, c'est l'inverse, on a des gens qui ont un gros bagages en code, qui on un super matos et qui font exprès de ne pas comprendre, c'est un peu paradoxal ! Vous défender l'accès universel et vous faite exprès de ne pas comprendre ?

Ok, on sait vous êtes des pro qui assurent, qui connaissent tout au CSS, on a compris, c'est pas la peine de remballer les gens à chaque fois, pour une histoire de minuscule qui ne change rien.

Il suffisait de m'orienter vers cette page
et celle-ci, cela aurait été un peu plus productif non ?
Modifié par lesfabuleux (06 Sep 2006 - 13:02)

Désolé de te contredire, mais si, en XHTML 1.0 strict les majuscules ne sont pas valides par exemple, c'est bien une question de standard. Je ne vois aucun dédain dans la réponse d'Igor, tu es dans un forum qui a un thème précis, Igor t'indique des erreurs en rapport avec ce thème, que ce soit le réponse que tu attendais ou pas me semble hors de propos: ton code n'est pas "propre", c'est un fait.

Alors ne t'offusque pas qu'on commence par te dire que ton code n'est pas valide, c'est le thème du forum, et la validité du code c'est pas simplement pour la beauté du geste que ça existe... Avant de regarder pourquoi ça marche pas, on regarde forcément si c'est bien écrit.

lesfabuleux a écrit :

C'est étonnant que pour quelqu'un qui a posté plus de trois milles message tu ne comprennes pas le "dialecte html employé".

C'est vrai qu'après tous ses messages à répéter qu'une structure html robuste et valide évite bien des problèmes, on trouve encore des propos d'une telle pertinence dans ce forum .

a écrit :
C'est vraiment ça le problème de ce site : Donne des leçons à des gens en permanence, qui viennent juste pour demander une info précise, du genre "Pourquoi une ligne est toujours autée après une balise </form>"

Tant que ton code ne sera pas valide, nous ne le saurons peut-être jamais.
Lire également: Valider ? Pour quoi faire concrètement ?

a écrit :
A chaque fois que je viens, je me fais remballer... Par exemple, dans ce cas précis, mon formulaire marche très bien, merci, mon problème n'est pas là. Et tu me renvois, en te moquant de moi, à mes cours d'HTML, mais à quoi ça sert d'ouvrir un forum si c'est pour n'y accepter que ceux qui sont très forts ?

Je ne me moque pas, je t'indique une ressource pertinente que j'ai déjà utilisée pour la construction de formulaires sans avoir le type de problème que tu rencontres et effectivement je ne comprend pas quelle version de html tu utilises, le code que tu présentes m'indique à coup sûr que tu n'as pas vérifié la conformité de ton code avec une DTD, ou que tu n'en as pas choisi une. Voici une ressource pour en choisir une adaptée à tes besoins: Les DTD HTML4.01 et XHTML1.0 : comment choisir ?.

Il ne sert à rien d'esquisser une réponse sur une base html fragile et sans le contexte de la page complète.

Plus gérérique sur le html: Écrire une page Web

Igor a utilisé l'ironie pour te faire remarquer que ton code HTML manquait de cohérence. C'était peut-être maladroit (à voir...), mais ça n'est pas une raison pour prendre la mouche ainsi, et voir du dédain là où il n'y en a pas.

Effectivement, HTML n'est pas sensible à la casse, et accepte aussi bien les attributs entourés de guillemets que ceux sans guillemets. Du point de vue de la validité du code, tant que tu restes en HTML (et pas en XHTML), il n'y a donc pas de problème.

Par contre :
1. La syntaxe irrégulière (pas fausse, mais manquant de régularité) de ton code rend sa lecture difficile... or, c'est bien à des humains que tu demandes de lire ce code. Tu diminues donc tes chances d'obtenir une réponse en ne présentant pas ta demande au mieux, de la manière la moins perturbante pour les différentes personnes susceptibles d'intervenir sur ce sujet.
2. Ce forum est fréquenté par de nombreux débutants, dont certains se contentent de lire les sujets pour apprendre à partir de cas concrets. Une remarque sur la qualité du code s'adresse non seulement à toi, mais aussi à tous ceux qui liront ce sujet.
3. Ce forum a pour but de promouvoir certaines bonnes pratiques. La rigueur du code en est une, qu'elle soit absolument nécessaire (avec les langages qui renvoient des erreurs bloquantes sur des erreurs de syntaxe) ou juste méthodologiquement utile. Sur ce dernier point, utiliser toujours la même notation pour les attributs et valeurs en HTML, même si ça n'est pas requis par les navigateurs ou les validateurs HTML, permet de mieux se relire et d'éviter, par exemple, d'ouvrir un guillemet sans le refermer, ce genre de choses.


Sur le soi-disant élitisme de ce forum, je dirai juste que la « ligne éditoriale » de ce forum est de promouvoir un ensemble de bonnes pratiques de conception, tout en restant ouvert à tous les niveaux. Vu le nombre de personnes qui arrivent comme débutants complets ou presque sur Alsacréations et le forum d'Alsacréations, et qui assimilent grâce aux tutoriels et au forum une partie de ces bonnes pratiques de conception, je pense que cet objectif est globalement rempli.

Je ne répondrai pas plus avant aux attaques et reproches contre ces forums et les personnes (modérateurs ou non) qui l'animent.


Pour revenir à ton problème, il aurait été plus simple de placer le texte à l'intérieur de l'élément form. Rien ne l'interdit, et ça ne pose aucun problème. Si tu pense à ce que l'on appelle « un formulaire » dans le format papier, tu verras que les explications contextuelles font partie intégrante du formulaire.

Salut,

Pour répondre à ton interrogation, la balise "form" est une balise de type "block". Il est donc normal qu'après sa fermeture, il y ait un retour à la ligne automatique

Un peu de lecture : Informations concernant la balise <form></form>

Sinon, tu peux éventuellement essayer de forcer la balise "form" à devenir une balise de type inline par un display:inline; dans le CSS.

Bonjour tout le monde,
Je me permets de relancer le sujet parce que le pb n'a pas été résolu et que je l'ai également.
Je le rappelle rapidement :
j'ai un saut de ligne (et non pas un retour à la ligne propre aux balises de types bloc) après (et aussi avant mais là ça me gêne moins) la balise fermante d'un formulaire.

Concrètement voici le code :

<body>
avant<form action="#self">
		form 1
	</form>après
</body>

Ce qui donne visuellement :

Or je voudrais que le formulaire se comporte comme une balise bloc classique avec juste un retour à la ligne et non pas un saut de ligne.

Quelqu'un saurait-il d'où ça viendrait et surtout comment régler ce problème ?

Merci

P.S : j'ai ce problème avec IE (7 j'ai pas pu tester avec la 6) et parfois sous Firefox.
Modifié par Nycoala (12 Jun 2007 - 11:19)

Bonjour,

Nycoala a écrit :
Or je voudrais que le formulaire se comporte comme une balise bloc classique avec juste un retour à la ligne et non pas un saut de ligne.

Quelle est la différence entre un « retour à la ligne » et un « saut de ligne ». Si un saut de ligne consiste à laisser une ligne vide, il n'y en a pas ici. Il y a juste un écart entre le formulaire et le texte qui le précède ou le suit. Cet écart ne correspond à priori pas à une ligne de texte, mais plus probablement à des marges ou padding.

Tu peux tester :

form {margin: 0; padding: 0;}

Mais ça ne vient pas forcément de là.
Conseil : avec Firefox, tu peux utiliser l'extension Firebug pour retrouver les styles qui s'appliquent à un élément.

Conseil bis : si tu nous avais présenté quelque chose qui ressemble plus à du vrai contenu, il aurait également été possible de te conseiller un balisage peut-être plus approprié...
Modifié par Florent V. (12 Jun 2007 - 12:29)

Merci Florent V.
Tu as raison en disant qu'il ne s'agit pas exactement d'un saut de ligne puisqu'on ne peut pas mettre de texte dans cet espace. Il s'agit bien d'un problème de margin et de padding qui a été résolu en les mettant à 0px.
La solution était simple et je ne sais pas pourquoi je n'y ai pas pensé plus tôt.
De plus je ne voulais pas présenter un contenu plus élaboré parce que ce n'était pas nécessaire pour présenter le bug, qui était d'autant plus visible avec un contenu restreint. De toute façon mon contenu n'était rien de moins qu'un formulaire classique qui ne changeait rien au problème de "saut de ligne".
En tout cas merci.