The fewer categories you have, the easier it is to keep things sorted.
If you have one shelf for plates and another for cutlery, it’s gonna be easier to stick to that than if you have one for forks, one for tablespoons, one for teaspoons etc.
Too few categories, and it’s not useful; it’s not sorting at all. It’s just one big silo. Arguably that’s how I keep a lot of my files, both digitally and physically, and I can still find stuff… most of the time.
If we want useful sorting, we need a lagom amount of categories—not too many so that people don’t sort things properly, not too few that there is no order at all.
The web erred into creating overly fine-grained semantics. Most people
don’t know how to use them correctly; even technical editors and
implementers struggle, let alone normal people end-users.
It feels messed up to ask people to keep track of three different
kinds of italics or a whole bunch of different bold (b, strong,
headers, dt, th).
That’s not a natural part of how many people think and write, outside of language-nerdery.
They turned it up to eleven in 1999 and made the already–too–fine-grained semantics even more semantic for the benefits of the machine overlords, which in 2023 doesn’t seem like a very appealing idea. But even before “the Semantic Web” we were in trouble with overly detailed sorting of stuff.
This is why I’m not into microformats. I use them only when they serve an immediate purpose or practical need.
In case you don’t know what Gemini is… it’s sort of like these toys but for the early 90s web.
Gemini’s semantics strike more of a sweetspot. Headers, text, and code, and that’s pretty much it. There are a handful of ways people can get it wrong (metaphorically jamming a plate into the cutlery drawer—things like hardwrapping or using unicode bold scripts or out-of-order header levels) but in practice people are doing much better than they were on the web, and long-time dreams like keeping styling client-side are finally becoming realized.
When Microsoft Word in the late nineties realized the limits of WYSIWYG and belatedly introduced a way to mark text as “header 1”, “header 2”, I thought “this isn’t gonna work”—since all the old formatting widgets and options were still there, and were more readily available.
People were like “Oooh this part should be sans and big and then this part should be serif and not big! I’m a typographer, ma!” and then when you wanted to republish that text in a different magazine or on the web you were out of luck because headers weren’t set as headers. We’ve all had the stubborn user who would mark text as “big and bold” instead of actually marking it as a header. Classic example. Or would use h5 instead of h1 because “it looks nicer”. A lot of us reacted with frustration. “Why can’t these lusers learn to mark things up semantically and trust the style sheet to make headers look big and bold for them?”
I don’t think that’s the right takeaway. The user experience is the problem, and the user’s behavior is just a consequence of that.
Gemini solves that issue by not having big or bold.
Semantics and style are different things. That’s the entire point of
what we’re doing here: some wanna set headers bold, others wanna make
them italic, others wanna make them red or centered or tilted or
uppercase or underlined. Some wanna use 22 point fonts for them,
others wanna use 23 points. <i> means “offset from prose”, not
“italic”.
But semantics need to have some impact on the style for people to bother. People use language to express themselves and style is a way to do that.
When there is semantic markup that people can’t immediately feel, they won’t use it. Style is their interface for understanding semantics.
Map semantics to style in a one-to-one way and you can get them to write semantically, in a way that’s really independent from style.
Maybe you really do need four different kinds of asides or six different flavors of italics because you’re writing a highly technical textbook. That’s OK. You don’t need to use gemtext for those documents.
Gemtext is easy to convert to, so if you want to make a super lossy export target for gemtext, you can. That’s what I do for this web page.
And if you wanna keep things simple and just write in gemtext directly, you can do that too.
I usually don’t even go on Gemini directly. I read gemlogs that have been converted to Atom. And since gemtext expresses such simple semantics so consistently, the converted feeds are among my most well-behaved feeds.
Gemini doesn’t make the web less complicated or remove any cruft from the web (since the web is still there, with all its diamonds and rust); it only adds to what the web can do. But what it adds is something pretty nifty: living the semantic dream. Simple text expressed simply.