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.
These snippets are my attempt to save and organize various bits of code, best practices, and resources relating to web development and design. They also function as a to do list of sorts, for things I want to implement in my own code, but haven’t yet. The concept is inspired by Jeremy Keith’s links and CSS-Tricks, among other things. Enjoy.
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.
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:
TL;DR: If you really need it, which you probably don’t,
readonlyis 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
readonlyare collected along with all of the normal field values in a form submission (“successful controls” in the spec). The only difference between a
readonlyfield and a regular field is the user experience.
Fields marked as
disabledare ignored when collecting values from the form. In a traditional form submission, the action page would never receive values for a
disabledfield, regardless of whether it has a
Making a link look like a button is materially dishonest. It tells users that links and buttons are the same when they’re not.
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.