Snippets

Dark Patterns are tricks used in websites and apps that make you buy or sign up for things that you didn’t mean to. The purpose of this site is to spread awareness and to shame companies that use them.

console.log is no debugger. It’s great for figuring out what your JavaScript app is up to, but it’s limited to spitting out a minimal amount of information. If your code is complex, you’ll need a proper debugger. That’s why we’ve added a new section to the Firefox Devtools Playground that’s all about debugging. We’ve built four basic lessons that use the Firefox Debugger to examine and repair a simple JavaScript to-do app.

Need a quick way to generate the necessary icons for your site, from the lowly favicon.ico to high resolution icons? I found this really helpful:

No hard decision

With so many platforms and icons, it’s hard to know exactly what you should do. What are the dimensions of favicon.ico? How many Touch icons do I need? RealFaviconGenerator did the reseach and testing for you.

Done in 5 minutes

You spent hours on design, colors, graphics… How much time left for the favicon? Probably not much. But no worries, you only need a few minutes to tackle this task.

Compelling design, a platform at a time

Each platform comes with its own design requirements. You can’t just use the same picture everywhere. RealFaviconGenerator knows this and lets you craft your icons platform per platform.

Instant feedback

How will Android display my icon? How will iOS round my Touch icon? No more guesswork. RealFaviconGenerator instantly shows you how your icons will look like.

Do you want a deep and nerdy dive into the web browser rendering and how the upcoming WebRender rendering engine for Firefox will use the GPU more like games currently do?

[T]here’s another big piece of Servo technology that’s not in Firefox Quantum quite yet, though it’s coming soon. That’s WebRender, which is being added to Firefox as part of the Quantum Render project.

Web forms are complex beasts. There are a lot of field types to remember, each with dozens of attributes. It’s hard to know which is the right way to go, especially when presented with a choice between two seemingly similar options for disallowing a field to be edited: disabled and readonly.

TL;DR: If you really need it, which you probably don’t, readonly is what you want.

[…]

The Key Difference

So why do we have two attributes that do the same thing? Unfortunately this is where developers often get confused: the user experience is the same, but the mechanics are quite different.

Fields marked as readonly are collected along with all of the normal field values in a form submission (“successful controls” in the spec). The only difference between a readonly field and a regular field is the user experience.

Fields marked as disabled are ignored when collecting values from the form. In a traditional form submission, the action page would never receive values for a disabled field, regardless of whether it has a name attribute.

In Resilient Web Design Jeremy Keith discusses the idea of material honesty. He says that “one material should not be used as a substitute for another, otherwise the end result is deceptive”.

Making a link look like a button is materially dishonest. It tells users that links and buttons are the same when they’re not.

In Buttons In Design Systems Nathan Curtis says that we should distinguish links from buttons because “button behaviours bring a whole host of distinct considerations from your simple anchor tag”.

For example, we can open a link in a new tab, copy the address or bookmark it for later. All of which we can’t do with buttons.

A quick overview of new JavaScript features in ES2015, ES2016, ES2017 and beyond.