How about another quick CSS post? (It’s on my mind anyway!)
This topic is one that I have had to learn the hard way, and I feel like it’s worth sharing. We need more web-based interface for doing documentation, not just displaying documentation.
That means that we need what might be called “dashboard”-style layouts.
HTML began with scrolling documents
The notion of a web “page” goes way back. Paging George Lakoff, because if you look the metaphors we use about web browsers carry connotations of sheets of paper. We “scroll” web “pages” and talk about “documents”, and so forth. And in fact, that makes perfect sense when you think about the fact that HTML first arose in a document-oriented context: one of Tim Berners-Lee and company’s primary early goals was to facilitate exchanging physics research papers at CERN.
So in a web browser, it came to pass that the way to read a document that didn’t fit in the browser window (the “viewport” in the lingo) was to simply scroll down. This is still the default. (Although it’s interesting to stop and note that “down” is relative to your writing direction — the web has fairly recently come to support languages like Mongolion, where going “down” the document means scrolling horizontally! It’s a little mind-blowing.)
Dashboards have parts that can scroll
Outside of the browser world, this metaphors applies in some classes of application — word processing is the obvious one.
But many other applications behave differently. Here’s the Activity Monitor on my Mac:
Here, the user interface “embeds” the scrolly bit. (You can see the minimalist OSX scrollbar on the right.) Come to think of it, this is actually quite similar to how browsers are arranged.
But other app interfaces scroll in complicated ways. For instance, here’s a screenshot of ELAN in use (hey @cbowern, look familiar? 
):
You can actually scroll this interface in more than one way:
And here’s the venerable Gmail interface, which echoes other desktop email user interfaces. The key thing here is that each scrollable pane can scroll independently.
It’s not like this is some surprising feature. We all use interfaces like this all day long, because they’re useful. But I’m going to go out on a limb and say that we really need more interfaces like this in language documentation. Why? Because we are constantly comparing various kinds of information, and it’s hard to do that if more than one kind of content can’t be juxtaposed onto the screen at the same time.
CSS can do that
Now, given the document-oriented origins of CSS, it’s not surprising the “scroll the whole document” interface style is the default. But over the years CSS has become incredibly powerful. As we saw yesterday, CSS grid can be used to arrange things on the page in columns as well as rows. But we didn’t talk about the scrolling question yesterday, mostly because we were using toy data. (The same Klingon sentence repeated 5 times! I was afraid to ask the speaker for more data. 
)
I’m going to stop here for now, but tomorrow I’ll take you through the CSS that can handle these dashboard-style interfaces.