Introducing Learning Notes

Updated June 7, 2025: This never went anywhere. I have removed it from the site. I stopped reading as much and struggled to take notes when I do. I’ve gotten better since then, and am interested in sharing notes and other digital garden-esque things here, but want to spend more time thinking about that.

Recently at work I came across this GitHub repo. I don’t remember what I was searching for, but it fascinated me. Here was someone who was taking notes on books, articles, and talks they read and saw—as if this were college! But I really liked it. I had mentioned recently wanting to slow down. I’ve felt like I don’t always retain all the information I read in books, nor even any information sometimes. I’ll look at the bookshelf and know I read a book, but I can’t explain the basic plot or argument. I don’t like that. I read and highlight passages for a reason. I want to easily look up interesting things I learned reading a book. Or characters, timelines, and settings in a novel. Writing it down will not only mean I’ll be able to look it up later, but it will also reenforce my learning as I’m writing the notes.

I decided to make a new section, Notes. It’s mostly for my benefit, but I think information should be shared openly, so I’m sharing my notes with you. You never know who will stumble across it and benefit from it, just like the repository that was my inspiration.

Creating this new section required updating some styles. It’s largely uninteresting, but there is one technique I do want to highlight. I wanted to have a table of contents for each note, so I could quickly jump to sections. I expect most of my notes will be for books, and there are a lot of chapters, so jumping around easily is important. On small screens, the table of contents should just stack on top of the notes. Nothing special. But when there is enough screen real estate, I want the table of contents to be a sidebar. Whenever possible, I want to avoid media queries and use intrinsic web design principles instead. I read Every Layout years ago, but still refer to it constantly. There’s a perfect layout for this very idea: The Sidebar. It lets you have a fixed-ish width sidebar, and a variable-width main content area. They stack when needed, and are side-by-side otherwise.

Implementing The Sidebar was very straightforward. But I wanted to take it a step further and make the sidebar sticky when it wasn’t stacked, so as you scrolled down the long page of notes, you could always jump to other sections quickly. If I were using media queries, this would be trivial. But since the browser decides when the elements stack and when they’re side-by-side, I had to think of a different approach.

I’ve used ResizeObservers a few times before at work, and this was the perfect use case. ResizeObservers are a performant way to react to changes as elements resize. The API is a little weird: why are there “entries” when you can only observe one element? Why do I have to loop through them then? Why is entry.contentBoxSize an array?

const sidebar = document.querySelector(".table-of-contents");

const resizeObserver = new ResizeObserver((entries) => {
	for (const entry of entries) {
		if (entry.contentBoxSize) {
			const inlineSize = entry.contentBoxSize[0].inlineSize;

			if (window.innerWidth - mainPadding > inlineSize) {
				sidebar.classList.add("sidebar--stuck");
			} else {
				sidebar.classList.remove("sidebar--stuck");
			}
		}
	}
});

resizeObserver.observe(sidebar);

When stacked, the table of contents would be roughly the size of the main element, which would be the width of the window as well. So in my ResizeObserver, I check if the table of contents is the size of the window (minus the padding applied to its container, the main element). If it’s that size or smaller, leave it alone. If it’s smaller than that size, it must be side-by-side, and then I add a class (using the classList API) that will make it sticky. Check it out for yourself.