The war against sticky toolbars continue

The wars against sticky toolbars, annoying overlays, unwarranted modals and scroll-locking continues. It’s a never-ending war of attrition. It’s been close to a year since I last updated my bookmarklet and since, I’ve come across more annoying ways to mess with the user experience on different websites.

Scenarios that my bookmarklet didn’t handle:

  • Setting overflow: hidden !important thus escalating the specificity wars further (my original script just set overflow: unset; which didn’t override !important styles)
  • The above styling was not just set on the <body> element, but also the <html> element, sometimes at the same time to really make sure that the poor user can’t scroll

No need to beat around the bush, this is the updated script.

const elements = document.querySelectorAll('body *');
const containers = document.querySelectorAll('html, body');

containers.forEach(el => {
  if (getComputedStyle(el).overflow === 'hidden') { ('overflow', 'unset', 'important');

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

The biggest changes are that I had to use instead of in order to also set !important. In addition, I’m also checking for that styling on the <html> element and unset it there if needed.

As always, below is the packaged bookmarklet for you to drag into your own bookmarks. This time featuring a cool emoji, fitting the situation.

☠️ unSticky

Big thanks to Joacim de la Motte for providing valuable feedback and helping me improve the script.

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.