Table column widths

Every column here declares one of the four roles, and between them they decide the whole layout. The check box and the operations shrink to their contents and stop; the title takes everything the others did not want; the summary is given a fixed measure in characters and wraps inside it; the notes column is empty in every row and collapses to nothing. Only one column is allowed to grow -- with none, auto layout shares the slack out in proportion to content and the table shifts every time the data does; with two, they split it, which is rarely what anyone wanted. The role is declared once, on the column, and the component puts it on the header cell and on every body cell beneath it: auto layout sizes a column from the widest content in it, so a role on the header alone leaves a long cell free to widen the column anyway. The selects above the table are every option a column can be given, set to what this table declares: change one and the class moves onto that column, header cell and body cells together, so the arithmetic can be watched rather than read.

Identical data through the same component, with the roles left off the columns. This is what auto layout does when nobody tells it which column matters: the summary is the widest content in the table, so it takes most of the width and the component names are squeezed against it, the empty column still holds a share of the table, and the operations column is as wide as whichever dropbutton happens to have the longest label. Nothing here is broken -- it is the browser guessing, and it guesses again whenever the content changes.

Sixteen columns, none of which can be dropped. The table sits in the scroll container the component wraps every table in, so it keeps its natural width and the container scrolls sideways rather than the columns being crushed into the space available. The pairing that makes that work is on the table itself: `width: auto` with `min-width: 100%`. With the `width: 100%` a table would otherwise inherit, it can never exceed its container, so the columns shrink to their minimum and overflow anyway -- and no scrollbar ever appears, which is the failure this looks like when it goes wrong. The figures are set to the right, which is the other thing a column carries besides its width.

A machine name, a namespaced class and a URL are each a single word as far as the browser is concerned, so each one sets the minimum width of its column by itself and squeezes everything beside it. The theme puts `overflow-wrap: break-word` on every cell for that reason -- it is the floor the rest of this page stands on. The two sized columns here go further and ask to break inside a word, which is safe precisely because they are sized: a column that reports a smaller minimum is a column the growing one takes the space of, and these two measured 33px and 31px wide when they were capped without also being floored.

Scroll this table down and the header stays; scroll it sideways and the header goes with it. Those two used to be mutually exclusive here. Core sticks a header by cloning it into an element fixed to the viewport, which cannot survive a table that scrolls horizontally -- the clone stays put while the columns move underneath it -- so the theme used to switch the scroll container off whenever a header was sticky. The script is turned off in the theme info file and the header is stuck with CSS `position: sticky` instead. That comes with a condition worth knowing: sticky sticks to the nearest scrollport, which is the container rather than the page, and a container with no height of its own never scrolls vertically -- so a sticky header inside one simply leaves the screen with the page. A sticky table is therefore given a bounded height and scrolls in both axes, which is why this one has a scrollbar of its own and the four above do not.