Proposal to include <di>-like element

[Sander Aarts]

In the proposal for XHTML 2 there is this new element for grouping <dt>'s and <dd>'s in a <dl>: <di> (optional). I think the structure of a <dl> can gain a lot with an element like this:

Code: Select all

<dl>
   <di>
      <dt>...</dt>
      <dd>...</dd>
   </di>
   <di>
      <dt>...</dt>
      <dd>...</dd>
      <dd>...</dd>
   </di>
</dl>

It might even be usable to make sections in a <dialog>:

Code: Select all

<dialog>
   <di>
      <dt>...</dt>
      <dd>...</dd>
      <dt>...</dt>
      <dd>...</dd>
      <dt>...</dt>
      <dd>...</dd>
   </di>
   <di class="thinking">
      <dt>...</dt>
      <dd>...</dd>
   </di>
   <di>
      <dt>...</dt>
      <dd>...</dd>
      <dt>...</dt>
      <dd>...</dd>
      <dt>...</dt>
      <dd>...</dd>
   </di>
</dialog>

For developers the possibility of explicit grouping can be of great help too. Layout and/or behaviour that is applied to <dl>'s often refers to this (implied) grouping. For instance an FAQ list with unfoldable answers.

I hope <di> or something like it will be implemented in the HTML 5 specifications.

Description of <di> in XHTML 2 working draft

[Cerbera]

The problem with that is current versions of IE treat unrecognised elements rather badly. I don't think CSS properties would be applied to <di> in IE7 or lower Much like how CSS doesn't get applied to <abbr> in IE6 and lower. So that technique wouldn't be backwards compatible.

Not sure if scripting would work on it...the DOM tends to look pretty scrambled for unrecognised elements in IE.

In the dialogue example, one <di> is containing many <dt>+<dd> groups (let's call them definition items). Since the <di> element looks like it means "Definition Item" I think it should only contain one definition item or be given a different name.

[Sander Aarts]

The problem with that is current versions of IE treat unrecognised elements rather badly. ...<snip>... So that technique wouldn't be backwards compatible.

Personally I coudn't care less about IE at the moment. It has slowed down progress for way too long.
But you're right. Let's call this list a <dfl> (or anything else) then if adding totally new elements is less of a problem than adding new 'sub elements' to existing ones.

In the dialogue example, one <di> is containing many <dt>+<dd> groups (let's call them definition items). Since the <di> element looks like it means "Definition Item" I think it should only contain one definition item or be given a different name.

In a definition list it would be a definition item, in a dialog a dialog item I guess. The number of <dt>'s and <dd>'s should be free (which is already the case in the current implicit grouping): more terms can have the same definition, but one term can also have more definitions.
In dialogs, dialog items could be used for dividing a dialog in different parts, for instance because the subject changes, or there is a flashback of an earlier conversation, a telephone call intervenes, the conversation changes to whispering or singing (in a musical), whatever . Anyway, during dialogs things can change and therefore parts of such a dialog can be grouped.
Then again, this <di>-tag can be optional I think (as in the XHTML 2 specs), especialy for <dialog>. I certainly do miss it in the current <dl> though.


Another positive thing about the <di> could be that it may allow swapping the order of <dt>'s and <dd>'s:

Code: Select all

<di>
   <dd>Capital of the Netherlands.</dd>
   <dt>Amsterdam</dt>
</di>

This could be handy.

[Cerbera]

But you're right. Let's call this list a <dfl> (or anything else) then if adding totally new elements is less of a problem than adding new 'sub elements' to existing ones.

You were saying <di> would be helpful for CSS layout. But this won't be backwards compatible because of IE, which you seemed to agree with. How would <dfl> make CSS layout work in IE? AFAIK, it would still be treated as an unrecognised element.

[Sander Aarts]

But what is HTML5 all about then if we can't add new elements to the HTML-repertoire? How do you look at <canvas> or <dialog> in this context?

I thought giving this new and improved defenition list a new tagit might be less of a problem than altering the existing one. If that is the case then let's make a new definition list. If not, lets' alter the current one.

I guess altering is not really a problem as I see what kind of changes form elements are undergoing in the development of HTML 5.


But maybe I just don't comprehend this whole backward compatibility thing here . So please explain it to me if you think I'm totally on the wrong track.

[Cerbera]

Layout and/or behaviour that is applied to <dl>'s often refers to this (implied) grouping. For instance an FAQ list with unfoldable answers.

I hope <di> or something like it will be implemented in the HTML 5 specifications.

This made me think a main reason for your <di> idea was so authors could use it for styling. But since this won't work in two commonly used browsers (IE6 and IE7) so it won't be as useful as you might want. It would work in HTML5 UAs though, so it could become more useful in the future.

In the <dl> example, <di> doesn't seem to add any semantic value because the association of <dt> and <dd> elements is already defined.

Perhaps this is acceptable for arbitrary grouping within definition lists:

Code: Select all

<dl>
<dd>
  <dl>
   <dt>Item 1, Term 1</dt>
   <dd>Item 1, Description 1</dd>
  </dl>
</dd>
<dd>
  <dl>
   <dt>Item 2, Term 1</dt>
   <dt>Item 2, Term 2</dt>
   <dd>Item 2, Description 1</dd>
   <dd>Item 2, Description 2</dd>
   <dt>Item 3, Term 1</dt>
   <dd>Item 3, Description 1</dd>
  </dl>
</dd>
</dl>

In the <dialog> example, I do think the <di> add semantic value. However, I think you'd hit the same styling problems in IE6 and IE7. If <dialog> elements can be nested then perhaps this would be acceptable:

Code: Select all

<dialog>
<dialog>
  <dt>Section 1, Speaker 1</dt>
  <dd>Section 1, Speech 1</dd>
  <dt>Section 1, Speaker 2</dt>
  <dd>Section 1, Speech 2</dd>
</dialog>
<dt>Section 2, Speaker 1</dt>
<dd>Section 2, Speech 1</dd>
<dialog>
  <dt>Section 3, Speaker 1</dt>
  <dd>Section 3, Speech 1</dd>
  <dt>Section 3, Speaker 2</dt>
  <dd>Section 3, Speech 2</dd>
  <dt>Section 3, Speaker 3</dt>
  <dd>Section 3, Speech 3</dd>
</dialog>
</dialog>

Perhaps you could test how current browsers handle <di> elements, nested <dialog> and other combinations? I'm not an expert.

[zcorpan]

In the <dl> example, <di> doesn't seem to add any semantic value because the association of <dt> and <dd> elements is already defined.

Indeed, and this is why, IIRC from previous discussions on the list, <di> has been deemed to be a styling problem, not a markup problem, and thus should be solved at the styling layer (i.e. CSS or XBL).

[Sander Aarts]

It has the same kind of semantic meaning as a <fieldset>, <optgroup> and a <tr>.
A <dl> is something like a simple 2-column table. The first column containing the terms and the second one the definitions/descriptions. The <di> is (should be) the <dl>'s alternative for a <tr>.

This made me think a main reason for your <di> idea was so authors could use it for styling.

The fact that an element can be of great help in adding layout and/or behaviour doesn't mean it's not semantical. A good design and good behaviour are also based on the semantics I hope. A good and logical structure (DOM) makes it easier add a meaningful layout. But it doesn't mean that that's the only purpose.

In the current tree structure of a <dl> there is just not really a logical association.

It would work in HTML5 UAs though, so it could become more useful in the future.

Isn't that the whole purpose of development?

[zcorpan]

It has the same kind of semantic meaning as a <fieldset>, <optgroup> and a <tr>.

No, it doesn't. If you removed those elements then you don't know where the grouping starts and where it ends. This is not the case with <di>, it is already defined where the groups start and where they end, without <di>, so adding <di> doesn't add anything that we didn't already know.

And hence, this is not a markup problem, but a styling problem.

[Sander Aarts]

And hence, this is not a markup problem, but a styling problem.

So, if something isn't a markup problem, it is a styling problem?

I'd say it's a very weak structure. I admit that 'problem' might be a big word, cause indeed... there is a weak, implicit kind of grouping going on. One that is only based upon an agreement, written in a DTD. But I'd like to see an explicit grouping, one that is clear from the structure (even if you'd never seen or heard about a <dl> before). Within a <di> the order of <dt>s and <dd>s doesn't have to be fixed anymore, as long as there is at least one of each. Therefore it would offer more possibilities to structure the markup in a way that fits the content best and it would offer more explicit semantics.
And indeed, it would also make it easier to add style and behaviour as an extra. I don't think that's a problem. Is it?

[zcorpan]

And hence, this is not a markup problem, but a styling problem.

So, if something isn't a markup problem, it is a styling problem?

Not implicitly, but the use-case here was to make styling easier, wasn't it?

I'd say it's a very weak structure.

It's unambigously defined.

The dl element introduces an unordered association list consisting of zero or more name-value groups (a description list). Each group must consist of one or more names (dt elements) followed by one or more values (dd elements).

-- http://www.whatwg.org/specs/web-apps/cu ... tml#the-dl

(In the same section it is also defined what it means when the content doesn't follow that rule.)

You might think that it's weak, but it's not ambigous.

Wouldn't a new pseudo-element, say ::key-value-group, solve the styling problem?

[Sander Aarts]

Not implicitly, but the use-case here was to make styling easier, wasn't it?

No, but it sure would be a nice extra ("For developers the possibility of explicit grouping can be of great help too"). Same for behaviour.

It's unambigously defined.

That's true, but for all (or most) other 'multilevel' elements like <select> and <table>and such, the DOM structure speaks for itself, unlike the <dl> where the grouping is only defined in the specs. And since we're in the proces of making things better, I'd say "let's upgrade this crippled element"

Wouldn't a new pseudo-element, say ::key-value-group, solve the styling problem?

That could be of help of course, but why not enhance the semantic value by creating a more intuitive DOM structure that shows the grouping that's now only implied (DOM-wise), and get extra means to add style and behaviour as a bonus?

[Cerbera]

The association of <dt> and <dd> elements in a <dl> has been part of HTML for a long time. HTML5 makes this association really explicit, so it's hardly a "crippled" element. A new element isn't necessary to improve the semantics of <dl>.

Allowing reversed order of terms and definitions might not be compatible with current UAs. I've read that modern screen readers can provide announcements which rely on the historic order, such as saying "equals" after each <dt>. The benefits to allowing reversed order seem marginal...float: right; or relative positioning or absolute position should enable any visual order using the historic source order?

AFAIK, scripting could loop through the descendants of <dl> to locate <dt>+<dd> groups to apply whatever behaviour was desired?. The algorithm for this is spelled out in HTML5, from what I can tell.

I can understand that <di> could make the markup more readable, sure. But prettifying the markup seems a rather extravagant reason to add a new element?

On the surface, <di> does make sense. But when you dig into the nuts and bolts, it seems less and less useful to me. But as I mentioned, I'm no expert.

[Sander Aarts]

Of course CSS and JavaScript can be used to emphasise the grouping and act as if there really are different branches within de <dl> tree.
Form validation can be done as well with JavaScript in HTML 4. Still, HTML 5 will have some new features to make that easier and more intuitive, to make it better.

I can understand that <di> could make the markup more readable, sure. But prettifying the markup seems a rather extravagant reason to add a new element?

More extravagant than adding an element called <dialog> which is pretty much the same as <dl>? An attribute might have done the trick here.

And what about <fieldset>s then? Shall we call those deprecated as well, since adding <legends> to a form already implies the start of a new group of form fields as well in the same manner as a <dt> does within a <dl>. Even more perhaps as only one <legend> is allowed per group which is not the case for <dt>s.

[Sander Aarts]

... besides, adding <di> would not just make it prettier or more readible.
With a <di> items within such a group would be siblings only to eachother, sharing a parent only within this group. In the current <dl> items share a parent with their cousins. That doesn't really sound very semantical to me (but maybe there are some definitions of 'cousin' that I don't know about ).

Even if there are a hundred specs, laws or whatever that say this is correct or no problem, it still doesn't feel right