Tom MacWright

tom@macwright.com

Big 4

Big is a presentation system that I created for fast, low-configuration talks. After versions 0, 1, 2, and 3, it’s ready for the next integer: 4.

If you aren’t familiar with Big, the previous posts should be a good introduction. Big has a double meaning: its main innovation is that it automatically makes text as large as it can be, which blurs the line between title, reduces the need for configuration, and encourages short slides. And it’s tiny, in terms of code. It started at 50 lines, grew a bit, and is back to a medium size of 216 lines – with a bunch of features.

What’s new in 4

I removed a few features

  • Audio tracks
  • Arrow navigation in jump mode
  • IE compatibility
  • Markdown compatibility

These things are gone, because my user research indicated that several were underused, and because some will be replaced by better web standards, and because Markdown doesn’t mix well with the direction of Big.

Improved the setup experience

  • No more NPM
  • Glitch starter

Check out the README for the details. The gist is that you can click a link (like this link) and instantly have an editable, hosted presentation.

I realized that not all JavaScript projects are NPM modules, and this one simply didn’t work all that well in that system. Forking the repo, downloading a zip file, scaffolding with degit, or starting from Glitch are all fast and great ways to start using Big.

Big has one new whiz-bang feature: layouts.

See, Big always worked by maximizing font size. This in itself was quite a feature - puffing up arbitrary text, line-breaks and all, is a lot more subtle than it sounds. Big has employed a number of different algorithms, but at the core it’s essentially an iterative approximation, like the Euler method but less interesting.

The problem with manipulating font size with the singular goal of making text as big as you can make it is that everything else, especially images, are not part of the goal. Images that are automatically shrunk will be shrunk to the extreme. Images that won’t shrink prevent text from getting big. The only case that Big handled gracefully was having images as the background of a slide. You could craft your presentations such that that was an acceptable compromise – and I did – but there’s no denying that it leaves a lot to be desired.

That’s the big thing that Big v4 fixes. It provides a rational, simple, reliable way to show both text and an image, or multiple blocks of text, on a slide.

Some software should be used without knowing how it works. You can use Big that way too, but it isn’t really necessary: the core magic is confined to less than 50 lines of code. So I’ll explain this feature from the inside out. Plus, you might learn something. I certainly did.

CSS Grid

We start with CSS Grid. This is a new value for the display property. You might know display from such hits as block, inline, and perhaps flex. grid is a new value, and it lets you lay out grids. In some ways, CSS Grid is like a new table element – in fact, I use it in exactly that way on the post listings on macwright.org. But it gives more control over potentially overlapping areas, how to size rows and columns, and plus, for the semantic HTML fans, it doesn’t require you to structure content in a particular way.

So I use CSS Grid to layout slides with more than one thing on them. You can define a grid that puts an image next to text, or below it, or above it. You can define a grid with multiple images and multiple chunks of text. You can customize how much of the slide is text, and how much is an image.

object-fit

The other ingredient that makes this work is the object-fit CSS property. It took me a while to understand precisely what object-fit does, but once I got it, I realized how much it would enable Big.

object-fit customizes how a ‘replaced element’, practically an img, video, or iframe, occupies its space. There are lots of ways to size and scale images, but this is the only one that cleanly solved the constrained problem: to make an image occupy the size of a container, never causing its container to increase in size, and to do it in pure CSS.

A boost from JavaScript

Big has always required JavaScript to do text sizing: there isn’t a pure CSS technique for fitting arbitrary text with line breaks to a container. In previous Bigs, this step only cared about the slide’s outer div, but if we’re dealing with layouts, we want to make sure that each area of the grid is nice and correctly fitted. Also, we want to support vertical layouts, so the grid needs an explicit height. So that’s how JavaScript participates in layout slides - by making sure that grids are filled to the brim.


Even though I’m putting the ‘4’ stamp on this release, this kind of project is never-ending. Even now, I have a long list of improvements that I’d love to implement. But there are only so many hours in the day, and I always have a few projects going.

So if you find something awry with Big, please help out by filing a good, long, explicit bug report, or even better, by contributing. It’s hard to overstate how much a great bug report helps a project. And it’s hard to overstate how much bad bug reports sap the time, energy, and enthusiasm of myself and all open source maintainers. So please, good reports only.


I set up a long, batteries-included demo so you can see what Big can do. There’s a lot more. I spent a lot of time rewriting the readme in hopes that it can be comprehensive, accurate, and fast - check that out, too.

If you’re looking for a different kind of presentation-writing experience, try out Big.