HTML5 includes a JavaScript method that is a cousin of document.getElementById and object.getElementsByTagName. I refer to object.getElementsByClassName, which is attached to the document object and every element object. The utility of such a method is obvious, and every major browser but one has implemented this method for several years now. The outsider? Internet Explorer, which will not implement this method until Version 9 (currently in beta).
In this post, I replicate this method and show how to bind it to the document object of any browser that does not already support it, and to every element currently in the DOM. There’s a lot going on here, so, except for a few remarks up front, I provide no additional commentary. Please copy and paste the code that follows as you see fit. Read the complete entry »
For this post, I’ll assume you know AJAX pretty well. I’ll also assume that somewhere in your readystate callback function you have code that looks kinda like this:
1
2
3
4
5
| if (AJAX.status == 200) {
// do something
} else {
alert("Server error " + AJAX.status + ". Please try again.");
} |
Or maybe you’re using jQuery, and all that stuff is under the hood.
The point is, a normal AJAX request only notifies you about parsing errors, fatal errors, missing page errors, and stuff like that. These are automatically generated server errors, the kinds that return error codes like 404 or the dreaded 500.
But other kinds of things go wrong all the time. Is there a slick and graceful way to handle those kind of errors? You bet.
Read the complete entry »
If your server is online, you probably have error-reporting turned off. (Users get annoyed by error reports.) We all know how to add error-reporting to a single script. But that only works for run-time errors. Parsing errors, like missing braces or semicolons, cannot be reported, because a script that won’t parse will not be executed; therefore, the statements that turn on error-reporting will not be executed. (A lot of people don’t get that. I don’t know why.)
This simple shell script solves the problem. Read the complete entry »
One of the most common questions a consultant hears these days is, “How can I use the same header and footer in all my files without pasting the same code over and over?” Read the complete entry »
A lot of web developers are essentially hobbyists. They run fan sites for games or anime, sites for model railroad collectors, sites about classic cars. You name it, there’s a site for it. A lot of sites, even hobbyist sites, use a registration system to limit membership to friends and family, facilitate mailings, eliminate spam, whatever. A registration system generally consists of usernames, passwords, identifying information like email or physical addresses, birthdates, and so on, all stored on a database.
If you run a small site with a hundred or so members, you probably don’t think about security very much. Why would you? You store no credit card information, no driver license data, nothing sensitive at all. As for hackers, that’s up to your hosting service, right?
Well, mostly. Read the complete entry »
el is a div element contained by daddy, which is also a div. daddy contains a lot of other elements too. Some of them are div elements; others are not. Some contain div elements of their own.
A tree diagram of daddy and its descendants might look like this:
div (daddy)
|
------------------------------------------
| | | | | | |
div (el) div div div p p img
| |
---------- |
| | |
div div divYour application needs a collection of div elements that are siblings of el. (For the rest of this tutorial, I will refer to these as same-siblings. The collection should not contain any of the following:
- elements that are not
div elements
- descendants of
el or el's siblings
- ancestors of
el
The question for today is this: How do we build such a collection? Or, more generically, given any page element, how do we build a collection of siblings that are the same kind of element? Read the complete entry »
You’ve seen this gadget a thousand times. Two select elements sit side by side. Let’s call them the source and the target. When the user selects an option in the source, every option in the target gets updated. In a recent consultation, I worked on a source-target gadget in which the user first selects a country, and then selects a city in that country. So, for example, if the user selects France in the source, the target updates so that it only contains the names of French cities. Selecting Germany updates the target so that it only contains the names of German cities. Got the idea?
There are many techniques for making this gadget work. Most of them are JavaScript-intensive and require a lot of DOM manipulation. Now, I’ll be the first to say that there is nothing inherently wrong with manipulating the DOM. I’ve written plenty of pages that manipulate the DOM extensively. But it’s a costly process. DOM manipulation is the slowest thing that JavaScript does. Changing the contents of a select element is especially slow—so slow, in fact, that older computers may experience screen flicker. My point is simply this: if we can avoid DOM manipulation, we probably should.
My version of the source-target gadget mixes JavaScript with CSS to keep DOM access to an absolute minimum. It requires more HTML than other techniques, but the JavaScript is very fast. Read the complete entry »
The <textarea> element is nearly unique among form controls. While any type of <input> element supports a value attribute in its tag, the <textarea> element does not. To set the initial value of a <textarea>, you must place text between the element’s opening and closing tags.
1
| <textarea id="txt">Some content here</textarea> |
The difference is trivial from an HTML perspective, but it creates a lot of confusion for JavaScript developers. In today’s post, I’ll try to put some of that confusion to rest. Read the complete entry »
I’ve spent the last few days investigating the way JavaScript interfaces with CSS, and I’ve decided that a few more words on the subject might come in handy. The information is certainly out there, but you really have to scratch for it, and I haven’t seen it discussed in many places. So here is a brief overview of some things that I’ve learned. Read the complete entry »
When you access a CSS color property through getComputedStyle() or element.currentStyle (look here, for example) the value may take on a variety of formats, depending on the browser and the CSS definition. Let’s say your CSS defines an element’s foreground color as blue. If you attempt to read the element’s color property, any of the following values might be returned:
1
2
3
4
| #0000ff
#00f
rgb(0, 0, 255)
blue |
This presents a challenge to the developer who wants to compare a returned value with a stored value. What do you do when your CSS defines a color as #00f, but Opera returns the value as #0000ff, and Firefox returns it as rgb(0, 0, 255)?
One solution is to use compound conditionals:
if (myColor == "#00f" || myColor == "#0000ff" || myColor == "rgb(0, 0, 255)" || myColor == "blue") { . . .which you must admit is pretty ugly.
A less intrusive solution is to normalize the returned value. That is to say: no matter how a color is defined in CSS, and no matter which browser interprets that definition, the returned value will always be formatted the same way.
Normalizing color values is the purpose of color2hex. Read the complete entry »