One of the components of Scatterpress is a javascript library that works with Prototype to make online forms more pleasant to use. For example, adding selection-dependent content to a form requires showing or hiding a page element based on whether a checkbox or radio button is checked. Ordinarily, we’d just specify an onclick attribute for the checkbox which would set the display of the page element to block (or inline) if the box is checked, to none if it isn’t.

But the Scatterpress front-end tools are all about progressive enhancement, and whenever possible they follow this principle: Use classnames to describe behavior; add behavior based on classnames. It’s the same idea behind the Behaviour library; all we’ve done is abstracted some of the attachable behaviors into libraries, and standardized a bunch of classnames which will produce those behaviors.

For selection-dependent content, the classnames will be show_if_checked and hide_if_checked, where checked is the id of a checkable element, i.e. a checkbox or radio button. To implement the account field in Luke Wroblewski’s example, we’d write markup like this:

<div>
    <input type="radio" id="has_account" name="has_account" value="1">
    <label for="has_account">I have an existing account</label>
</div>
<div class="show_if_has_account">
    <div><label for="account_number">Please provide your account number:</label></div>
    <div><input type="text" size="15" id="account_number" name="account_number"></div>
    <p>Your account number is the 15-digit number in the upper right corner of your bill</p> 
</div>
<div>
    <input type="radio" id="doesnt_have_account" name="has_account" value="0">
    <label for="doesnt_have_account">I don't have an account yet</label>
</div>

We could also have a section with the classname show_if_doesnt_have_account that might contain information about signing up for an account. It’s important to note that it’s the id of the checkable element that’s specified, not the name.

Internet Explorer 7

1. Go to Tools/Internet Options
2. In the General tab, in the Browsing History section, click the “Delete” button
3. In the Temporary Internet Files section, click the “Delete files” button
4. Click the “Yes” button
5. Click the “Close” button
6. Click the “OK” button
7. Click the “OK” button

Internet Explorer 6

1. Go to Tools/Internet Options
2. In the General tab, in the Temporary Internet Files section, click the “Delete Files” button
3. Click the “OK” button

Firefox

1. Go to Tools/Options
2. Click the Advanced tab, then the Network subtab
3. Under Cache, click the “Clear Now” button
4. Click the “OK” button

Safari

1. Go to Safari/Empty Cache
2. Click the “Empty” button

Opera

1. Go to Tools/Preferences
2. Click the Advanced tab, then History in the left-side menu
3. Next to Disk Cache, click the “Empty now” button
4. Click the “OK” button

Way back when, I spent too much time trying to fix a CSS problem whose cause was a class name that contained underscore characters. “The CSS1 specification, published in its final form in 1996, did not allow for the use of underscores in class and ID names unless they were ‘escaped,’” Eric Meyer wrote in 2001. “CSS2, published in 1998, also forbade the use of underscores in class and ID names. However, errata to the specification published in early 2001 made underscores legal for the first time. This unfortunately complicated an already complex landscape.”

Meyer’s survey of browser implementation showed support in then-recent releases, so it’s safe to assume that, six years later, underscores are perfectly safe to use, right?

Here’s a quick bit of test code:

<style type="text/css">
.yes, #supports_underscores_in_ids .no, .supports_underscores_in_class_names .no { display: none; }
#supports_underscores_in_ids .yes, .supports_underscores_in_class_names .yes { display: block; }
</style>
<ul id="supports_underscores_in_ids">
<li class="yes">This browser <strong>supports</strong> underscores in ids.</li>
<li class="no">This browser <strong>does not support</strong> underscores in ids.</li>
</ul>
<ul class="supports_underscores_in_class_names">
<li class="yes">This browser <strong>supports</strong> underscores in class names.</li>
<li class="no">This browser <strong>does not support</strong> underscores in class names.</li>
</ul>

Sound fair? Let’s see it.

• This browser supports underscores in ids.
• This browser does not support underscores in ids.

• This browser supports underscores in class names.
• This browser does not support underscores in class names.

And here’s a quick survey of browser support:

• Internet Explorer 7: supports both
• Internet Explorer 6: supports both
• Firefox 2, Windows and Mac: supports both
• Safari 2: supports both
• Opera 9, Windows and Mac: supports both

So that’s a yes to underscores?

Safari doesn’t like you to use “class” as a variable name or object property. Statements like these:

var class = "proletariat";
var boxer = { class: "middleweight" }

will generate syntax errors. This is very likely in advance of ECMAScript 4 which allows object class definitions via a class statement, so it’s probably a good idea to steer clear of “class” variables in all cases.

For all the PHP documentation that exists, it’s sometimes difficult to figure exactly how things work without poking around a little. For this, and for countless other experimental purposes, I end up writing a lot of little test files. They’re basically all the same: little bits of code and lots of echo, var_dump, and other means of output designed to give feedback on what’s going on.

Recently, I was trying to figure out why the chunk_size argument for the ob_start function wasn’t working the way I’d expected. When you start output buffering in PHP, you can specify an optional callback function through which the captured output can be sent before passing it along to the browser. It’s useful for compressing a page before serving it or funneling markup through Tidy to fix broken HTML. The chunk_size parameter is supposed to let you set the number of bytes of output that the buffer should store before it sends it through the callback function. If you set a chunk_size of 1, the callback should receive each piece of output as it’s generated. Should.

If I’d read more of the notes in the manual, I’d have seen that chunk_size values of 0 and 1 are ignored by PHP, but with values of 2 or greater, the function works just as expected.

Why would you want to receive every piece of input just after it’s generated? It turns out that this is extremely useful when writing test pages. An output callback function which utilized information from debug_backtrace would know exactly what lines of code generated each piece of output. Combine this with PHP’s built-in syntax highlighter and you have something like what I’m calling Lookout, a swell little class for watching PHP operate.

Lookout can also grab and integrate any errors able to be caught by error handling, it corrects some of the unfortunate markup generated by the syntax handler, and it caches its results in between changes to the test files.

The downside is that if your file contains any fatal errors, Lookout gives you a blank screen. You can’t capture fatal errors in PHP; they just stop execution in its tracks. Usually you get an error message, but when all output is being tucked safely away by an output buffering callback, you won’t seen even that.