[whatwg] <di>? Please?

[Hugh Guiney]

As I understand it, the main reason for rejecting <di> was that it
solves a problem that is allegedly CSS's job, but as an author who
uses <dl>s quite extensively, adding a grouping element would really
make my life a lot easier.

Yes, my most common problem with <dl>s is styling them, but it's
hardly CSS's fault. What kind of styling am I attempting to do?
Mostly, to arrange them in columns.

Why not use <table>? Because the data is at most two-dimensional
(i.e., serial, not tabular) and consists of definitions rather than
arbitrary data. Why would I want to to arrange the data in this way?
The same reason I would want to arrange most things in columns: to use
vertical space efficiently when I have it.

I've tried, and as far as I can tell, this can't be achieved with
floats. Even if it can, it's prohibitively unintuitive enough to
someone with considerable CSS experience. The only way I have done it
is with absolute positioning, which of course takes you out of normal
flow and into fixed coordinate positioning; hardly tenable considering
the flexibility requirements of fluid, and now responsive designs.
Even recent additions like CSS3 columns are a blunt instrument in this
regard, which often result in widows/orphans unless height is
manipulated manually to force everything into place (a nonstarter for
separation of concerns).

Yet, I can achieve this easily with <ul>s and with <table>s, with
headings and paragraphs inside of various containers; I can do it with
essentially every other data structure but <dl>, and that's no
coincidence: <dl>s are notoriously hard to style specifically because
they're loosely-structured; they lack the grouping semantics which are
paradoxically abundant in other content models. Because of this, I
have in the past resorted to either: A.) choosing a
less-semantically-accurate, but more flexible structure; or B.)
splitting the <dl> into two <dl>s.

I tend to opt for B. simply because I want to retain the <dl>
semantics, but it's still less-than-desirable because the motivation
for doing so is purely presentational. Sibling <dl>s are as silly as
sibling <ul>/<ol>s: if there's no reason to have other content between
them (such as an explanation about what the second list represents),
there's no reason not to enumerate them all in the same list. Yet,
it's the only practical way to achieve this effect. I have a feeling
most authors would opt for A., however, which diminishes the utility
of <dl> by making it even more rarely used.

The way I see it, <di> has more or less identical use cases to
<section>. Despite the fact that we have an outlining algorithm that
will automatically determine the structure of your content without
using <section> at all, authors are still free to use grouping
mechanism to make sectioning explicit, which is necessary to avoid
ambiguity. Take this for example:

<section>
  <h3>foo</h3>
  <p>bar</p>
</section>
<section>
  <h3>baz</h3>
  <p>qux</p>
</section>
<p>quux</p>

…where the absence of <section>s would result in two titled sections,
rather than the desired: three sections, two of which are titled and
one of which is untitled.

This is in no way different from the following:

<di>
  <dt>foo</dt>
  <dd>bar</dd>
</di>
<di>
  <dt>baz</dt>
  <dd>qux</dd>
</di>
<dd>quux</dd>

…where the absence of <di>s would result in two named values, rather
than the desired: three values, two of which are named and one of
which is unnamed.

Simply put: just because the parsing algorithm is well-defined and we
can imply association sans-container, that doesn't mean authors (like
myself) won't want finer-grained control over grouping.

Is there a compelling reason why, given the current <dl> content
model, it is possible to create a list of: nothing but unnamed values,
nothing but valueless names, an unnamed value followed by a named
value, a named value followed by a valueless name, but NOT a named
value followed by an unnamed value—what makes that last scenario any
less useful than all of the others? If anything it's probably the
*most* useful, since valueless names and nameless values can already
be represented by <ul>/<ol>.