[whatwg] <di>? Please?

[Jordan Dobson]

Sounds like what you want is flex box. Have you looked at that yet?

Jordan Dobson • Designer / Developer • 425-444-8014 • JordanDobson.com

On Jan 9, 2012, at 11:32 PM, Hugh Guiney <hugh.guiney at gmail.com> wrote:

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