为啥对 HTML 表单而不是表格使用定义列表（DL、DD、DT）标签？

Posted 2023-03-05

【中文标题】为啥对 HTML 表单而不是表格使用定义列表（DL、DD、DT）标签？

【英文标题】：Why use definition lists (DL,DD,DT) tags for HTML forms instead of tables?为什么对 HTML 表单而不是表格使用定义列表（DL、DD、DT）标签？

【发布时间】：2010-10-05 21:01:41

【问题描述】：

我最近遇到了一些例子，它们的作用如下：

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

用于制作 html 表单。这是为什么？与使用表格相比有什么优势？

【问题讨论】：

您选择的答案是完全无效的标记：表单上缺少“action”、“method”，您不能在其中放置 lebel 和 input。该示例还将显示在一行上，因为没有 标记（这可能不是本意）。就语义而言，除了无效的代码也是代码汤。在这种情况下，定义列表和表在语义上是等效的。不同之处在于代码量，dl 要短得多：pastie.org/1090219 而使用表需要多个表才能工作，这很尴尬：pastie.org/1090229（续...）

如果你不关心语义，这是如何让它既有效又避免使用 id：pastie.org/1090225

srcspider，方法是必需的，从技术上讲，根据浏览器，action 将默认为 self.答案的格式都是用 CSS 完成的。你不应该需要任何<br />'s。这完全取决于您希望如何设计代码

为什么是 javascript（或 CSS）标签？现在这个页面的标题以javascript - 开头...

【参考方案1】：

表格列表数据会是这样的：

<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>

您可以像这样使用 DL、DT、DD 标签列表数据：

<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>

【讨论】：

感谢您的链接，但最好在此处也包含代码，因为该链接可能会在某个时刻过期。顺便说一句，这个例子夸大了差异，因为他们本可以使用<th/> 元素作为标签......

【参考方案2】：

我已经多次成功使用this article 中概述的技术。

我同意 sjstrutt 的观点，即您应该在表单中使用与表单相关的标签，例如 label 和 form，但是他的示例中概述的 HTML 通常会缺少一些您可以用作使用 CSS 设置表单样式的“钩子”。

因此，我这样标记我的表单：

<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>

这种方法给我留下了一组易于理解的标签，其中包含足够多的钩子以多种不同的方式设置表单样式。

【讨论】：

我发现这种方法的唯一问题是有时您需要将内容放在两个都不相关的表单元素之间。从语义上讲，您应该关闭无序列表并重新开始，但是您可能会得到一个仅包含一个子元素的列表。

复选框列表呢，你会把它放在哪里？

@msony 在<li> 中，就像其他输入一样。

嗯？如果您需要挂钩，请使用 div。这就是他们的目的。语义很棒（应该使用！）但是当您需要样式的锚时，最好使用没有语义的 span 或 div。一个 div 是一个盒子，应该这样使用。

如果我认为我的表单是一个带有图例的字段集的集合，每个字段集都包含一个带有或不带有标签的输入字段列表，那么上面的 html 不会产生完美的语义含义。此外，它还有一个额外的好处是不需要额外的类名来格式化。

【参考方案3】：

将dldt,dd 用于表单只是构造表单的另一种方式，以及ulli、div 和table。您可以随时将label 放入dt。这样您就可以将表单特定元素 label 保留在适当的位置。

<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>

【讨论】：

您的示例违反规范，因为您的提交按钮属于密码 dt。您有多个 dd 属于单个 dt，这就是您在这里所做的。我会将提交按钮完全放在 dl 下方，因为 dl 仅适用于名称-值组，而不是像提交按钮那样独立存在的元素。

我认为这不违反规范。您可以根据需要对每个术语进行尽可能多的描述（反之亦然）w3.org/TR/html401/struct/lists.html#h-10.3 但您是对的，提交按钮应该从密码定义中移出。

提交只是不必在dl上。它不是一个输入元素（语义上）而是一个动作元素。

太棒了！那是最灵活和符合标准的解决方案。仅使用标签和输入来设置表单样式确实很难，但是使用

@Eduardo Cobuci：+1 事实上，这是迄今为止最好的方法。语义上几乎没问题，我们能够更恰当地设置它的样式。我还可以添加一个 fieldset 元素。

【参考方案4】：

几乎从不使用定义列表，因为从语义上讲，它们很少出现在互联网上。

在您的情况下，已发布正确的代码：

<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>

您正在为所述输入创建一个带有输入和标签的表单，而不是列出单词列表并定义它们。

如果您正在做某种帮助部分，那么定义列表将是合适的，例如：

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

【讨论】：

术语：名字定义：请在提供的框中提供一个。

对不起。如果您将术语（dt）视为“名字”、“姓氏”等，则可以将定义（dd）视为由用户提供。

【参考方案5】：

我想这取决于你来确定语义，但在我看来：

应该使用与表单相关的属性，而不是定义列表。

<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>

标签中的“for”属性应该引用 标签的“id”属性。请注意，当标签与字段关联时，单击标签将使关联的字段成为焦点。

您还可以使用

等标签将表单的各个部分聚集在一起，并使用

为字段集添加标题。

【讨论】：

你也可以把输入放在标签里面

+1 是唯一一个建议这样做的合乎逻辑的人。从布局的角度来看，“表格”通常在语义上不准确或非常灵活。 “定义列表”更接近，但仍然有点牵强。但是“输入”和“标签”呢？事情就是这样！

对于很多表格，我相信表格/可能/在语义上是合适的。但并非在所有情况下。正如 Chuck 所说，从布局的角度来看，表格并不是很灵活。如果您要在表单中使用表格，请确保它在语义上是合适的，并确保也使用标签。

nickf: 是的，但是不嵌套它们更灵活，因为您可以执行 labeldisplay:block; 来获取字段上方的标签，或者 labelclear:both;float: left;width:300px; 以获得表格外观。

svinto：你的第二个例子是我通常使用的方法。问题是您的标签宽度受到限制；添加长标签或增加文本大小可能会导致不需要的结果，而这正是表格解决方案实际上更灵活的地方。

【参考方案6】：

几乎所有的表格都是表格的。你见过不是表格的表格吗？我读过的指南建议使用表格标签进行表格展示，而这正是表格、日历和电子表格的用途。现在他们使用 DD 和 DT 而不是表？网络是什么来的？！ :)

【讨论】：

我认为这是桌面恐惧症的例子；) 我已经看到由嵌套的 <ul> 和 <ol> 组成的表格数据使用大量 CSS 样式，只是因为 表格是邪恶的.

或者，因为 和

【参考方案7】：

在这种情况下，标签和输入是您的语义含义，它们独立存在。

想象一下，您必须阅读网页，将网页加载给盲人。您不会说“好的，我在这里有一个定义列表。第一个术语是'名称'。”相反，您可能会说“好的，我们这里有一个 form，看起来有一个 字段集，第一个 input 是标记“名字”。”

这就是语义网很重要的原因。它允许页面的内容准确地向人类和技术展示自身。例如，manybrowserplugins 可以帮助人们使用标准信息（姓名、电话号码等）快速填写 Web 表单。如果输入没有关联的标签，这些很少能很好地工作。

希望对您有所帮助。

【参考方案8】：

有时，定义列表只是以所需的方式呈现信息，而表格则不然。就个人而言，我可能不会对表单使用定义列表，除非它适合网站的风格。

【参考方案9】：

使用

来标记表单的部分原因是使用

比 更容易做花哨的 CSS 布局技巧。另一部分是它比表格更能反映表单的语义（标签/字段对列表）。

好吧，餐桌仇恨也是其中的一部分。

【讨论】：

【参考方案10】：

这是语义与格式问题的一个子集。定义列表说明了它们是什么，相关键/值属性的列表，但没有说明如何显示它。一张表更多地说明了布局以及如何显示数据，然后是里面的数据。它通过过度指定格式和未指定格式来限制列表的格式。

HTML 在历史上一直将语义与格式混为一谈。字体标签和表格是最糟糕的例子。转向 CSS 进行格式化以及从 XHTML 中去除大量纯格式化标签在某种程度上恢复了含义与格式化的分离。通过将格式分离为 CSS，您可以以多种不同的方式显示相同的 HTML，为宽浏览器、小型移动浏览器、打印、纯文本等重新格式化...

如需启蒙，请访问CSS Zen Garden。

【讨论】：

我要补充的是，它增加了意图、关系。稍后，搜索引擎可以使用此页面并发现上面的代码并知道它们都是相关的。

dl 对我来说奇怪的是它依赖于标签的顺序来传达术语与其定义之间的关系。

【参考方案11】：

定义列表具有语义含义。它们用于列出术语 (

) 及其相关定义 ( )。因此，在这种情况下，

比表格更准确地描述了内容的语义。

【讨论】：

或更少，因为大多数表单不要求定义术语（而表是通用元组关系）。

我不同意你的观点大卫，当一个表格有一个输入让你填写你的名字时，它会询问“你的名字是什么”，所以“定义你的名字”是完全有效的，因此 dt>firstname dd>您的输入。当然，定义有一个上下文，你。

正确使用的input 和label 标签已经是明确的，并且将它们包装在定义列表中充其量是重言式。就像短语“语义”一样:)

@IanMackinnon 同意第一部分，但“语义”特指元素本身之外的意义（更接近“字面意义”）