Unless you’ve been living under a rock for the past five years or you’re an absolute beginner to front-end coding, then you’ve probably heard of npm, and npm for beginners is a subject you’re looking into.
Maybe you’ve clicked through to the GitHub repo of a tool of some kind, and you noticed the installation instructions had a couple of different possibilities, including something like this:
A couple of years ago I wrote an article for a company called Thinkful on CSS positioning, which also included a screencast that I hosted on my ImpressiveWebs YouTube channel. The video was “unlisted” but I’ve now made it public, and since some time has passed I thought I would post the video here.
It’s pretty basic stuff for most experienced CSS developers, but if anyone wants a quick primer on CSS positioning, this should be a good guide. The video is embedded below and I’ve summarized the content here in this post.
As many of you probably know, I’ve been writing a weekly newsletter called Web Tools Weekly for over a year now. Most issues begin with a brief JavaScript tutorial, after which I include a curated list of tools primarily focused on front-end development. I’ve released a new issue every week, without a break, since July 2013 and I use MailChimp to produce the mailing (disclosure: previous link has my affiliate ID attached, which means we both get $30 towards MailChimp if you become a paying customer).
The subscriber count has grown to almost 10,000 as of this writing, and that number is growing by about 70 each week. For the past couple of months, I’ve been displaying the subscriber count on the home page, and manually editing it every once in a while.
As you might already know, CSS transitions and animations allow you to animate a specific set of CSS properties. One of the properties that cannot be animated is the display property.
It would be great if we could do it, but it’s not currently possible and I’m guessing it never will be (e.g. how would you animate to “display: table”?). But there are ways to work around it, and I’ll present one way here.
I don’t think this happens very often. To be honest, I don’t think I’ve ever used a percentage value on a top padding/margin, or a bottom padding/margin value. Even for height values, I may have used a 100% value for a hack, but nothing else.
Nonetheless, using percentages on those vertical parts of a page are somewhat different in the way they are calculated, compared to other properties that take percentage values.
As many of you know, I’ve recently launched a new weekly newsletter called Web Tools Weekly. In addition to providing a weekly, categorized list of tools for front-end developers, most issues begin with a brief tip or tutorial that usually includes code examples that have syntax highlighting.
The method I use is based on a suggestion given to me by Joshua Clanton, who writes the very cool A Drip of JavaScript newsletter. When I asked him how he embeds code in his, he directed me to a page on MailChimp’s blog along with a GitHub repo.
In addition to the unique property/value pairs that CSS offers, there are also a small handful of language-wide features that can come in handy, including a few that are brand new in the spec.
These often go unnoticed, especially by beginners, because when CSS properties and their possible values are discussed (in tutorials, books, or even in the spec), these features are usually omitted for brevity.
Here’s something interesting that you may not have realized about CSS3 transitions. Normally, you’ll see a transition declared by utilizing three different properties, either in longhand or shorthand.
In both cases, we’re explicitly declaring three of the four transition-related properties (leaving out transition-delay). Can a transition occur with less code than that? Well, yes.
As most of us probably are aware, a significant part of the HTML5 spec is the expansion of the History API.
This post will not be a super extensive discussion of this subject, especially since it’s something that I’m only now just getting into understanding better. But I thought I would put down the main components of the API, for my own quick reference, and I hope it will prove useful to my readers and those searching via Google.
For those who have studied web site accessibility, this is probably old hat. Admittedly, I haven’t spent enough time thinking about accessibility, so this is one of those things I didn’t even realize until recently. So shame on me. :)
Let’s say you have the following page, with various elements, starting with maybe a form field:
