dl {
align-items: baseline;
display: grid;
grid-gap: 1.5ex 1.5em;
grid-template-columns: fit-content(12ch) 1fr;
}
dl dt {
font-weight: 600;
grid-column: 1;
}
dl dd {
grid-column: 2;
}
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.① 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.
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 linesI think back to the early days (circa 2000 or so), before CSS positioning and float hacks were even a thing, working as the lead webdev at Upromise, meticulously hand-crafting complex layouts with nested HTML tables... you could nest them 5 or 6 levels deep before running into noticeable render performance issues in what must have been, what, IE4 and NN4? It really has been a couple decades, hasn't it. Kinda wish every FE dev had to follow the path the industry took to get where we are now...
/ramble
I think this is how web tech works best, when you see the best way coming down the pipe, don't waste time on hacks. But I admit, floating was the only way to make columns for far to long.
I know grid is taking a long time to take root. I primarily only use grid-template-columns, grid-gap and areas or really only needed for major/complicated layout.
Why not table with inline width=95%/align=center
It seems to be about a mix of grids with flux instead of either/or.
But you are right, something like a gallery of images (unknown number of items that need to flow), flex seems more useful.
You are right that I just haven't NEEDED it and without that I don't tend to grock things.
Since IE is no longer supported (or even considered a browser by MS, but a compatibility layer) what kind of site do you work on that is so heavily trafficked by primarily IE?
Grid requires no/fewer wrapping elements, solid outcomes (ie, code matches result more often than other layout methods from the start) and lots of minor properties for edge use cases. And this is just a summary of the benefits.
An example I dealt with recently: I needed a header with logo / external link / social icons/ content / phone link. All to layout perfectly, and be mobile friendly.
With grid, I used this: (this is rough code to demonstrate the simplicity, I made a codepen demonstrating it properly. [0])
For each of the logo, content, etc... areas you use this to attach it to the specific location in the grid. You end up with exactly what you would expect: For mobile, I wanted this: Here's the only CSS needed for mobile. (or reverse this if you are doing mobile first layout) Here's the html: The power to move content around with such simple and clean code like this is amazing.With flexbox you can use the "order" property to move stuff around a little, but not control the exact layout so cleanly and simply. There are tweaks for adjusting the widths of columns and heights of rows, but this is generally all that is needed to get the layout with grid.
There is also grid-gap [1], something not possible in flexbox yet. (though Firefox supports grid-gap with flexbox)
[1] https://codepen.io/Vanderson/pen/yWWVVZ
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/gap