After my last post, therealadam posted about some Low-key CSS libraries. These are small CSS libraries which don't do anything much more than style your baseline HTML elements.
Which was perfect for the current state of my site since I stripped my own styles away. I've gone with new.css as it's decently close to what I'm aiming for although I do plan to go with my own custom CSS long-term. This works until I actually start working on that to have something.
That said, let's start with the intent of this post which is the HTML structure of my header and footer sections.
Footer
The footer is really simple. I don't think it needs to change.
A literal line of copy. If anything, I'm just not sure if the copyright should be me personally or Updrift, but I'll check that out later as that doesn't really pertain to the HTML structure.
Header
There's a bit more to the header section. I'll exclude the skip to content link, as that exists outside the header.
There are three different things that are kind of related.
Logo / nav link to the home page
Actual nav links to the main areas of the site
Search form
The logo is technically navigation, so It should be included in the nav block. I'll move that into the unordered list that's a child of that element. As it's a secondary link to the home page, I'll go by the W3C recommendations for functional images and set the alt value to an empty string since it performs the same function as the Home link. I'm leaving the Home link as it's text that can be read by a screen reader.
Speaking of the unordered list (ul), I feel it's appropriate because it literally is a list of nav items. The nav element itself gives me enough of a hook for styling that I shouldn't need any additional classes except for a selected class that goes on the li tag if you're on the About or Contact pages.
The search form is also navigation related in the sense that it will take you to a different page.
That's not a drastic change from what I had. Ironically, having an empty alt tag on the logo is flagged by accessibility checkers, however, I'm doing exactly what W3C recommends so I'll go with W3C for now.
I know there's likely a bit of aria attributes I should add, but I'll defer that to a broader accessibility effort later on.
Next up, I'll look at the main content which, for this site, would be blog post content.
With this post, I'm going to remove the styles from the site completely and focus on the HTML elements and structure alone.
For now, I'll focus on the HTML elements for the overall page alone then dive into the individual parts in future posts.
For posterity, here's what my current site's home page looks like with a bit cut out so we can see the top/bottom of the page.
Removing the styles, I fortunately have something that's still functional and not a complete mess. Things will just be a bit unstyled for a while as I work through things. If I actually have any followers anymore, they likely read my stuff through an RSS feed and the styling doesn't matter anyway.
This isn't really the best. Looking at current HTML documentation, I should probably replace the page section with a main element, and the sidebar section with an aside element that exists within the main element.
Additionally, as stated in the main element's HTML documentation, adding an id to it allows it to be a target for a skip navigation link. I want that, so I'll go ahead and add it along with the skip link at the top of the document.
I'm not sure if I'll need the class for the footer element. So I'll drop that for now and add it if needed later.
Resulting Page Structure
This leaves us with a much more modern html structure.
First, let's examine what's in the <head> area of my current site. Note that whatever's wrapped in {{ }} tags is Craft CMS code.
<!DOCTYPE html>
<html lang="{{ craft.app.language }}">
<head>
<!-- Internet Explorer? Well, won't need this! -->
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<!-- Next part is pretty standard. -->
<meta charset="utf-8" />
<title>{{ siteName }}</title>
<meta http-equiv="Content-Type" content="text/html; charset={charset}" />
<meta name="description" content="{{ craft.app.globals().getSetByHandle('siteInfo').siteDescription }}" />
<meta name="keywords" content="Wade, Winningham, Wade Winningham, Updrift, Ruby on Rails, PHP, MySQL, Craft CMS, HTML" />
<meta name="author" content="Wade Winningham" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, viewport-fit=cover" />
<meta name="referrer" content="origin-when-cross-origin" />
<link rel="shortcut icon" href="/favicon.ico" />
<link rel="manifest" href="/site.webmanifest">
<!-- Links to rss/atom feeds for those who use RSS Readers -->
<link rel="alternate" type="application/rss+xml" href="{{ url('feed.rss') }}">
<link rel="alternate" type="application/atom+xml" href="{{ url('feed.atom') }}">
<!-- Link to an Adobe webfont. I'll drop this in the redesign. -->
<link rel="stylesheet" href="https://use.typekit.net/mbc8gkz.css">
<!-- CraftCMS embedding the css file -->
{% set stylesheet = rev('main.css') %}
{% if stylesheet %}
<link rel="stylesheet" href="/{{ rev('main.css') }}">
{% endif %}
<!-- The rest of this is page view tracking for Matomo -->
<!-- which I host myself rather than use Google -->
<script>
var _paq = window._paq = window._paq || [];
/* tracker methods like "setCustomDimension" should be called before "trackPageView" */
_paq.push(['trackPageView']);
_paq.push(['enableLinkTracking']);
(function() {
var u="//updrift.com/matomo/";
_paq.push(['setTrackerUrl', u+'matomo.php']);
_paq.push(['setSiteId', '1']);
var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
})();
</script>
</head>
Referrer
Based on the info in this article on referrer best practices, one meaningful change I can make is to set my referrer policy to strict-origin-when-cross-origin for the reasons within that post.
While that seems to be the default for most browsers today, it's not guaranteed, so seems best to be explicit.
Viewport
The viewport value is stale. Been forever since I'd have set that. One item, the user-scalable=no can be bad as the documentation indicates it can cause accessibility issues. Which makes sense as it doesn't allow for scaling the screen for those with visibility issues.
So I'll reset that to a safer value of width=device-width, initial-scale=1 and can adjust it if necessary when I get more into the layout and design later.
Manifest
A site.webmanifest file isn't required, but nice for Android devices. So I'll keep it basic.
{
"name": "Updrift",
"short_name": "Updrift",
"description": "A blog from Wade Winningham on tech, development, and building web sites and appliations.",
"icons": [
{ "src": "/icon-192.png", "type": "image/png", "sizes": "192x192" },
{ "src": "/icon-512.png", "type": "image/png", "sizes": "512x512" }
]
}
