On form elements and JavaScript

Chris Ferdinandi of Go Make Things answers the question ”Why use a form element when submitting fields with JavaScript?” and does so quite succinctly:

  • It makes your life easier.
  • Semantics (and the accessibility that happens as a result).

From the perspective of JavaScript, he goes on to make the case for using the submit event on the <form> element to keep things not only simpler, but also a lot more usable and accessible.

His post was inspired by a question posted by Coding Journey on Twitter:

Question: If we are preventing default behavior of form submission and manually handle it (e.g. with Fetch API), is there a reason to use the <form> tag? (other than form submission with enter/return key…)

I’d say that you needn’t look further than that last sentence. There’s so many poorly designed forms out there built by developers who doesn’t know any better (seriously, I’ve seen forms in the wild that are nothing more than <div> elements with JavaScript triggers). Just the fact that you can actually submit a form in any other way than using a mouse (or tapping on a screen) goes such a long way. Proper semantics helps GUI-less applications like 1Password as well, since it looks for forms with properly named input fields and submit buttons.

Ok, so long story short — learn the basics, use proper forms.

I did dark mode for my blog

Damn my laziness. If you happen to run macOS Mojave or iOS 13, you might’ve noticed that I added support for dark mode quite a while back. Silly ’ol me didn’t write about it, even though I was quite happy with myself for utilizing CSS custom properties to simplify the theming. Both Chris Ferdinandi and Jeremy Keith beat me to it (or rather, their posts got me to finally write at least something about it).

Prefer dark mode

In the words of Mozilla Developer Network, the prefers-color-scheme CSS media feature is used to detect if the user has requested the system use a light or dark color theme. The spec is part of Media Queries Level 5 with a status of “Editors’s Draft” as of writing this post.

@media (prefers-color-scheme: dark) {
  /* Dark styles goes here */

I’m just glad that we’re (mostly?) past vendor prefixes at this point.

The power of CSS custom properties

To keep all things related to dark vs. light themes in one place, I leveraged the power of CSS custom properties. All colors that I use across the site is residing in a variables collection; /css/00_variables.css.

:root {
  color-scheme: light dark;

  --body-background: hsl(45, 40%, 94%);
  --body-text: hsl(0, 0%, 20%);

@media only screen and (prefers-color-scheme: dark) {
  :root {
    --body-background: hsl(0, 0%, 20%);
    --body-text: hsl(45, 40%, 94%);

This lets me keep only one instance of prefers-color-scheme: dark around, which is nice. All my other stylesheets just contain references to the custom properties.

body {
  background-color: var(--body-background);
  color: var(--body-text);

If you already utilize the cascade to its full potential, which luckily I have, you really shouldn’t need to change styles much. One such instance is the use of currentColor property value.

Thoughts on a modern CSS reset

I never was a fan of using someone elses CSS reset, like Normalize or even Eric Meyer’s reset.css, but this modern take of a CSS reset caught my eye for several reasons.

In this modern era of web development, we don’t really need a heavy-handed reset, or even a reset at all, because CSS browser compatibility issues are much less likely than they were in the old IE 6 days. That era was when resets such as normalize.css came about and saved us all heaps of hell. Those days are gone now and we can trust our browsers to behave more, so I think resets like that are probably mostly redundant.

The reset for lists is frickin’ genius!

/* Remove default padding */
ol[class] {
  padding: 0;

Why didn’t I think of that?

Extra bonus points for the piece by piece explanations for each section.

Further sticky bookmarklet fun

I just couldn’t leave that poor bookmarklet alone, could I? Using the previous version in the wild, I noticed some use cases where there was room for improvement. Right now my bookmarklet does two things:

  • It checks the <body> for any scroll disabling styling and tries to unset it
  • It finds any element with either position: fixed or position: sticky and deletes them

Sounds good enough, right? Well, not quite. I found one big glaring issue with this; headers. Many times, modern web sites use position: sticky for headers. If I delete them — well, then I’ve broken the site a little too much.

Based on my very scientific research following this, by visiting as many as ten web sites, I could conclude the following:

  1. Most annoying overlays and modals is positioned using position: fixed — these we can safely destroy with fire
  2. Most functional elements of a page, such as the header, uses position: fixed — these we want to keep, but away from scrolling view

These assumptions (dangerous as assumptions may be), lead me to modify the script accordingly.

const elements = document.querySelectorAll('body *');
const body = document.querySelector('body');

if (getComputedStyle(body).overflow === 'hidden') {
  body.style.overflow = 'unset';

elements.forEach(function (element) {
  if (['-webkit-sticky', 'sticky'].includes(getComputedStyle(element).position)) {
    element.style.position = 'unset';
  else if(['fixed'].includes(getComputedStyle(element).position)) {

I first check for position: sticky styled elements, and instead of removing them, I force the inline style to position: unset. This will reset to the initial value of position: static and so “un-sticky” any such elements on the page. Everything else that has position: fixed will instead just get deleted.

There are of course some caveats with this approach, mostly that older sites might still have sticky-ish headers that are positioned with the fixed property. I believe this is fine. Compared to the previous version, that just killed everything in sight, regardless of fixed or sticky, we now get something a bit more precise.

I’m beginning to have trouble coming up with good names for these bookmarklets, so this time around I’m just calling it “unSticky”. Besides, you’re completely free to name it whatever you wish.


Ok, that’s it for now. Let’s see how long I can leave this one alone.

Updated: Well that didn’t take long. My friend, Joacim de la Motte, decided to do some optimization for me. Apparently the IIFE is not really necessary, so I’ve removed it. The bookmarklet will still run without it.