Considering viewports

Posted on

Following yesterdays Apple event, I spent the morning perusing my RSS feed, as I do most mornings. One of the articles from developer Michael Tsai pondered the screen sizes of the new iPhone models. He compiled a list of most available models (including the older 5s/SE that’s no longer as easy to buy) and their viewport sizes in CSS pixels, or the unit he chose to describe them with; points.

iPhone Model Width Height
5s/SE 320 pts 568 pts
12 mini 360 pts 780 pts
8/SE 2 375 pts 667 pts
11 Pro 375 pts 812 pts
12/12 Pro 390 pts 844 pts
XR/11/11 Pro Max 414 pts 896 pts
12 Pro Max 428 pts 926 pts

The iPhone 12 Mini is the model that I believe will be the “people’s iPhone”. That is to say, it’ll most likely be the top seller. With that in mind, it’s interesting to note the width of the device. 360 CSS pixels. I’ve noticed in my day job that our designers have designed with the iPhone 8/SE 2 in mind, that is to say that they make their most narrow designs 375 CSS pixels. While that might be a problem in and of itself since there’s still plenty of devices out there that is reporting 320 CSS pixels and you should cater to these too, it’s interesting to note that our designers will at least have to shave off 15 CSS pixels in their future designs, since this will very likely be the majority for the future.

Then again, if we all just built stuff fully flexible and did not cater to a specific minimum viewport, this wouldn’t be a problem at all.

The war against sticky toolbars continue

Posted on

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') {
    el.style.setProperty ('overflow', 'unset', 'important');
  }
});

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

The biggest changes are that I had to use body.style.setProperty instead of body.style.overflow 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!

Posted on

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)

Posted on

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

Posted on

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.

Older posts Newer posts