Happy CSS Naked Day!

Today is April 9, which means that it’s CSS Naked Day! Never heard of it? It basically means that if you have a website, you should strip it of its CSS.

Why on earth would you do that?

Well, if you know your stuff, you should author your markup before doing any styling. This is unfortunately something that most developers almost never do, which is a sad thing. The information architecture of a website should be good enough that no styling should be required to be able to use the site. That’s the whole point of CSS Naked Day.

So, how did my site fare?

Facebook discovers that native is better (updated)

The engineers over at Facebook rolled out a new Messenger app and later on posted a blog about the project, dubbed Project LightSpeed.

  • We are excited to begin rolling out the new version of Messenger on iOS. To make the Messenger iOS app faster, smaller, and simpler, we rebuilt the architecture and rewrote the entire codebase, which is an incredibly rare undertaking and involved engineers from across the company.
  • Compared with the previous iOS version, this new Messenger is twice as fast to start and is one-fourth the size. We reduced core Messenger code by 84 percent, from more than 1.7M lines to 360,000.
  • We accomplished this by using the native OS wherever possible, reusing the UI with dynamic templates powered by SQLite, using SQLite as a universal system, and building a server broker to operate as a universal gateway between Messenger and its server features.

What’s gotten people’s attention online is that they seem to have accomplished this by axing React Native and going (possibly mostly) full native. The reaction has been just what you’d expect; no shit, Sherlock. I love the web and (at least most of) it’s many technologies. These days you can accomplish amazing things with HTML, CSS and JavaScript.

But web just can’t compete with native.

I’m not going to stick my neck out and say that it never will, but I honestly don’t see that happening for many years to come. Plus, as front end developer since the 90s, I don’t see web technologies as the correct set of tools for building such apps. I loathe Electron and other stuff that’s not native to Mac, for example. I feel the same way about iOS as well. I want snappy, responsive and native apps on all my platforms. Looks like the engineers over at Facebook wants that too.

Updated: The Messenger app was apparently native before the rewrite as well, so the title of this post is pretty off target. My point about native vs. web still stands, though.

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.