Coding and Development — Getting Out There

Dont ever use in HTML... err... Wrong!

Sun, 14 Apr 2024 17:59:06 +1000

If you’ve ever Google’d the humble HTML  tag, and read more than three of the results returned, you’ll have inevitably come across the hordes of self-righteous knobs on StackExchange berating people (especially those new to HTML/CSS) for using the tag. Their reason? It’s semantically-invalid HTML. They. Are. Wrong!

The key to the  tag, or even the  for that matter (but that’s a different post for another day) is that the usage is different than what you might expect…

b is the ~~Boldface~~ Bring Attention To element¹

The  HTML element is used to draw the reader’s attention to the element’s contents, which are not otherwise granted special importance. This was formerly known as the Boldface element, and most browsers still draw the text in boldface. However, you should not use  for styling text or granting importance. If you wish to create boldface text, you should use the CSS font-weight property. If you wish to indicate an element is of special importance, you should use the  element.

That does not necessitate being bold. That is a design decision separate to the semantic one. In days of yore, b meant Boldface. This is where the angst arises, because it is automatically assumed that you’re using  because you’re ignorant of .

I use this tag liberally across my site to mark up any text where I use a brand name, e.g. Google signifies that Google is a brand name, and then I do style it subtly differently (I switch out the serif font for the sans-serif and italicise) but importantly: that does not mean I am using it for that function. All I am doing by adding it to my HTML is saying that this text may need to be marked up as standing somewhat different to its surrounding context. What I do in the stylesheet afterwards is not a determinant of its validity as HTML markup.

My stylesheet declaring that

b.brand { font-family: sans-serif; font-style: italic; }
is purely decorative and has no semantic meaning to the original markup. I might decide one day to not treat brand names any different from the surrounding text, and if I was to remove that stylesheet, my markup would remain perfectly valid. Or I could just remove the font-style: italic style:

b.brand { font-family: sans-serif; font-style: italic; }
Some browsers still render  as bold,  as italicised, but that’s easily solved with a reset style in the root of your stylesheet, and it’s the browser’s fault and problem, not yours.

So the next time you get berated (or find yourself about to do the berating) take a moment to first discern the reason that page is marked up the way it is. Maybe drawing some attention to that element is correct, and you’re merely arguing about the stylistic choices of your fellows.

Definition from mdn web docs ↩︎

Rant:
Why the rant? I use all over the site and some goose had at me about it.

Transitioning from Wordpress to Hugo

Tue, 14 Nov 2023 09:52:00 +1100

I have, for the past few years, run a little personal blog on Wordpress called “Getting Out There”. Over the years I’ve hosted it at different hosts and domains, and added to it much the same as one might build extra rooms to a renovated house. I’ve run a little WooCommerce, added GravityForms and custom post types and photos and before you know it, the bloat is very, very real. With that bloat comes more hosting costs, which for a little personal blog that I am certain nobody reads, is unsustainable.

Here’s the catch: I love Wordpress. I’ve developed Wordpress themes from scratch, have built, maintained and then long-forgotten plugins, and have adored how close I was able to blend my loves of back- and front-end web design and development. Some years ago I moved from my own custom theme to one called Impreza, by US Themes. If you need a professional, highly capable and customisable Wordpress theme that just does everything you could possibly need, then Impreza is for you. I have held dozens of licenses for this theme. Adore.

So whilst I recognised the dire need to Marie Kondo my blog [I actually really detest the commercial drive behind the craze that is ~~KonMari~~ ruthlessly throwing things away, just to buy some Scandinavian shit to replace it and make your home look like the ones on Instagram. Maybe another blog post for another day… In the meantime, I’m referring to: https://konmari.com/], I still wanted to keep some flash. Additionally, or perhaps most critically, I love the front- and back-end maintenance of my blog as a pleasure in and of itself: whilst in one way I love that you’re reading this — thank you for honouring me with your presence, Esteemed Guest 🙏 🙇‍♂️ — I truly do not care if anybody reads my blog at all. I like having somewhere to drop my thoughts, collect my adventures, post some photos, and provide a web geek’s playground.

So I started to look at a static site generator (SSG). If you don’t know what a SSG [SSG: static site generator] is, I have two suppositions to make:

You should go Google that.

You may not actually be that interested in this post. You’ve been warned. 😆

I have yet to delve professionally into static site “JAM [JAM: Javascript, API and markup]stacks”, the tech I use at work utilises them but I’ve never configured or set it up myself. I decided to have a crack at Hugo after reading a few subreddits and declaring myself familiar with what Hugo has to offer. I also took a look at a few different frameworks for the CSS [CSS: cascading style sheets], as I decided at the outset not to use a theme. I’m doin’ this meself.

The key criteria I have for the technologies I’ve considered are:

It must be open source.

No cookies or invasions of my readers’ privacy. You’re welcome.

No over-reliance on one particular platform.

For example, I do not want to maintain huge package.json files due to every framework’s answer being:

npm install this-small-two-lines-of-code-plugin

No, I won’t just npm it. First tell me: “Why?!”

Of course, building something “on Hugo and TailwindCSS” means the platform is a key integrated component, but I want to be able to move my content elsewhere when I inevitably bore of Hugo and move to the next thing. I am a fickle bastard.

That said above, no stupid abstractions or religious adherence to DRY [DRY: don't repeat yourself] principles.

Some things in my site are hard-coded and definitely not content-agnostic. Why? It’s easier. I can always re-do the copyright notice in the next site I build.

The answer to every question is not always a huge YAML [YAML: Yet Another Markup Language] file and another layer of the stack.

DRY has kept food on many a developer’s table, much as lawyers adore complainants fighting a case on “the principle of the thing”.

In the end, I decided upon the following:

Hugo to generate the site.

TailwindCSS to generate the CSS.

Gulp to handle the Javascript, SVG [SVG: Scalable Vector Graphics] and any SCSS [SCSS: SASSy cascading style sheets] that isn’t Tailwind.

Git for version control.

One main repository for the site code and logic.

Another repository as a git submodule for the content.

~~Gitea for hosting my git repository.~~ Self-hosting my git repository on an instance of Charm’s Soft Serve.

~~DroneCI for building “production Hugo”.~~ I built a little Raspberry Pi-powered single board computer to build my Hugo site when not at my desk (i.e. on the bike, at work, travelling, etc…).

A DigitalOcean droplet for hosting the files. I’m aware I can use cheaper GitHub Pages et al. but I both don’t mind paying for the occasional bit of hosting and importantly: I may want to add some dynamic elements (such as PHP [PHP: PHP: Hypertext Preprocessor] forms, et cetera) at a later date. No stupid abstractions, remember?