Meilleur moyen de mise en page dans les formulaires HTML?

Je veux afficher un formulaire HTML contenant étiqueté champs de texte, comme ceci:

 Prénom: [_____________] 
Nom De Famille: [_____________] 
Date de Naissance: [________]

Mon approche évidente est d'utiliser un <TABLE> et il suffit de placer les étiquettes et les champs de texte dans les cellules, mais est-il une meilleure façon de faire, par exemple, une fonction de CSS approche?

EDIT:

Je suis à la recherche d'une manière qui réduit le niveau de verbosité dans le fichier HTML.
Et oui, je suis à la recherche pour le redimensionnement automatique des étiquettes. Voir un liés à la question sur les étiquettes d'emballage

InformationsquelleAutor Tony the Pony | 2010-05-25

37

Si vous avez besoin d'étiquettes à gauche des champs comme ça, juste aller de l'avant et à l'utilisation d'une table. Non seulement les tables de dégrader parfaitement sur les navigateurs plus anciens, mais ils automatique de la taille de la colonne d'étiquettes pour le texte en eux (en supposant que vous utilisez white-space: no-wrap sur les cellules contenant les étiquettes et/ou — et cela est vrai de l'hérésie — le bon vieux nowrap attribut sur la th tag), ils manipulent des faits assez étroit bien, et ils sont faciles. Faire de chaque cellule de l'étiquette d'un en-tête et de chaque champ de la cellule une cellule normale. Et c'est une douleur, mais assurez-vous que les étiquettes sont vraiment labels et des liens vers leurs champs, parce que les questions d'accessibilité, même si (et peut-être surtout si vous êtes en utilisant une table non sémantiquement.

J'aimerais beaucoup entendre parler de CSS solutions que la détection automatique de la taille de l'étiquette de colonnes, la poignée étant étroit bien, et n'impliquent pas de 18 hacks pour faire face à des incohérences dans les navigateurs. Je serais ravi de les voir. Mais chaque fois que j'ai regardé (et qui est plusieurs), c'est encore un écart. Un vide qu'il faut remplir, IMV, afin que nous puissions arrêter de faire cela sans porter de hairshirts.

Pour tous ceux qui lisent, qui n'est pas besoin de les étiquettes à gauche comme ça, découvrez jball réponse pour une bonne recherche, sémantique alternative.
- Il fonctionne à merveille sur reddit -- garanti upvotes à tout poste qui mène "je sais que je vais obtenir downvoted, mais". C'est comme les gens de lire et de penser "Ah ouais? AH OUAIS?! upvote prends ça!"
- Pas prévu de cette façon, mais je comprends comment vous avez pu lire de cette façon. (Aucun appel à la prestation de serment, si.) Mais pour plus de clarté: je ne pas pense que toute personne qui veut downvote c'est une motte.
- Mrozek: [hors-sujet] je sais. J'ai développé une règle de ne jamais upvote rien "appel" pour un downvote, même pas lorsque je vous l'aimez, après avoir vu cette infestation sur reddit.
- et les trois (pour l'instant!) upvoters sur son commentaire: je n'ai jamais été sur reddit (oui, vraiment) et je n'ai pas vu ce problème sur DONC. J'ai retiré les commentaires que vous avez pris de l'exception, merci de me le faire savoir.
- J'ai regardé Plan, et avec respect, il échoue lamentablement sur les "hacks" avant. Et la complication de l'avant.
- C'est une question de principe. Les Tables sont pas pour la mise en page. Plus.
- Eh bien, nous avons tout à fait en désaccord là. 🙂 Et juste assez.
- Merci pour cette! Bon de vous. 🙂
- +1 pour moi. Le point de la CSS push n'a pas été de se débarrasser de tous <table/> s, c'est de cesser d'utiliser <table/> s à rendre des mises en page tabulaire. Mais si vous êtes réellement rendu d'une table... utiliser un <table/>! C'est le point de vue sémantique, le bon choix.
- K: parfois, lorsque les résultats souhaités répond principe, résultat désiré gagne
- J' refuser à croire qu'il s'agit d'une situation où c'est le cas.
- Autant je suis d'accord sur le principe de base, je pense juste que les aveugles de l'absolutisme est futile. Le fait est qu'aucune autre solution n'offre tout vous pouvez le faire avec un tableau dans ce cas. Vous pouvez aller faire un compromis et de sacrifices, mais parfois vous avez juste payé pour faire ce qu'on vous dit.
- Vous avez raison, les tableaux ne sont pas de mise en page. Sauf qu'à l'aide de tableaux de formulaires est parfaitement sémantique, puisque les formes sont données tabulaires. Et que d'un point de vue général, le terme "pur CSS" me donne envie de tirer mes cheveux. Par définition, un pur CSS site web est un concept inexistant.
- Les formes ne sont pas des données tabulaires. Mise en page et les styles, ce qui est signifié par "pur CSS," pas que les tables sont interdits.
- Ne pas traîner (esp. depuis que j'ai initialement convenu que ce n'était pas une sémantique de l'utilisation de tables), mais de Chèvre et roufamatic ont un point intéressant. Si j'ai eu une série de lignes où la th contenus (dire) "prénom:" et au td contenus "Sam", la ligne suivante est th était "nom:", et a été suivi par td = "Samson", qui serait tablular de données. Alors pourquoi n'est-il pas de tableaux de données si le "Sam" et "Samson" sont des champs? C'est une question intéressante...
- vous devez copier votre dernier commentaire dans la réponse, comme c'est un bon point. Cela m'a vraiment ouvert les yeux 😉
- Les Tables de tomber à court, ici, si on a besoin d'utiliser des balises html fieldsets. Et autant que je sache, une légende dans un fieldset est le seul approprié et accessible pour le nom ou l'étiquette de "de" plusieurs boutons radio.
InformationsquelleAutor T.J. Crowder
19

En termes de facilité d'utilisation et si l'espace vertical est pas un facteur limitant, une liste de champs avec l'étiquette au-dessus de chaque champ est le moyen le plus rapide pour lire et remplir, et peut être fait en terme d'esthétisme. Voir de nombreuses études d'utilisabilité sur le web pour plus d'info, par exemple. http://www.lukew.com/resources/articles/web_forms.html
- +1 pour LukeW, mais j'aimerais garder des étiquettes alignées à droite, à gauche, l'une des pratiques de son étude préconise pour les utilisateurs occasionnels.
- +1 je suis un grand fan de ces lorsque vous pouvez le faire, non pas (seulement) pour le balisage sémantique raisons, mais pour des raisons esthétiques. Ils ont juste l'air bon.
- +1 pour le référencement "études d'utilisabilité" sur une question où j'aurais prévu de mettre l'accent sur la table-des dispositions de la guerre sainte
InformationsquelleAutor jball
14

Je voudrais utiliser les listes de définition (<dl>) ils ont tendance à être sémantiquement correct.
Une étiquette est définie par une saisie de l'utilisateur. Il n'a de sens pour moi.
<dl> exprime la sémantique du contenu avec plus de précision que d'une table.
```
<dl>
    <dt><label for="name>Name</label></dt>
    <dd><input type="text" id="name" /></dd>

    <dt><label for="email>Email</label></dt>
    <dd><input type="text" id="email" /></dd>
</dl>
```
Voici un exemple

Par la façon dont ils se dégrader gracieusement dans tous les navigateurs, même à base de texte.
- cette technique n'est jamais venu à moi... cela ne semble pas être sémantiquement correct, simple, et fonctionne sur tous les navigateurs... réussir à tous les trois de ces catégories en fait la bonne réponse, à mon humble avis. +1
- C'est une approche intéressante. Je ne pense pas que je suis avec vous du point de vue sémantique, mais c'est une question d'opinion. Malheureusement, il a encore le problème que tous le CSS solutions que je connais ont a: Les étiquettes ne sera pas automatique de la taille de l'OP dit qu'elle veut. Vous devez explicitement leur donner une taille (dans votre "exemple", 33% à 50% de la largeur du navigateur).
- Ne pas appliquer une display: inline-block faire le tour de redimensionnement automatique ?
- Non, je crains que ça ne l'aide pas. Ce qui rend surtout semble pour le travail est la width:33%, pas la display: inline-block (bien que vous le faites aussi besoin que avec dts pour cette). Cela signifie que le dts seront tous au moins 33% du conteneur, mais une longue label serait plus, résultant en quinconce look. Peut-être pas une grosse affaire quand vous avez fait les étiquettes, grand (~17% de la largeur de la fenêtre du navigateur), mais vous n'avez pas l'habitude d'avoir beaucoup d'espace pour travailler avec.
- très astucieuse technique
InformationsquelleAutor Boris Guéry
5

Je pense que quelque chose comme cela, c'est ce que je fais, mais aussi de ne pas autosize à la longueur du texte, mais c'est plus propre à mon avis
```
<form>
  <label for="firstName">First Name</label>
  <input type="textfield" name="firstName" />

  <label for="lastName">Last Name</label>
  <input type="textfield" name="lastName" />
</form>

label {
  float:left;
  width:30px;
}

input {
  float:left;
  margin-left:30px;
}
```
- Largeur fixe signifie que votre présentation dépend du contenu
- Cette approche fonctionne mieux si vous ajoutez clear:both pour l'étiquette et display: block pour les deux label et input.
InformationsquelleAutor Catfish
4

L'article est un peu vieux, mais j'ai toujours trouvé une liste à part les conseils pour être solide: (si vous ne voulez vous débarrasser de vos tables)

http://www.alistapart.com/articles/prettyaccessibleforms/

InformationsquelleAutor quoo

CSS Tableau d'Affichage

À partir de IE8+ vous pouvez utiliser les CSS Tableau d'Affichage pour cette:

Meilleur moyen de mise en page dans les formulaires HTML?

<!DOCTYPE html>
<html>
<head>
<style>
form > div > label { text-align: right; vertical-align: top }
form { display: table; }
form > div { display: table-row; }
form > div > label,
form > div > textarea,
form > div > input { display: table-cell; }
</style>
</head>
<body>
<form method="post">

<div>
<label for="name">Name</label>
<input type="text" id="name" size="14"/>
</div>

<div>
<label for="message">Message</label>
<textarea id="message"></textarea>
</div>

<div>
<label for="ssn">Social Security Number</label>
<input type="text" id="ssn"/>
</div>

<div>
<label></label>
<input type="submit" value="Send"/>
</div>

</form>
</body>
</html>

Cela ressemble juste comme vous êtes en utilisant une table... oui, via le CSS, mais c'est à peu près la même chose...

InformationsquelleAutor Jonas

2

Utiliser un framework CSS comme Plan et de l'utiliser pour le style de l'formes.

Une autre astuce serait de créer virual "colonnes" avec les css et les faire flotter à côté de l'autre. Les étiquettes dans une colonne et les entrées dans l'autre. Mettre (deux colonnes) dans un div avec une assez grande largeur et flotter les colonnes de l'opposé de ce que vous souhaitez aligner.

Voici un code (parce que je suis entrain de créer un formulaire) que sera de travail pour les formes de base. La seule contrainte est la grande marge de droite sur les intrants.
```
form input, form select
{
    float: right;
    margin-right: 650px;
}
form label
{
    float: right;
    margin-top: 5px;
    margin-right: 10px;
}
form .nofloat
{
    float: none;
    margin: 0;
}
form br
{
    clear: both;
}
```
Et la mise en page comme
```
<input type="text" id="name" />
<label for="name">Name</label>
<br />
```
Sur le dessus de cette petite, de justesse code écrit, il y a un intégralité de l'article liées à la création de tableless formes en CSS.
- La dernière fois que j'ai regardé Plan (environ un an), il n'a pas s'afficher correctement sur tous les navigateurs populaires et impliqué beaucoup trop de hacks et les circonvolutions.
- Deux colonnes de pire pour l'accessibilité de la table, dont au moins les maintient dans l'ordre de lecture logique.
- Et une table pour les tables de l'information. Ce n'est pas l'utilisation correcte.
- On peut très bien soutenir que c'est en fait une table d'informations
- Il n'est pas. C'est pour entrée, la non-présentation des lignes et des colonnes de données.
- Eh bien, d'entrée ou de sortie des données de toute façon. Un tableur a beaucoup si entrée cellules, et c'est toujours un tableau, n'est-ce pas.
- Non, il n'est pas. C'est un libre formant une feuille de calcul. Les formes ne sont pas.
- Bien ne peut pas dire grand-chose contre les "non ce n'est pas le genre d'arguments.
InformationsquelleAutor Josh K
0

En général, j'ai trouvé qu'il y a au moins certains problèmes lorsque vous n'utilisez pas de Tables pour les formulaires. Le général des choses que je n'ai pas été en mesure de résoudre:
- Couleur d'arrière-plan pour les champs/entrées n'est pas vraiment possible sans un faux fond
- Auto-dimensionnement des colonnes, mais je pense que c'est OK
- Champ hover en CSS, vous pouvez utiliser du JS, mais les Tables peuvent le faire avec de la pure CSS
J'ai peut-être manqué quelques choses, mais le plus flexible mark-up si vous êtes en utilisant le CSS est comme ci-dessous:
```
<div class='form-field'>
   <label>Name</label>
   <input />
</div>
```
Vous avez des questions, si vous souhaitez que plusieurs champs par section de l'étiquette, de sorte que vous avez à introduire un autre div pour contenir les entrées (pour permettre à l'étiquette continuent de flotter à gauche etc):
```
<div class='form-field'>
   <label>Name</label>

   <div class='form-inputs'>
      <input />
      <input />
   </div>
</div>
```
Avec la marque ci-dessus, vous pouvez obtenir une très grande flexibilité des formes, je ne vais pas poster le CSS car il est très similaire à un 2 Colonnes de Mise en page.

J'ai encore besoin de s'asseoir et essayer de comprendre si pur CSS les formulaires sont viables pour toutes les occasions mais tbh il est très peu probable!

Formes sont la pire chose pour un style à l'aide de CSS. La seule grande Croix Navigateur problèmes que j'ai eu sont quand à la coiffure de la FieldSet et Legend éléments. Pas de réel hacks, mais ils prennent un peu de travail pour bien paraître.
- Comment cela va aligner les étiquettes?
- Vous flottent à l'étiquette de gauche, régler l'affichage de inline-block, puis ajouter une largeur fixe. La préférence a besoin d'une classe sur elle pour la rendre plus facile à cibler en CSS, mais le minimum pour que la classe soit une marge à gauche égale à la largeur de l'étiquette. Le "champ de formulaire" classe aurait overflow:hidden pour assurer la flotte sont effacés, et la forme-intrants permettrait de le modifier légèrement pour de multiples domaines. Cheers
- Ce n'est pas une réponse à la Fpo question, car cela exige une largeur fixe pour l'étiquette. Il écrit: "Et oui, je suis à la recherche pour le redimensionnement automatique des étiquettes"
InformationsquelleAutor Mig
0

Un problème avec les tables de la bug espace. Lorsque vous n'utilisez pas de tables, vous pouvez écrire votre étiquette et entrée comme ceci:
```
<label for="foo">Blah <input id="foo" type="text"/></label>
```
qui encapsule l'entrée et de l'étiquette.

Dans un tableau, sur l'autre main, vous êtes de ceux qui sont séparés:
```
<td><label for="foo">Blah</label></td><td><input id="foo" type="text"/></td>
```
Cela signifie que la zone entre le </label> et le <input/> ne répond pas aux clics de la souris.

C'est pas trop mal avec plaine de champs, c'est vraiment ennuyeux avec des boutons radio et des cases à cocher si (ou peut-être que je vais être super pointilleux.)

Maintenant, pour répondre à votre question: je ne pense pas qu'il y est une bonne façon de faire de la mise en forme d'une colonne dans le CSS (à moins que la largeur de la colonne est connu--vous pourriez obtenir que feat avec JavaScript...) Afin de T. J. Crowder a certainement une excellente réponse.

Cependant, il y a un argument pour le CSS (et forcé de largeur) que dans un cas, j'ai créé une très grande forme qui a couvert la totalité de l'écran. Tous les champs apparaissent dans un seul écran (Que le client voulait) et le CMS n'a pas de sortie d'une table. Mais même si, une table aurait été un cauchemar, tout simplement parce que tous les champs ont été pendant de nombreuses placé en non-alignés en colonnes. Qu'il serait assez difficile avec une table (beaucoup de rowspan à l'aide de la table comme une grille qui seraient un tableau pour la mise en page!).

Mise à jour:

Comme par commentaire ci-dessous, singe31 dit que <input/> ne peut pas être définie à l'intérieur de la <label> tag. Ce qui est faux. Le DTD HTML 4.01 est facile à lire et nous voyons que:
```
<!ELEMENT LABEL - - (%inline;)* -(LABEL) -- form field label text -->
<!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">
<!ENTITY % formctrl "INPUT | SELECT | TEXTAREA | LABEL | BUTTON">
```
Donc, en d'autres termes, une <input/> peuvent apparaître dans un <label> tag. Il est parfaitement légal.

HTML 5 montre clairement que c'est légal dans la documentation sur le w3c ici:

http://www.w3.org/html/wg/drafts/html/master/forms.html#the-label-element

Descendez un peu jusqu'à la "Exemple de Code" et vous voyez:

Exemple De Code

Par exemple, sur les plates-formes où cliquant ou en appuyant sur une case label vérifie la case, en cliquant ou en appuyant sur l'étiquette dans l'extrait de code suivant pourrait déclencher l'agent de l'utilisateur pour exécuter synthétique cliquez étapes d'activation sur l'élément d'entrée, comme si l'élément lui-même avait été déclenchée par l'utilisateur:

<label><input type=checkbox name=lost> Lost</label>

Sur d'autres plates-formes, le comportement peut être juste pour se concentrer le contrôle, ou ne rien faire.
- <input> ne devrait pas être dans le <label> au premier abord. Avant ou après, jamais à l'intérieur
InformationsquelleAutor Alexis Wilke

Vous devez vous connecter pour publier un commentaire.

CSS Tableau d'Affichage

Exemple De Code