If you’ve been writing CSS for some time, then you’ve certainly done something similar to the following, and likely multiple times in a single stylesheet:
The lone declaration in the rule set above is what’s commonly referred to as a font stack. This line defines the font that the browser should use for the specified element (in this case, for the <body> element). The stack is “Arial, Helvetica, sans-serif”. This instructs the browser to take the following steps:
In most cases, you should not use a leading or trailing space in an HTML attribute value. For example, if you add a leading or trailing space to an ID attribute, you wouldn’t be able to hook into that value in CSS using the ID selector (not that you use IDs as selectors, right?):
This happens because spaces are not allowed in an ID selector. But interestingly, there is a way around that using CSS’s attribute selector:
As you probably know, there are a number of HTML attributes that are considered global because they can be applied to any HTML element. Common examples include class, id, style, and tabindex.
One that was added a number of years ago in HTML5, and you may have forgotten about, is used on two elements in the following code:
There are two things here that you’re probably already aware of. First, HTML includes an <output> element that allows you to display the “result of a calculation”. It’s a form element and it’s been around for some time, having been added in HTML5.
The other thing you’re likely to be aware of is that the for attribute is normally used on the <label> element to associate a <label> with a form element. This aids accessibility and usability, as you’ve probably discovered as both a developer and a user. But interestingly, the for attribute can also be used on the <output> element:
This just in: Web developers are easily swayed by tentacled sea creatures. But wait, I’m getting ahead of myself. I’ll get back to that in a moment.
Caching and cache-busting front-end resources have been common for a number of years now. When dealing with front-end resources, you want to be able to accomplish two things:
Back in 2014 a couple of developers launched a website called You Might Not Need jQuery that listed alternatives to jQuery features using vanilla JavaScript and DOM techniques, along with browser support. The site was shared quite a bit in the community.
In response, a couple of other developers released a Google doc that explains why you should not be too quick to drop jQuery without careful consideration of all the problems it overcomes.
In this post, based on some instructions in that Google doc, I’ll describe how you can examine the DOM bugs and incompatibilities that jQuery attempts to address.
If you’re new to web development and have some basic knowledge of HTML, CSS, and possibly a little bit of JavaScript, a practical area in which to expand your front-end skills is JSON.
But even if you already have a basic understanding of what JSON is and have used it in some of your projects, there might be a few things you weren’t aware of. So in this JSON tutorial and guide, I’m attempting to provide a fairly comprehensive discussion of JSON, its history, and its usefulness. I’ll close with a list of some practical JSON tools that might come in handy in future projects.
Unless you’ve been under a transpiler-sized rock for the past five years or you’re an absolute beginner to front-end coding, then you’ve probably heard of npm.
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:
Since July 2013, I’ve curated a weekly newsletter called Web Tools Weekly. It’s been my primary side project which, admittedly, has taken time away from this blog. I’m planning to be more active on Impressive Webs again this year, but I felt it was time for a fresh new design for the newsletter. The new design launches in this week’s issue.
The redesign was done by a local friend of mine, Priscilla Di Carlo. Although I could have put something together myself, I don’t consider myself a true designer, so I preferred to pay someone to give it a fresh look. Priscilla is mostly a print designer, but since this is email design, I feel like that’s an advantage more than anything.
One thing that’s common in development blog posts and documentation is the use of HTML’s <code> tags to mark up code snippets inline and in large blocks (the latter of which is usually done along with <pre> tags).
One of the problems that occurs with styling of <code> tags, however, is when they’re used inline inside of links (or <a> elements).