When you can do anything, there's always that impulse to do everything. Or, at least, everything you have the means to do, whether it makes sense or not.
And yes, this ties into hVmark.

One of my favorite video game franchises is Max Payne. In 2012, Max Payne 3 came out, and I thought it was a great final chapter. Sure, it had its issues, but on the whole, it was a great gameplay experience that tied very well into the base franchise. Admittedly, for a variety of reasons, I was a bit late at getting to play it. To hold me over, I'd read and watch reviews from sources that I knew would not spoil anything. I remember seeing a positive review from a popular outlet that only had one negative critique: That it was linear. The level-based progression was considered a flaw, so besides that, it was a great game.

Of course, we're talking about 2012: Open-world games were the current hotness. If your game wasn't open-world, you better figure out how to fold it in or else you're gonna get lost in the shuffle. Later on, we'd realize (for the most part) that not every game needed to be open-world, but back then, it was seen as natural progression. Tech got better, and removed so many constraints to the point where almost anything was possible. On paper, it's freeing, until you remember that constraints are integral to game design.

Games, by their very nature, are contests inside of abstract scenarios, with very specific rules and conditions pertaining to how said contest can be won. The creative thinking involved in beating any game is part of (if not most of) the fun, which makes the dopamine hit from victory hit that much harder. Even the way games were made back in the 8-bit and 16-bit eras had their own rigid constraints, but those constraints aided in the creation of fantastic games.

Pictured: Peak Game Design

When it comes to making "better" games nowadays, video or otherwise, the impulse is always to remove constraints and add features. If the game is a sequel, these could be in service of ruining existing gameplay mechanics. Trying to strive for the idea of more being better, instead of trying to improve what you already have.

That same temptation exists in modern dev, when you're the one writing all of the rules. In the last couple of weeks, I've gotten some great feedback about hVmark. And things have been brought up that made me think about extra features I could add or changes I could make. But with every idea, I've had to reel myself back and ask a very important question:
Would this go against the spirit of hVmark?

Adding quality-of-life features to hVmark would be redundant, because hVmark itself is a quality-of-life feature of this website. A quality-of-life feature that I was initially hesitant to even start work on, strictly because I don't like adding extra code to the framework. In the beginning, I knew there would be quirks to the system; small things to work around in publishing... whatever. If I was going to add simplified formatting features, it couldn't be at the expense of the site's innocuous quirks.

Why not just make sure there are no quirks at all?
Laziness.
Because constraints in specific contexts are a good thing. The trick is, finding out what those contexts are, and working from there.

So when I decided to actively start work on hVmark, the plan was that I'd only target the HTML tags and blocks that I actually use. I could add headers, but I don't use headers on posts. I could add blockquotes (and probably will), but I typically don't use blockquotes because I suck at blogging. hVmark is automatic on posts; using it in pages takes some work, and that is very much deliberate.

hVmark is complete enough that I'm actively using it on almost every single page on this website, so for all intents and purposes, it's a completed work. Will I add more features? Probably. But the way it functions as an application, with its own added quirks and all, will not change. Or at least, it will not change so much that it becomes something new entirely. If there is an hVmark v2, the "updates" will likely include more constraints, because putting in effort on the client-side is part of it. It reduces bloat with the added benefit of making the user more mindful of what they're putting out into the ether.

If you're able to make any sense out of this digital chicken-scratch, stay tuned for more bullshit.