This will put all your terms in the first column and all your descriptions in the second. All aligned nicely and creates a new row even if you have two `<dt>`s or `<dd>`s in a row. A flex solution would quickly fail once the terms get irregular.
That's clever. I think it's easy to make complicated solutions, and this is pretty clean. I like the solution for irregular content/tags getting displayed correctly.
But here’s the thing: Grid’s regular handling of long terms is typically not actually ideal anyway. Here are four ways of formatting such lists:
① Something that can be achieved with float, fancy margins or a couple of other related techniques (with caveats, inside this markup structure, such as needing both dd and dt to be inline, since `display: run-in` died):
Key: Value, even on
multiple lines
A long key: Value, even
on multiple
lines
② A flex approach:
Key: Value, even on
multiple lines
A long key: Value, even
on multiple
lines
③ A grid approach, avoiding wrapping keys:
Key: Value, even
on multiple
lines
A long key: Value, even
on multiple
lines
④ A grid approach, wrapping keys (and you’d better hope the key is wrappable):
Key: Value, even on
multiple lines
A long Value, even on
key: multiple lines
Now as it stands, your fit-content approach lands part-way between ③ and ④, wrapping the terms where possible, but extending the column’s width if necessary (e.g. if you use a long, unbreakable word, which experience tells me will be a URL and thus insanely long). Yet I would argue that in most cases of unknown content, ① or ② are better, most commonly ①. Wrapping terms is generally a bad idea (especially if there is no border in the grid), and if arbitrary content can end up in the term you’re likely to get pathological cases, like URLs in the term.
(I say all this as one who switched his known-content-that-doesn’t-trigger-these-cases <dl>s to `display: grid` over a year ago. But for arbitrary user content, I’d be more likely to go back to approximating ①, probably with markup other than <dl> now as well, to avoid problems related to it.)
This approach to handling outliers (break out of a rigid grid, wrap, extend all, &c.) is worth thinking more about. In the article this thread is about, I am actually not convinced that having the card internal elements lining up is a good thing. Here’s the problem: the depiction of its appearance when they don’t line up is deceptive, and not how you would realistically implement it. Without subgrid, you’d be using `display: flex; flex-direction: column` on the cards, and that’s what’s depicted; but what the depiction lacks is `flex: 1` on the content, so that the header and footer take the least space possible, rather than themselves flexing as well. If you fix that, the not-lining-up case no longer looks terrible; I’d say that at that size then it’s six of one, half a dozen of the other; and for larger grids or more pathological cases, it’ll very arguably be nicer.
But here’s the thing: Grid’s regular handling of long terms is typically not actually ideal anyway.
Grid is just the layout (columns/rows), not entirely how text is handled. 3 & 4 are no different with grid, only word-break/word-wrap with forced/limited widths.
And 1 & 2 seem disjointed and hard to read (ie, break long held rules for readability), I don't see the value arbitrary space after the key. 1 & 2 would easily be better suited to this:
Key:
Value, even on
multiple lines
A long key:
Value, even
on multiple
lines
Or this:
Key: Value, even on
multiple lines
A long key: Value, even
on multiple lines
https://codepen.io/anon/pen/gJJmzM?&editable=true