Proposal to include <di>-like element

[Cerbera]

(I also think form validation and <dialog> are unnecessary additions to HTML. But I assume there's a good reason for them, just that I don't know what it is.)

I think anyone would agree that, on the surface, <di> is a good idea. But since the relationship is just as unambiguous without this element, it doesn't seem to add that much value. Also, we aren't talking about deprecating <di> and replacing it with an all-new association method, we are talking about whether <di> is worth adding.

If you are proposing that <di> would replace the existing grouping mechanism so that it used DOM relationships rather than element types, consider this:

Code: Select all

<dl>
<di>
  <dt>foo</dt>
  <dd>bar</dd>
  <dt>bish</dt>
  <dd>bash</dd>
</di>
</dl>

Would this mean:

• foo = bar
• bish = bash

Or:

• foo, bish = bar, bash

If it's the former, the historic association method is adequate. If it's the latter, what would happen when <di> is absent:

Code: Select all

<dl>
<dt>foo</dt>
<dd>bar</dd>
<dt>bish</dt>
<dd>bash</dd>
</dl>

And what about when some but not all groups in a <dl> are contained by a <di>:

Code: Select all

<dl>
<di>
  <dt>foo</dt>
  <dd>bar</dd>
</di>
<dt>bish</dt>
<dd>bash</dd>
<dt>alpha</dt>
<dd>beta</dt>
</dl>

I think this DOM-based method would not be backwards compatible, particularly with assistive technologies. That would make HTML5's <dl> less accessible than HTML4's -- a very undesirable outcome.

It's all about the nuts and bolts!

[bfrohs]

I haven't been one to use <fieldset> within my forms in the past, but it does add a large amount structure to the form that is not present in the form itself. I believe adding <di> to <dl> and <dialog> would indeed add organization to the code as well as the document itself. You may be able to accomplish the same styling effects with CSS, but if all of (X)HTML was founded on this principle, <address>, <dialog>, <blockquote> and other such elements would simply be replaced with <div>.

As for backward compatibility, IE has done little to nothing other than slow down the progression of (X)HTML on the Web. Nearly every web designer complains about IE, yet due to the market share IE has, they give in and use CSS Hacks or don't use some features of (X)HTML at all simply because IE doesn't support it. In my opinion, the large market share IE has is due to the fact that web designers give in to IE and make their sites IE-compatible. Many of these users don't even know the bad practices of IE. For example, my parents had no idea. They are now avid Firefox users. We cannot jump forward as quickly as we like, but we must force IE into changing. If we don't, they will continue to serve up web pages any way they like.

[Sander Aarts]

(I also think form validation and <dialog> are unnecessary additions to HTML. But I assume there's a good reason for them, just that I don't know what it is.)

I didn't say they're unneccessary, I just made a comparisment to the choices that are made concerning other elements and features. I'm not sure about <dialog>, but I think HTML form validation is a very good thing.

Also, we aren't talking about deprecating <di> and replacing it with an all-new association method, we are talking about whether <di> is worth adding.

True, but again it was just a comparisment. I've never heard anyone saying that we could get rid of <fieldset> because it has no semantic value as its <legend> allready tells us where a new group starts.

Code: Select all

<dl>
<di>
  <dt>foo</dt>
  <dd>bar</dd>
  <dt>bish</dt>
  <dd>bash</dd>
</di>
</dl>

Would this mean:

• foo = bar
• bish = bash

Or:

• foo, bish = bar, bash

Now we're talking

I guess the second option would be the most logical.

If it's the latter, what would happen when <di> is absent:

Code: Select all

<dl>
<dt>foo</dt>
<dd>bar</dd>
<dt>bish</dt>
<dd>bash</dd>
</dl>

And what about when some but not all groups in a <dl> are contained by a <di>:

Code: Select all

<dl>
<di>
  <dt>foo</dt>
  <dd>bar</dd>
</di>
<dt>bish</dt>
<dd>bash</dd>
<dt>alpha</dt>
<dd>beta</dt>
</dl>

Good questions. I'm not saying that I've thought all options and possible errors all the way through. I just experience an element missing whenever I work with <dl>s.
But to answer tour questions... I think there are two options here:

1. if <di> will not be optional, these examples would not conform
2. if <di> will be optional there are two options again:
   1. list items that are not explicitly grouped inside a <di> are grouped implicitly (so the first example would have one group, the second two)
   2. if a <dl> contains no <di>s at all, the 'old' way of grouping is used

Now that I think about it I guess I'd prefer option 1, making <di> not an optional element. Option 2a could be defined as part of the 'error handling' then
Option 2b would offer a backwards compatibilty opportunity, but therefore has the same 'incestuous' DOM structure (cousins sharing the same parent) as it has nowadays.

I think this DOM-based method would not be backwards compatible, particularly with assistive technologies. That would make HTML5's <dl> less accessible than HTML4's -- a very undesirable outcome.

But that would mean that we're stuck forever in HTML4. That seems even more undersirable. To people who rely on assistive technologies as well I guess.
<abbr> was only introduced in HTML4 and not supported in IE6 and Netscape 4. Is that a bad thing? I think not. Even <span>s were not to be found in any specs before HTML4.

[Cerbera]

The key is, as much as possible, to add new things in a way which doesn't breaking current things.

Changing the way <dt>+<dd> elements get associated would probably break current things (such as the output from screen readers). Since the historic way associates them fine in practise and HTML5 makes this method bulletproof, breaking all the existing UA support for <dl> seems like rather a high price to pay?

Now, if <di> were introduced simply to make <dt>+<dd> associations more obvious to authors and had no influence on semantics, that would cause no breakage. However, the way the elements get associated is pretty easy to understand: when a <dd> is followed by a <dt>, a new group starts. So it doesn't make the markup a whole lot clearer, imho.

If <di> were just to provide a convenient hook for styling, zcorpan's suggestion for something like a ::key-value-pair psuedo-element in CSS would provide that. Although <di> is already stylable in some browsers, styling is more logically done at the presentational level. And zcorpan's idea would add no filesize to the markup.

There are a lot of "housekeeping" elements which could be introduced. However, unless they add significant practical advantages with minimal disadvantages, is it really worth adding them? (I don't know whether it is or isn't, btw.)

[bfrohs]

In my opinion, if you want (X)HTML 5 to truly help the web, backward-compatibility will have to be broken somewhere. There is always talk of things that would make it more organized, but everyone is too scared to break backward-compatibility because it might affect users with older browsers. I say (X)HTML 5 should just figure out everything it wants to accomplish and do it. We can talk about how we want this and that to be changed, but if all we do it talk about it, how is that improving (X)HTML?

Personally, I believe the best plan would to get everything figured out and set a date as to when UAs must conform to (X)HTML 5. Since Apple, Opera, and Mozilla are already backing this project, it just makes it that much easier. Prepare the UA vendors and publishers now, and set a date when (X)HTML 5 will be available. That way everyone (including the general public) will be prepared (whether or not they know it) for (X)HTML 5. Keeping backward-compatibility is slowing progress and keeping key features out of (X)HTML.

[Stevie D]

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.

There is a key difference between <fieldset> and the proposed <di>. <dt> and <dd> elements are automatically and unambiguously associated with each other. A group of one or more contiguous <dt> elements are defined by a group of one or more contiguous <dd> elements. The association is terminated by either another <dt> element or the closing </dl> tag.

You don't get that with elements in a <form>. Form elements may be grouped together, as in a <fieldset>, or may be stand-alone items that are not grouped with any others. So while a <legend> element will implicitly begin a <fieldset>, and in doing so terminate a previous unclosed <fieldset>, there will often be times when you need to close a <fieldset> without beginning a new one.

Consider the following form structure:

Code: Select all

<form>
Name
<fieldset><legend>Address</legend>
Address 1
Address 2
Town
Postcode
Country
</fieldset>
Age
</form>

If you're not allowed <fieldset> elements, you can't separate off the "age" field at the end from the preceding "address" fields, other than by inserting a (completely unnecessary) legend.

[Cerbera]

The text you quoted was written by Sander Aarts, not me. I think <fieldset> must be in HTML5 for exactly the reason you give: groups of related controls.

[Fyrd]

Wow, I was just about to propose this exact element. Glad I decided to do a search first.

So obviously, for reasons mentioned above, I think this element makes a lot of sense and could be quite useful.

[haka]

It may be usefull, but I dont think it is important. Why not grouping multiple <dl>-list in a parent list?

In HTML 5 are a lot of new elements that the people has to learn. So the list of new elements should be focused on the realy important ones.

[Fyrd]

In HTML 5 are a lot of new elements that the people has to learn. So the list of new elements should be focused on the realy important ones.

And assuming the <dl>/<dt>/<dd> system could still work without <di>, no one would have to learn it. It would just be there for anyone looking for a way to group key/value pairs in an element.

Personally I was looking for an element that would let me group items the way I want to (already possible), but using appropriate semantics (currently not possible).

One other convenient thing this would allow is to style the definition list as a table with table rows and cells.

It may be usefull, but I dont think it is important. Why not grouping multiple <dl>-list in a parent list?

The problem with grouping multiple <dl>s is that it means you have all these lists that just have a single key/value in them, which wouldn't make it a list at all. So it's semantically inappropriate.

I guess instead one might create some kind of <dfn><key></key><value></value></dfn> system, which could work independantly or inside a list. As an added bonus that give a way of displaying a single key/value pair, without requiring to be in a list. Has something like this been considered before?

[Fyrd]

After reading the HTML5 spec on tables, I have found that this setup might be a decent alternative solution:

Code: Select all

<table>
<tr>
   <th>Key</th><td>value</td>
</tr>
<tr>
   <th>Key</th><td>value</td>
</tr>
</table>


And one could use CSS to display elements as block, inline, or whatever is preferred. Unfortunately Internet Explorer is currently NOT able to do so, but then IE compatibility would probably be an issue with any other suggestion.

Can anyone see any other problem with this solution?

[bfrohs]

My apologies on bringing this back from the dead, but there is new... evidence, so to speak.

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

As I mentioned in #whatwg on freenode, it isn't enough. Let's say I have the following definition list:

Code: Select all

<dl>
<dt>term 1</dt>
<dd>
<dl>
  <dt>term 1-1</dt>
  <dd>def 1-1-1</dd>
  <dd>def 1-1-2</dd>
</dl>
</dd>
<dd>
<dl>
  <dt>term 1-2</dt>
  <dd>def 1-2-1</dd>
  <dd>def 1-2-2</dd>
</dl>
</dd>
<dt>term 2</dt>
<dd>
<dl>
  <dt>term 2-1</dt>
  <dd>def 2-1-1</dd>
  <dd>def 2-1-2</dd>
</dl>
</dd>
</dl>

Okay. Now that we have that, let's add some styles to it.

Code: Select all

dl {font-family:verdana;font-size:.8em;width:500px;padding:0;margin:0 auto;border:1px solid #000;}
dt {margin:.2em;padding:.2em;background:#000;color:#fff;}
dd {margin:.5em;padding:0;}
dl dl {width:auto;font-size:1em;}

The DTs have black backgrounds and the DLs have black borders. Now, how do we separate the definition sets? Well, this should be easy. Let's try the :last-child selector.

Code: Select all

body > dl > dd:last-child {border-bottom:5px solid #f00;}

This does exactly what it's supposed to (style-wise). It adds a 5 pixel border under the last dd child in the definition list. This isn't very helpful since we're looking for the last definition of each definition term. This means it is not a styling problem, but rather a structure problem. The addition of a definition group tag would allow for this to be done. We could still do the 5px red border at the very bottom of the list by adding the :last-child selector to the definition group tag rather than the dd tag. The current spec makes it impossible (without hacks of course) to do this.