Pourquoi utiliser des balises de listes de définitions (DL, DD, DT) pour les formulaires HTML au lieu de tableaux?

J'ai récemment rencontré quelques exemples qui font des choses comme:

<dl>
  <dt>Full Name:</dt>
  <dd><input type="text" name="fullname"></dd>
  <dt>Email Address:</dt>
  <dd><input type="text" name="email"></dd>
</dl>

pour faire des formulaires HTML. Pourquoi donc? Quel est l'avantage par rapport à l'utilisation de tables?

Je suppose que c'est à vous de déterminer la sémantique, mais à mon avis:

Plutôt qu'une liste de définitions, des propriétés liées au formulaire doivent être utilisées.

<form>
  <label for="fullname">Full Name:</label>
  <input type="text" name="fullname" id="fullname">
  <label for="email">Email Address:</label>
  <input type="text" name="email" id="email">
</form>

L'attribut "for" dans la balise <label> doit faire référence à l'attribut "id" d'une balise <input>. Notez que lorsque des étiquettes sont associées à des champs, cliquer sur l'étiquette mettra le champ associé en évidence.

Vous pouvez également utiliser des balises telles que <fieldset> pour regrouper les sections d'un formulaire et <legend> pour sous-titrer un fieldset.

J'ai utilisé avec succès la technique décrite dans cet article à plusieurs reprises.

Je suis d'accord avec sjstrutt pour dire que vous devriez utiliser des balises liées au formulaire comme labelet formdans vos formulaires, mais le code HTML décrit dans son exemple manquera souvent de code que vous pouvez utiliser comme "hooks" pour styliser votre formulaire avec CSS.

En conséquence, je marque mes formulaires comme ceci:

<form name="LoginForm" action="thispage">
    <fieldset>
        <legend>Form header</legend>
        <ul>
            <li>
                <label for="UserName">Username: </label>
                <input id="UserName" name="UserName" type="text" />
            </li>
            <li>
                <label for="Password">Password: </label>
                <input id="Password" name="Password" type="text" />
            </li>
        </ul>
    </fieldset>
    <fieldset class="buttons">
        <input class="submit" type="submit" value="Login" />
    </fieldset>
</form>

Cette approche me laisse avec un ensemble compréhensible de balises, qui contient suffisamment de crochets pour styliser les formulaires de différentes manières.

Il s'agit d'un sous-ensemble du problème de la sémantique par rapport au formatage. Une liste de définitions dit ce qu'ils sont, une liste d'attributs clé / valeur associés, mais ne dit pas comment l'afficher. Un tableau en dit plus sur la disposition et la façon d'afficher les données, puis sur les données à l'intérieur. Il limite la façon dont la liste peut être formatée à la fois en surspécifiant le format et en sous-spécifiant de quoi il s'agit.

Le HTML, historiquement, a mélangé la sémantique avec le formatage. Les balises de polices et les tableaux sont les pires exemples. Le passage au CSS pour la mise en forme et la suppression de nombreuses balises de mise en forme pure hors du XHTML restaure, en quelque sorte, la séparation du sens et du formatage. En séparant le formatage en CSS, vous pouvez afficher le même HTML de différentes manières en le reformatant pour un navigateur large, un petit navigateur mobile, une impression, du texte brut, etc.

Pour vous éclairer, visitez le CSS Zen Garden .

Dans ce cas, les étiquettes et les entrées sont votre signification sémantique et elles sont autonomes.

Imaginez que vous deviez lire la page Web, hors de charge, à une personne aveugle. Vous ne diriez pas "D'accord, j'ai une liste de définitions ici. Le premier terme est" nom "." Au lieu de cela, vous diriez probablement "Ok, nous avons un formulaire ici et il semble qu'il y ait un ensemble de champs , la première entrée est étiquetée " nom "."

C'est pourquoi le web sémantique est important. Il permet au contenu de la page de se représenter avec précision aux humains et à la technologie. Par exemple, il existe de nombreux plugins de navigateur qui aident les gens à remplir rapidement des formulaires Web avec leurs informations standard (nom, numéro de téléphone, etc.). Ceux-ci fonctionnent rarement bien si les entrées n'ont pas d'étiquettes associées.

J'espère que ça t'as aidé.

L' utilisation dl dt, ddainsi que des formes est juste une autre façon de structurer vos formes, ul li, divet table. Vous pouvez toujours mettre un labeldans dt. De cette façon, vous gardez l'élément spécifique au formulaire labelen place.

<form action="/login" method="post"> 
    <dl>
        <dt><label for="login">Login</label></dt>
        <dd><input type="text" name="login" id="login"/></dd>
        <dt><label for="password">Password</label></dt>
        <dd><input type="password" name="password" id="password"/></dd>  
        <dd><input type="submit" value="Add"/></dd>
    </dl>
</form>

Les listes de définitions ont une signification sémantique. Ils servent à lister les termes (<dt>) et leurs définitions associées (<dd>). Par conséquent, dans ce cas, un <dl> décrit la signification sémantique du contenu avec plus de précision qu'une table.

Les listes de définitions ne sont presque jamais utilisées car, sémantiquement parlant, elles apparaissent rarement sur Internet.

Dans votre cas, le code correct a été affiché:

<form>
    <label for="fullname">Full Name:</label>
    <input type="text" name="fullname" id="fullname">
    <label for="email">Email Address:</label>
    <input type="text" name="email" id="email">
</form>

Vous créez un formulaire avec des entrées et des étiquettes pour lesdites entrées, vous ne définissez pas une liste de mots et ne les définissez pas.

Si vous faites une sorte de section d'aide, des listes de définitions seraient appropriées, par exemple:

<dl>
    <dt>HTML</dt>
    <dd>Hypertext Markup Language</dd>
    <dt>CSS</dt>
    <dd>Cascade Stylesheets</dd>
    <dt>PHP</dt>
    <dd>Hypertext Preprocessor</dd>
</dl>

Une partie de la raison d'utiliser <dl> pour baliser le formulaire est qu'il est beaucoup plus facile de faire des astuces de mise en page CSS avec un <dl> qu'avec une <table>. L'autre partie est qu'il reflète mieux la sémantique du formulaire (une liste de paires étiquette / champ) qu'un tableau.

Ok, la haine de table en fait également partie.

Parfois, une liste de définitions présente simplement les informations de la manière souhaitée, contrairement à un tableau. Personnellement, je n'utiliserais probablement pas de liste de définitions pour un formulaire, sauf si cela convient au style du site.

Pratiquement tous les formulaires sont tabulaires. Avez-vous déjà vu un formulaire qui n'est pas tabulaire? Les directives que j'ai lues suggèrent d'utiliser la balise table pour une présentation tabulaire et c'est exactement à quoi servent les formulaires, les calendriers et les feuilles de calcul. Et maintenant, ils utilisent DD et DT au lieu de tables? À quoi le Web arrive-t-il?! :)

Les données de la liste de table seront comme ceci:

<table>
<tr>
	<td class="title">Name: </td>
	<td class="text">John Don</td>
</tr>
<tr>
	<td class="title">Age: </td>
	<td class="text">23</td>
</tr>
<tr>
	<td class="title">Gender: </td>
	<td class="text">Male</td>
</tr>
<tr>
	<td class="title">Day of Birth:</td>
	<td class="text">12th May 1986</td>
</tr>
</table>

Et vous pouvez utiliser les données de liste de balises DL, DT, DD comme ceci:

<dl>
	<dt>Name: </dt>
	<dd>John Don</dd>
	
	<dt>Age: </dt>
	<dd>23</dd>
	
	<dt>Gender: </dt>
	<dd>Male</dd>
	
	<dt>Day of Birth:</dt>
	<dd>12th May 1986</dd>
</dl>