The Cafes » Refactoring HTML

Over the next week or two I’m going to serialize the first two chapters Refactoring HTML here. Of course, if you don’t want to wait you can always buy it from Amazon or read it online on Safari. And with that brief commercial announcement out of the way, let us begin:

Refactoring. What is it? Why do it?

In brief, refactoring is the gradual improvement of a code base by making small changes that don’t modify a program’s behavior, usually with the help of some kind of automated tool. The goal of refactoring is to remove the accumulated cruft of years of legacy code and produce cleaner code that is easier to maintain, easier to debug, and easier to add new features to.

Technically, refactoring never actually fixes a bug or adds a feature. However, in practice, when refactoring I almost always uncover bugs that need to be fixed and spot opportunities for new features. Often, refactoring changes difficult problems into tractable and even easy ones. Reorganizing code is the first step in improving it.

If you have the sort of personality that makes you begin a new semester, project, or job by thoroughly cleaning up your workspace, desk, or office, you’ll get this immediately. Refactoring helps you keep the old from getting in the way of the new. It doesn’t let you start from a blank page. Instead, it leaves you with a clean, organized workspace where you can find everything you need, and from which you can move forward.

(more…)

The following is a possible new chapter to be added to Refactoring HTML in the accessibility section. I’m throwing this in fairly late in the editing process, so I’d appreciate any thoughts, comments, or criticisms you might have about this. In particular, I’d appreciate any cases you can think of where autocomplete is not appropriate.

For what it’s worth, I’ve pretty well convinced myself that usernames and passwords are not such a case. That is, autocompleting usernames and passwords definitely increases accessibility and usually increases security. I don’t intend to explain why it improves security in this chapter, but if anyone wants to disagree with that, I’ll explain why in the comments.

Remove autocomplete=”off” attributes where appropriate.

<form action="/login" method="post" autocomplete="off">

<p><label>E-Mail Address: 
<input type="text" name="e1" autocomplete="off"/>
</label></p>

<p><label>Password: 
<input type="password" name="p1"  />
</label></p>

<input type="submit" title="Login" autocomplete="off"/>

</form>

<form action="/login" method="post" autocomplete="off">

<p><label>E-Mail Address: 
<input type="text" name="e1" />
</label></p>

<p><label>Password: 
<input type="password" name="p1"  />
</label></p>

<input type="submit" title="Register" />

</form>

(more…)

Here’s a neat rearrangement of Matthew Levine’s Holy Grail CSS layout (fixed width left and right columns and liquid inner column) I’ve devised for Refactoring HTML. This is based on the non-equal height, no extra-div version. The basic idea is reorganizing the style rules into three sections:

• The rules whose values must be copied verbatim.
• The rules whose values can be set to arbitrary values.
• The rules whose values are calculated based on the arbitrary values.

This makes it easier to see exactly what you can change independently, and what else you have to update when you make such a change. Here’s a sample stylesheet. LC stands for left column, RC for right column, and CC for center column.
(more…)

The following is an early draft of the intro to Chapter 6 of Refactoring HTML. The remainder of the chapter will address specific recipes for improving site accessibility, especially those tasks that remain after a site has been made strictly valid (which is addressed in earlier chapters). Comments, suggestions, and corrections, are appreciated.

The Web has the potential to more fully integrate people with seeing, hearing, physical, learning, and other disabilities into society. By limiting the interaction necessary to communicate, as well as enabling delayed communications so that participants can move at their own pace, the Web has transformed our relationships with each other. Properly designed web pages neither know nor care whether you’re reading them with a CRT or a screen reader. Properly designed forms neither know nor care whether you’re inputting data with a keyboard, a mouse, or voice recognition software.
(more…)

A bogon is an element that appears in an HTML document, but has never been recognized by any browser. You’ll often find them by viewing source on pages written by XML geeks like me. I got the term from John Cowan’s TagSoup, which has, a --nobogons switch to suppress any elements it doesn’t recognize.

A semibogon (my own coinage) is an old element that used to be recognized by one or more browsers but is no longer. Examples include:

• marquee
• basefont
• bgsound
• keygen
• bgsound
• spacer
• wbr
• nobr

I’m trying to generate a reasonably complete list of these semibogons for Refactoring HTML. Can anyone add to this list?