At some point when reading about scope in JavaScript, you may have come across the term hoisting. It’s often used in the context of variable or function definitions.
For example, consider the following code:
In CSS, every property has what’s referred to as an initial value. Sometimes this is called the default value, but the spec uses the term initial, which I think is a slightly better term.
Technically speaking, the initial value of any given property needs to be declared only if that value is overriding a previously-defined value that’s not the initial value. But initial values are often present even when they’re not necessary.
For example, suppose I have a block-level element that I want to take up the full width of its parent. I want it to sit on its own “line”, so to speak, in the layout, so I add the following CSS:
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:
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).
A common UI pattern for a range slider is to allow the user to move the slider and display the value of it somewhere on the page, changing the displayed value as the user moves the slider.
I think the expected behaviour in such a case is that the value should display instantly, as the user is moving the slider, rather than the page waiting for the slider to finish moving before the displayed value is updated. I suppose there could be cases where you prefer a delay over instant results, but I think the expected behaviour is to display the results instantly.
As you’ll see in the videos below and in your own testing, the behaviour of the input event compared to the change event is not exactly the same in different browsers when applied to a range slider.
Slate published an interesting article on Google’s Master Plan. When I got to the bottom of the article, I noticed they had a multi-page article breadcrumb.
Oh, one of those.
Like many ad-driven websites, they split the article into two parts because it will get them more ad impressions. Okay, whatever. But what’s this?
