Re: what is dt?

Maciej Stachowiak wrote:
>
> 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?

I don't personally have any stake with re-using label. I actually don't 
like redefining elements, which is antithetical when discussed in 
relation to semantics, so I'm not going to stand up in defense of label, 
as I noted in other emails in this thread.

> 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.
>
>
Well, I disagree with your assumption of the plausibility of putting 
form elements in a figure caption, not unless your idea of figure and 
caption differs extremely from my idea of figure and caption.

I believe that Flickr currently uses a hidden page object to handle 
editing in place. That's pretty standard for editing in place behavior. 
It would not be the same element as the figure caption. It would be a 
different element.

Again, we have mentioned about separating discussion of Details and 
Figure. The use of label and not having keyboard access for Figure is 
not a problem.

Style issues have, again, been rejected as a sole reason for any 
decision: we assume people can add new CSS rules to handle the new use 
of new elements.

In fact, we have to assume that web page authors will be adding new CSS 
rules for Figures anyway.


>>
>>> 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.
>
Sorry, I don't agree with how this argument is being re-framed.

Laura quoted something in another email, which I don't think ended up 
going to this group:

3.2 Priority of Constituencies
"In case of conflict, consider users over authors over implementors
over specifiers over theoretical purity. In other words costs or
difficulties to the user should be given more weight than costs to
authors; which in turn should be given more weight than costs to
implementors; which should be given more weight than costs to authors
of the spec itself, which should be given more weight than those
proposing changes for theoretical reasons alone. Of course, it is


preferred to make things better for multiple constituencies at once."
http://dev.w3.org/html5/html-design-principles/Overview.html#priority-of-constituencies

--

We are assuming that it is acceptable to place the burden of adaption on web page authors, because referring to problems that web page authors may incur is not inherently a "technical issue".

That is not only an error, it goes counter to the Design Principles that seemingly guide this group, and counter to every known principle of user design that has ever existed. 

Technical issues are a concern yes. But they are not the only concerns, and should not be the overriding purpose of this group.

I can understand the issues of legacy browsers, but once a solution is found to satisfy legacy browsers, doesn't mean the job is done. The solution must also work for web page authors. 


I have stated that dt/dd will not work for web page authors, and have my 
arguments for such an opinion. This is no different than anyone else 
saying such and such won't work because legacy browsers will crap out. 
Both are describing a point of potential failure, and deserve to be 
respected for such.

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

Received on Thursday, 17 September 2009 17:48:13 UTC