Re: what is dt?

On Sep 17, 2009, at 6:02 AM, Shelley Powers wrote:

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

Found by whom? Do you personally think it is acceptable? Did you see  
the list of problems I cited for <label>? Do you disagree that these  
are problems? Quoting myself from before:

>> label:
>> - Is associated as the label for any controls inside it; probably  
>> not a big deal for <details>, but it's totally plausible to have  
>> checkboxes, radio buttons, text fields or other form controls in  
>> the caption of a <figure>. Think about the flickr UI for editing a  
>> photo caption, or sites like "Am I hot or not", or a UI to check  
>> the photos you like best out of a set.
>> - Cannot ever receive keyboard focus; this is more of a problem for  
>> <details> than for <figure>, since it is an interactive element.
>> - Apparently, a fair number of pages have existing style rules for  
>> "label" that are not further qualified, intending them only for  
>> form control purposes. Adding a <figure> or <details> to such a  
>> page would cause styling oddities in the caption, unless all  
>> existing label CSS rules are changed to qualify them further.

I believe the Superfriends were not aware of all of these issues when  
they made their proposal.


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

What you say below is something I'd consider a question of design  
taste. That doesn't mean it's unimportant. Design taste an important  
consideration in designing a language. But I want to keep language  
design questions separate from issues that cause concrete technical  
problems, because they tend to be more subjective.

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