[whatwg] <di>? Please?

[Hugh Guiney]

On Mon, Mar 5, 2012 at 12:09 AM, Ian Hickson <ian at hixie.ch> wrote:
> The only thing it adds to the grouping is the ability to have a subsection
> that is then followed by more content from the subsection's parent
> section. You couldn't do that with <hx> alone. However, for <section>
> that's more of a negative than a positive, really (it makes more sense for
> <aside>, <nav>, and <article>; <section> only allows it for consistency).

In what ways is that a negative?

> The spec doesn't generally include design rationale. (If anyone would like
> to help maintain our rationale documentation, please let me know. We're
> always in need of volunteers there.)

What type of work is involved?

> <di> doesn't exist. The ability to have multiple types of authoring style
> isn't the reason for <section>'s existence. It's just a side-effect of now
> having two different ways to mark up sections. It's not actually a good
> thing in language design to have multiple ways to do something (despite
> what Perl might have us believe!).

HTML is full of multiple ways to do things: a run of text can avoid
<p> and be the child of a <div> if the author prefers, a <footer> can
be at the bottom or top of a section, authors can continue to use
Microformats despite the existence of microdata, etc. If language
idealism was a tenable goal on the Web then the WHATWG wouldn't exist
and we would all be using XHTML 2 right now (which had <di>, for that
matter).

> <section> wasn't introduced as a stop-gap measure.
>
> There's no such thing as a stop-gap measure on the Web. We can't add
> something then remove it. Once we've added something, it's part of the
> platform, forever. That's why we have to be careful to only add things
> that make sense on the long term.

I only said "stopgap" because you posited CSS grouping as the ideal we
should be striving for, when this method would work today. I actually
don't think this should be taken out at a later time, as CSS grouping
only addressing the issue of styling. It does not address the fact
that—as I outlined in my original post—it is impossible with <dl>'s
current parsing model to specify a named value followed by an unnamed
value, since the unnamed value would be subsumed into the preceding
group and be interpreted as an alternate value for it. The converse
(an unnamed value followed by a named value) *is* possible. The spec
claims that the order may or may not be important, yet this forces the
author to write things in a specific order, which may violate what
data they are trying to describe, or in what way. To illustrate:

<dl>
<dd>Nameless value</dd>
<dt>Name</dt>
<dd>Value</dd>
</dl>

<dl>
<dt>Name</dt>
<dd>Value</dd>
<dd>Nameless value? Nope, alternate value for Name.</dd>
</dl>

Whereas wrapping either or both Name/Value and Nameless value in <di>
would mirror what is already allowed, but free the author up to use
the appropriate order rather than compromising semantics with multiple
<dl>s or non-<dl>s.