@font-face helper is designed to let authors install custom fonts directly into a style sheet without writing out the entire
@font-face declaration that looks something like the following…
I’ve always been on the fence when it comes to using a GUI over the CLI to transfer/update files on a remote server. For the majority of my work I use Fetch when I need to transfer or grab single files and sometimes I will even go as far as mirroring with Fetch to sync entire projects. There are better ways for sure, but I really wanted to see what else is out there and the benefits of each method/tool available (ones that don’t use a GUI at all!). I decided to take to the tweeters in hopes that other developers would provide me with some feedback/opinions.
“Hey you, Sass developers who use variables for media queries! How do you decide what to name the media queries?” It’s a pretty common question in programming languages other than Sass, and one that is always the toughest to decide.
When Chris Van Patten asked in this tweet there were a few replies. Some answers assorted and some similar. If you aren’t aware of Chris Coyier’s post on naming conventions then be sure to check that out before reading further. It’s what I call “the bear approach.”
As you can tell from the title of this post we’re gonna talk about retina and most importantly, that it’s not called retina. Why you ask? Well, because it’s a buzzword from Apple so instead let’s call it HiDPI because that’s more appropriate, but even then I still don’t like that term. The reason is “dpi” actually stands for “dots per inch” and our screens are in pixels…or at least that’s how I think of them as. I would rather call it HiPPI which replaces “dots per inch” with “pixels per inch.” DPI is used by printers so that’s why it always confuses the hell out of me when we talk about computer screens.
WARNING! I use a Mac so these comments and examples are from the point of view of a Mac owner.
Setting up an environment with the required dependencies can be a chore to be blunt. Here’s a rundown of the best approaches to keep these dependencies in place once they’re installed. This is not an article about installation, but what to do once they are installed and maybe a few hot items/points of interest to enhance your experience. As a FRED these days you’ll certainly run into a project that may have node or may use Ruby and knowing how to operate in these environments plus keep them updated can be a huge advantage to you or your team members.
Reading specs is hard. There I said it, but it’s not like it hasn’t been said before by the bajillion other developers out there and today is no different for me. I’ve been doing some writing lately that requires me to conduct research within the actual documentation which brings our work to life. It’s also the content we search heavily for on blogs that help interpret it for us to digest.
As we all know the majority of the Web development community uses Git or Github in some way or fashion. The funny part to the whole story is the fact that most developers don’t even know what version they’re using.
Now, before I get up on my high horse here I’ll preface everything by saying I was in the same boat as the rest of you. Sadly, making sure my version of Git is up to date is the last thing on my mind. Thankfully I’ve grown up since those troubled days and now know the value of keeping Git up to date and using the best techniques to keep it that way.