Chrome has been my default browser for many years now, but I’ve been thinking that my familiarity with just one browser has become a problem. If I tend to design for a single browser, then I’ll start to make assumptions that those features are available for everyone. Then I’m likely to miss important differences between browsers which could introduce bugs into the codebase or influence the amount of time I spend designing a feature.
I’ve started to call this problem “Chrome Bias”, and over the past week, I decided I would do something about it by switching to Firefox. This way I could figure out what’s new in one of the most popular web browsers out there. But! While I was running this little experiment of mine, I found three Firefox features that you might not know about if you suffer from extreme Chrome Bias like I do.
Let's say you manage a WordPress site. You chose, purchase, and install a pre-made theme. Say you added a few items you came across in the WordPress plugin directory to add some advanced features to the site. This is the awesomeness that is the WordPress ecosystem. It's relatively easy for anyone with light technical chops to get a website off the ground and wrangle together something powerful without having to build everything from scratch. It just works great and your website looks wonderful.
Scaling our websites and applications so that they look great on every screen can be difficult. A big portion of that difficulty can be trying to get specific components, particularly ones that have pieces that have to stay a certain size (like animations), to look good regardless of the screen size. In this post, we'll cover how to help keep our responsive animations sized the way we want them.
Which amounts to pretty much: "Don't use them". Notice there are no examples of good use cases, and even the examples in the "Do" graphics just say "Placeholder Text", which isn't exactly demonstrative of usefulness.
I wonder if placeholder text will fall completely out of favor.
It reminds me of float labels. Float labels were a fun little fling, but they aren't actually useful. The reason you'd reach for them is when you're so space-limited that you can't show a regular label beside the input. But you can't actually ever remove the label, just move it. So if the label is still there and readable, why not just leave it there the whole time?
Kevin Suttle on the ever-growing number of .dotfiles in projects:
The number of config files per repo is slowly but surely overtaking the number of code files.
Seems to me /config/ or /.config/ as a directory to keep them are also too overloaded to be a real solution. I agree: "something’s gotta give at some point."
In one fell swoop you can set the size of a display heading to be proportional to the screen or browser width, rather than choosing from a scale in a series of media queries.
Both are all about leveraging viewport units to size type that doesn't jump from size to size at breakpoints, but gracefully scales.
I'd highly recommend checking out Mike Riethmuller's Fluid type though, which is nearly just as simple but allows for setting minimum and maximum sizes, which feels like the way to go for me.
