This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The dt and dd elements were defined for use with a dl (Definition List) in HTML 4. In addition, the HTML 4 also recommended the use of the dl element, and dt and dd for use in dialogue. The elements have had broad implementation. In HTML5, both elements have been redefined, in order to include them in both the Figure element and the Details element. If elements maintained the same semantics in both circumstances, such reuse might be more meaningful, but they're not. As noted in the HTML5 specification, a dt element is the name of a term, in dl, a caption, in Figure, and the summary in details. As another bug notes (http://www.w3.org/Bugs/Public/show_bug.cgi?id=7629), formatting doesn't remain the same between uses either. The same conflicting semantics applies to the dd element. It's defined as a description or definition, in dl, as the "data" in a figure, and as details in a details element. In addition, you can have many sets of dt/dd within a dl element, which doesn't make sense within a figure, or within details. Seemingly the only reason for reuse is keyboard access, which is not a "semantic" choice, but a choice of convenience. Though we want to avoid creating new elements, it's preferable to confusing the semantics of an existing element, to the point where the use will more likely cause confusion than not. People will look at how dt/dd are used in dl, and assume the use can be the same for Figure, and Details, and vice versa. Other options should be explored for Figure and Details.
An unbelievably large number of options have been explored over the past 6 years. I don't buy that these elements are that confusing. In all three cases, these elements mean roughly the same thing <dt> is the label for something else, and <dd> is the something else.
"I don't buy that these elements are that confusing. In all three cases, these elements mean roughly the same thing <dt> is the label for something else, and <dd> is the something else." I find it amazing that the same person who argues so strenuously for the needs of both section and article, is the same person who just wrote that. If it is so important to have both a section and an article, because they semantically mean different things (and have different behaviors), than how much more so is it an error to use dt/dd in such a chaotic and messy manner. The use of dt/dd were added only recently, before that other HTML elements were 're-used', and to the same ill effect. You can't say one is label for the other, when you allow only dt in some cases, only dd in other cases, and an add mix of both in yet other cases. Worse, when authors see how dt/dd are used in Figure, they will parrot such use in Details, which will then cause confusion, and perhaps odd results. The same with dl -- such redefinition is badly done, a grasping at straws, rather than a thoughtful response. However, since the HTML5 author is indifferent to web page authors, developers, and designers, new evidence has surfaced that this approach is not backwards compatible with browses, either [1]. [1] http://lists.w3.org/Archives/Public/public-html/2009Sep/0780.html
As Shelley pointed out with her link to the mailing list, IE6 and IE7 will generate non-tree DOMs when they encounter <dt> or <dd> outside of <dl>. This issue cannot be easily gotten rid of with a simple JS hack, like you can do with the other new elements. However, it *is* possible to (as far as we know) safely force IE6 and IE7 to generate a tree DOM of the expected shape by using a conditional comment to insert an empty <object> element. I have no idea whether this has additional ill effects. While I don't expect to be able to depend on <details> being natively implemented for years yet, I *do* want to be able to slide in appropriate functionality via javascript until then (with a quick feature-test to seamlessly allow native implementations when they exist). I can't do this for IE6 and IE7 if they generate bad DOMs, and I don't want to have to carry around a markup talisman to force it into working correctly - using a single js file to hack things into shape is bad enough.
Well, these two features aren't anywhere near important enough to justify a whole new set of elements, IMHO; even introducing <details> and <figure> is somewhat pushing it. As far as the semantic argument, personally I don't understand the problem. Prior to HTML5, <dt> and <dd> had meaning inside <dl> only. These elements are meaningless outside <dl>, so why can't we introduce new meaning to these elements in new contexts? Furthermore, the new meanings are so close to the old meanings, that I really don't see an issue. If you disagree, please escalate this to the chairs. As far as the compatibility argument, as I see it we have three options: 1. Use <dt>/<dd> and have people continue to use <div>s while we wait for 25% of today's browsers to be replaced with the current generation of browsers. 2. Use <legend> and have people continue to use <div>s while we wait for browsers to implement the HTML parser and for 100% of today's browsers to be replaced with that new generation of browsers. 3. Not have these two features and have people continue to use <div>s. Currently the spec picks 1. If you disagree, please escalate this to the chairs.
You neglected to reference the other issues associated with dt/dd, including the fact that the different syntactic requirements for dt/dd based on container is going to lead to confusion about which is the proper use of the elements based on which container. Your only reason for picking these is because there was no physical reason for not using them: not because they were a superior option, not because there was any real logic for using the elements, and not because it was the best solution for the future. It was a slap dash grab at something, anything. Yes, this needs to be escalated to an issue.
And per this IRC entry, note to co-chair: I have listed concerns that are beyond "philosophy" http://krijnhoetmer.nl/irc-logs/whatwg/20090929#l-258
escalated to tracker: http://www.w3.org/html/wg/tracker/issues/83
Even though there is an Issue on this item, I want this bug kept open, as this is the only way I can record links or other new information associated with both bug and issue. There is a discussion on dt/dd in the WhatWG pertinent to this topic. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023276.html I would be happy to "close" this bug, if I can add information to the Issue. Only HTML WG members can add information to the an issue.
There's two ways anyone can add information to the escalated issue with this bug in "resolved" state: 1) Leave comments on this bug, since it is linked from the issue, and so the information will not get lost. 2) Send mail to the public-html mailing list with ISSUE-83 in the subject line or body, and the issue tracker will link it to the issue automatically.
The associated Tracker issue for this, issue-83, remains open pending resolution by the HTML WG. If that resolution ends up being something that requires a change to the spec (e.g., if the resolution is that <dt> and <dd> should not be repurposed for the <figure> and <details> element), then this bug will be reopened with a instructions to the editor to make whatever change the group decides on. I've updated the Description field of issue-83 with links to this bug and to bug 7669.
This item was fixed as part of the resolution process.
*** Bug 8246 has been marked as a duplicate of this bug. ***