Ohno Type School: A (2020)

in other words, it's not that deep. The site is fun and you can figure it out.

> I ask genuinely: what is the value -- in what way does it "fit" so well?

This is a you problem. Its self-evident to anyone willing to explore their world in an incredibly low-stakes manner, and its pretty much pointless to describe or debate the merits to someone able but unwilling to experience it themselves.

So, the key here is simply the horizontal layout: roman-alphabet letters naturally sit as "siblings" on a horizontal line, and — at least on desktops/laptops [which is pre-assumed here, since the site is just broken on mobile] — people's screens will almost always be much wider than they are tall.

Giving the type examples (a bad "A" glyph, vs a different bad "A" glyph, vs a good "A" glyph) all baseline-aligned on a horizontal line — packed together just closely enough to see multiple of them at a time (to visually contrast them) while also having room for notes in between — allows the eye of an English (or other LTR alphabetic-language) reader to intuitively pick up the same point that's being made explicitly in the notes, implicitly, just by looking at the successive examples next to each-other.

This wouldn't work with a vertical layout. Not just because on desktop there wouldn't be enough room (multiple example glyphs and their notes wouldn't fit together within the viewport), but more fundamentally because said English reader's eye isn't trained to compare things that are juxtaposed vertically nearly as well as it is trained to compare things that are juxtaposed horizontally. (Heck, part of that is inate in our biology: people with regular binocular vision can cross their eyes to superimpose things that are juxtaposed horizontally!)

---

The arbitrary viewport navigation on vertical scroll, is a technique commonly employed by a modern "web experience designer" when what they want to show you is some kind of animated presentation, but one that is so information-dense that there is no "correct speed" for that presentation to automatically play at. Instead, they put the control of the animation into your hands, having you manually scrub through it, by giving the document a large height, and having your Y scroll offset translate to the animation's timeline position.

In other words: this webpage could have (and with a lazier team, would have) been a video presentation. But instead, they went to the extra effort to give you a "video" that plays as you scroll it in a way that feels intuitively similar to scrolling through a webpage; where that interaction "affords" scrolling in fits and starts, to give yourself time to read the content. And where, when you're not scrolling, it is just a webpage, where you can highlight and copy the text, click citation links, hover over things, etc.

---

And sure, in this case, all the "animation" is doing here is moving you horizontally when you scroll vertically, and fading things in and out a bit. And you could accomplish that without hijacking the semantics of scrolling, by just making the page very, very wide.

But even today, it's still a bad idea, accessibility-wise, to ship a "very very wide webpage", because even in 2025, the OEM mice that come with Windows desktop PCs still don't give you any way to scroll horizontally. Which means that any "wide webpage that you are actually expected to navigate by scrolling horizontally" would effectively lock out the average office worker from consuming the content on their work computer (unless they realize that the browser gives them a horizontal scrollbar — which is unlikely, due to the non-discoverability of modern scrollbars.)

(And this first-order effect creates a second-order chicken-and-egg problem: nobody ships very wide webpages [or any other kind of UX views, other than maybe spreadsheets]; so few people even realize it's possible to scroll horizontally, even when they have a mouse or touch surface capable of emitting horizontal-scroll gestures. [Or they know that it does something, but only seemingly bad things — pulling at the edge of the view rather than actually scrolling — so they train themselves out of ever giving any diagonality to their scroll gestures and never intentionally try it.] ...and so we all avoid shipping wide webpages, because it would confuse those people.)

In other words, "hijacking the semantics of scrolling" in this way is an accessibility aid: both for the desktop users with one-scroll-axis mice, and for the people who just plain don't realize they can or should ever scroll/swipe horizontally.

---

Though, I should note that even on this page, which is nearly a perfect case for "just let the user scroll horizontally", there's still the potential for users "getting lost" in a contentless void if you remove the "guardrails" imposed by the single-axis timeline-scrolling mechanism.

There's a bit of this page where you scroll vertically "normally" before and after the scroll-offset animation-timeline sync happens. If the page was literally translated into a wide canvas, there'd still be a bit at the top and bottom that'd just be empty on the right. A user could wind up scrolling down, then right, then up (or more likely, up-right or down-right, which new touchpad-users often do by accident)... and wind up in a blank nothing space.

There's no settled solution for this "getting lost in the empty-space parts of a large canvas" problem on the current web.

That's not to say that it couldn't be solved. Video games have had "camera-lock bounding boxes" for forever. Browsers could allow you to specify a "valid scroll boundary" [probably as a CSS shape, ala clip-path] for a given scrollable container, where the viewport of that container would "run into a wall" if any part of it would collide/intersect/exit the inner boundary of the shape. Then the "wide part" of the document would have a "low ceiling" and "high floor" compared to the beginning and end of the document. (Also, to replicate the current experience, the footer would exist only on the far right of the canvas; and the with-header zone on the far-left would probably also have a "high floor", while the with-footer zone on the far-right would have a "low ceiling.")

But there's no real demand for this kind of fine-grained viewport control... because of the second-order chicken-and-egg problem. Even though it'd be hella neat and many designers [who almost all have two-axis-scroll-capable devices] would love to play with it.