[css-sizing-3] Use-case for intrinsic multicolumn sizes #6961

Addressing this part in the 2021-12-17 document status:

The following features are at-risk, and may be dropped during the CR period:

• Additions to column-width

I recently styled a layout of a rather long unordered list where column-width: max-content would have been exactly what I was looking for:

Screenshots of layout across viewport widths

.mon_moves {
  display: flex;
  flex-wrap: wrap;
  align-items: flex-start;
}

.tutor-moves {
  flex: 1;
}

.tutor-moves_heading {
  margin: 0;
}

.tutor-moves_list {
  margin: 0;
  padding: 0;
  list-style: inside;
  columns: max-content;
}
li { /* specifically for CSS multicolumn fragmentation, but good for printing too */
  break-inside: avoid;
}

<section class=mon_moves>
  <h3 class=moves_heading>Moves</h3>

  <table class=moves_table>
    <thead>
      <th>Level<th>Learns
    </thead>
    <tr><th>1
      <td><a href=/ptv/moves/#pound>Pound</a>, <a href=/ptv/moves/#sing>Sing</a>, <a
          href=/ptv/moves/#copycat>Copycat</a>, <a href=/ptv/moves/#defense-curl>Defense Curl</a>
    <tr><th>2
      <td><a href=/ptv/moves/#sweet-kiss>Sweet Kiss</a>
    <tr><th>3
      <td><a href=/ptv/moves/#disarming-voice>Disarming Voice</a>
    <!-- … -->
    <tr><th>14
      <td><a href=/ptv/moves/#astral-barrage>Astral Barrage</a>
  </table>

  <section class=tutor-moves>
    <h4 class=tutor-moves_heading>Tutor Moves</h4>

    <ul class=tutor-moves_list>
      <li><a href=/ptv/moves/#ally-switch>Ally Switch</a>
      <li><a href=/ptv/moves/#amnesia>Amnesia</a>
      <!-- … -->
      <li><a href=/ptv/moves/#zen-headbutt>Zen Headbutt</a>
    </ul>
  </section>
</section>

Right now I use a magic number instead with columns: 8em, but that can waste space if the item names are short, and wraps in an ugly way for item names that are too long. These issues are exacerbated by (auto-)translation — CJK ideographics always look like they’re wasting space, and German almost always triggers the ugly wrapping.

I tried flexbox and grid, but neither have desirable behavior: Grid’s repeat(auto-* …) wrapping doesn’t (yet?) allow truly intrinsic sizing either and fills the items ltr-tb instead of tb-ltr, and flexbox needs explicit height to wrap in the way I want — which largely defeats the point of handling unknown amounts of content across unknown viewports.

I know the “at-risk” status mostly has to do with implementer appetite, but I figured a good real use-case can only help.