How I fixed the giant blank gap under image-heavy articles
Both of blog.js's height functions, getFullHeight() and getHeightForFirstN(n), computed an article's height by looping over its direct children and adding up each one's own offsetHeight:
let height = contentChildren.reduce((acc, el) => {
const style = getComputedStyle(el);
return acc + el.offsetHeight + parseFloat(style.marginTop) + parseFloat(style.marginBottom);
}, 0);That assumes every child sits on its own row, stacked one under the next — true for block-level elements like <h3>, <p>, and <table>. But <img> defaults to display: inline, and blog.css has no rule that changes that. Consecutive <img> tags flow like words in a sentence — they sit side by side and only wrap to a new line when they run out of horizontal room, exactly like text.
The IKEA article has two runs of images (5 photos, then 7 more) that actually render as just 2 visual rows. I confirmed this in the browser console: all 5 images in the first run shared the same rendered top offset, and all 7 in the second run shared a different single top. But the summing loop added up all 12 images' heights as if each occupied its own row — 3318px of summed heights versus 767px of real visual content. Since the article has overflow: hidden, the box just got set to that inflated 3318px-ish height and the real content sat at the top, leaving a huge blank area below it.
The fix was to stop reimplementing layout math and just read the browser's own measurements instead:
getFullHeight()now simply returnsarticle.offsetHeightonce the article's height is set to'auto'— the browser has already laid out any wrapped inline content correctly, so there's nothing left to compute. This also made the oldgetBrHeight()special-case for<br>unnecessary, since native layout handles that too.getHeightForFirstN(n)now takes the actual renderedgetBoundingClientRect()of the Nth included child and measures down from the article's own top edge, rather than summing individual child heights.
The first version of this fix introduced a smaller follow-up bug: it added the article's own bottom padding as trailing space after the cut-off point, but since the next (hidden) child sits immediately after with no gap, that padding just revealed a sliver of its text. I caught this by actually looking at a screenshot of the collapsed articles, not just checking that the previously-broken one now worked. The real fix measures the actual rendered gap to whatever child follows the cutoff (which already accounts for CSS margins correctly, no matter what the next element is), and only falls back to the article's own padding when there's no next child at all — i.e. when the "preview" is actually the whole article.
Verified in Chromium via the claude-in-chrome extension: the IKEA article now expands to hug its content with no extra gap, the earlier Expand/Collapse fix (see the entry below) still works on the "Harry Sends..." articles, and an article with a <br> and several tables still renders with normal padding, not an inflated one.