W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: what is dt?

From: Shelley Powers <shelleyp@burningbird.net>
Date: Thu, 17 Sep 2009 08:02:42 -0500
Message-ID: <4AB23372.4010101@burningbird.net>
To: Maciej Stachowiak <mjs@apple.com>
CC: Smylers@stripey.com, public-html@w3.org
Maciej Stachowiak wrote:
> Hi Shelley,
> On Sep 16, 2009, at 9:17 PM, Shelley Powers wrote:
>> We keep referencing the importance of semantics, but most of the 
>> considerations about elements to use for Figure and Details have been 
>> based on some physical characteristic or behavior. Physical 
>> characteristics and behaviors, I should add, that came about because 
>> of earlier, non-compatible semantics.
> That's exactly right - the other plausible existing elements are ruled 
> out because of their pre-existing use and behavior. I don't have a 
> strong opinion on <dt> vs. a new element - as far as I'm concerned, 
> either is acceptable. All I wanted to do is clarify why <caption>, 
> <label>, or other similar elements, are not an option for technical 
> reasons that go beyond aesthetics.

Actually, label has been found to be acceptable for use with Figure. 
Even preferable because it is a "caption".

> I think you're making the case below that for reasons of taste and 
> language design, dt/dd is not a good choice, perhaps worse than making 
> up a new element. Would that be a fair assessment of your viewpoint? 
> Do you think there would be downsides to creating one or more new 
> elements for <figure> and <details>?
No, I don't believe I stated my argument in terms of "taste" or any 
"personal" preference.

The specification now lists three different ways that dt/dd can be used, 
and each has its own peculiar usage. I could easily imagine someone 
seeing how dt/dd are used in definition list, and think that the same 
type of usage would also apply to its use in Figure. And vice versa.

We're adding a layer of significant confusion, because the elements 
really are not treated the same in all cases. We're doing so based on 
how browsers implement behavior for these elements _today_, even though 
the elements are being redefined for browser use _tomorrow_.

There was no semantic reason for it, it was purely convenience, which is 
not a particularly good reason to introduce such confusion.

>> What has happened is that we've sifted through the various elements 
>> and found the ones that don't have any browser behavior attached that 
>> would make them incompatible. We then attach semantics that changes 
>> based on container, formatting that will have to change based on 
>> container, and even occurrence that will change based on container.
>> Where now, there is no real conflict about how dt/dd is used within 
>> the dl element, we've introduced confusion. A very significant 
>> confusion.
>> The use of dl/dt/dd is no longer encouraged for dialogues, because 
>> we've heard, there is no inherent order to the dt/dd elements in a 
>> definition list. Yet we've made rules that there can be many dt/dd 
>> pairs in a dl container, but only one pair in a Figure, and I'm not 
>> quite sure how they work in Details yet. The first is a dt, the last 
>> child a dd, and I guess we can assume there is the possibility of 
>> millions of pairs in between. Which really confuses the heck out of 
>> what Details is.
> One side note: multiple <dt>/<dd> pairs inside <figure> or <details> 
> create the same kinds of issues as multiple <legend>s would have under 
> the older approach. Either way, multiple labels are disallowed, but 
> UAs must somehow cope. The only new issue is the comparison to <dl>.
Again, though, we're making decisions based on how browsers implement 
these elements _today_ for elements being redefined for use _tomorrow_.

It would be understandable if we were "paving a cow path" or somehow 
standardizing on widespread usage. But the one case, outside of 
definition lists, where there _is_ widespread usage of dt/dd (and within 
dl), has actually been labeled in such a way as to discourage its use. 
So the argument for dt/dd in Figure, really is expediency, rather than 
reason, or semantics.

And I do not believe that those who took such an expedient approach 
stopped to think about how the rather significant differences in how 
dt/dd can be used within each of the different containers will cause 
confusion for those trying to work through the rather arcane rules 
governing their use.

Received on Thursday, 17 September 2009 13:03:26 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:51 UTC