Forms will be able to require the user-agent to do pre-submission validation. Obviously we can’t rely on this for security reasons, but it will save us from writing JavaScript validation scripts and give users a better experience with our forms.

And the validation is fairly robust. <input/> elements gain an attribute called pattern, which accepts a simple regular expression, like "[A-E][0-9]{7}".

But you probably won’t need the pattern attribute very often, since there is a whole slew of new types that the UA will be expected to provide controls for, and validate. Crucial types, like email and url, and difficult types like datetime-local and color.

jQuery UI is great, but it doesn’t compare to this kind of power.

I only realized the sorry state of our current form controls very recently, after getting an iPhone. Built-in form fields on the iPhone can trigger different input methods. A field, like ZIP code, that accepts only numbers, opens the keyboard to the numbers first. A field that wants a URL can open a keyboard with a .com button to save time. But web pages can’t do this. They can only say that an input accepts arbitrary text.

For mobile or touch-enabled UAs, knowing that you can open a keypad instead of a full keyboard is a great step forward. For everyone, having date and color pickers built into the UA means saving both developers’ and users’ time. Less time to build and less time to download, consistent experience in the UA across web sites.

Forms also get a new event, input, which is a little like the current change event, except you don’t need to wait for the element to lose focus for the event to fire. That’s just useful.

Controls get new methods, stepUp() and stepDown(), to enable, for example, very fast forward/backward selection on a date input.

The last fun addition I’ll mention (go read the links, they’re all to the same page) is the autocomplete attribute. It doesn’t do what you hope it does. What it does is specify to the UA that it should not remember and suggest values for this input. It lets the UX designer decide whether to use Firefox or IE’s built-in autocomplete on a per-field basis. Useful. (Not as useful as, say, an autocompleteUrl attribute that could load some JSON or XML, but still useful.)

Building forms is going to be so, so much better once these are widely support.

Last time, I introduced the technique of creating and immediately executing a function, using parentheses. I talked a little about returning a function and storing it in a variable.

There are a lot of things you can do with this trick, like create interesting bookmarklets. But let’s see how you can use it to protect information on the class level.

Here we’ll take advantage of JavaScript’s scope behavior. Remember that a function uses the variables where it is defined, not executed. Perhaps a better example…

We can see that the inner function (which is returned from the outer function and set to myFunc) uses the value of message from the block where it was defined, not executed.

Now you should be able to see where this is going. Let’s look at a more complex example, extended from the first part:

What’s the advantage here? The variable partNumRegex is not copied by the new operator. In a small example like this, there is not much benefit, but if you had hundreds of Product objects, you could save a significant amount of memory.

There are a few major drawbacks: a public static (class) method cannot access a private static method or variable. For example:

The class method validPartNum has no access to the private class variable partNumRegex, and so will throw an error at (1). Adding an accessor must be done on the instance, not the class, like so:

But then you cannot access the private variable without first creating an instance of the class, and the accessor function is copied with the new operator. New methods added to the Product.prototype object are likewise unable to access the private static variables. This is a limitation of JavaScript.

Even with these limitations, the ability to hide implementation behind an agreed-upon interface is powerful. (JavaScript doesn’t actually have interfaces, but you can just write it down.) Behind the scenes, you could load new data via Ajax, without ever exposing your Ajax method to that new guy down the hall who likes to misuse everything he can:

That’s it for now. I owe most of these three articles to the book Pro JavaScript Design Patterns, by Ross Harmes and Dustin Diaz. Those two are geniuses, and anyone who wants to be a better JavaScript programmer would do well to pick up their book.

Next up, I’ll argue why the <dl> tag is a good way to display forms semantically.

I’ve been thinking a lot about browser compatibility as I’ve been working on Today’s Meet. My CSS is valid, but it doesn’t work quite right in IE6. The interface is completely JavaScript-based, and will only become moreso in the future. How much time should I put into making it all work with IE6?

None.

I know lots of people, usually in government offices or schools, who are stuck with IE6. For some reason, their IT departments have neglected to update their systems for over two years.

(Sure, some of these systems are running Windows 2000. This is a real minority at this point, though, and the rest have no excuse. If you’re running Windows 2000, and absolutely cannot afford to get new systems, get Firefox.)

I used to think I needed to support IE6 because this group is frighteningly large. But now I’ve come to realize—especially in the wake of this week’s news—that by supporting IE6, all I’m really doing is enabling these lazy IT departments to keep running dangerously out-of-date software.

IE6 is the Vicodin to lazy IT’s Dr. House. As developers we’re Drs. Wilson and Cuddy. Just keep handing it out.

How up-to-date is the rest of the software on a system that (apparently) hasn’t run Windows Update in 2 years? What other major security holes, accessibility issues, and compatibility problems would be solved by updating?

Not only is supporting IE6 annoying, it enables people to run software that is out-of-date and easily exploited. Are we really helping users, or are we just helping them get hacked?

So from now on, no more.

My personal projects will no longer support IE6. I won’t test in IE6.

IE7, Firefox 3, Safari 3, provisionally Opera (really, if it works in the first 3, it should work in Opera).  Keep your software up-to-date.

If you’re still using IE6, go get 7. (Then don’t use it until after the Windows Update patch.)

If you can’t run updates, but can install software, go get Firefox.

If you can’t do any of that, tell your IT department that running software 2 years out of date is unacceptable. Tell your boss to tell them. It’s a performance/security/accessibility/compatibility/etc issue.

And if you’re a developer, stop and think. Are you actually doing your visitors any good by supporting IE6? Or should you take all the time and effort you put into backwards compatibility and put it someplace more valuable?

I just downloaded the Spore Creature Creator, and this file showed up on my desktop: 792248d6ad421d577132c2b648bbed45_scc_trial_na.exe.

Why not “Spore Creature Creator Trial Install.exe”, or, if spaces aren’t your thing, “SporeCreatureCreatorTrialInstall.exe”? Either would be infinitely more meaningful than an MD5 hash followed by an acronym and a region code.

While the developers may have had a reason (though I can’t imagine it’s a good enough reason) to use this file name, the web team has no excuse.

There’s a lesson here: be nice to users. Whether it’s just a file name or helpful error messages or designing a user interface/experience, don’t treat your users like machines that parse your (bizarre) internal formats.

And Will Wright, if you’re listening, ask someone to rename that file.

Some themes waste kilobytes of HTML source on something that could be achieved with 75% less markup. Some use blatantly non-compliant code. Almost none use semantic names.

But what really irks me—I’ll cop to using meaningless code to make it look good—is the style of CSS that seems to be spreading: breaking up definitions into a half-dozen chunks, no line breaks, lack of organization. I think their heart is in the right place (a section for colors, so don’t have to worry about layout; a section for typography, so the precious padding is protected) but the result is a horrid mess.

I blame Michael Heilemann, the designer behind the bland and semantic-free default WordPress theme. I imagine theme developers, many just starting with HTML and CSS, started by looking at his code, and thought that was the way to do it. Then it spread like a virus.

Here’s an example from “Autumn Concept 1.0″:

#topbar {background-color: #4b7c44;}
#footer {background-color: #4b7c44;}
#mainpicinner {height: 250px; background: «
  url(images/mainpic01.jpg) top left «
  no-repeat #fff; border: 1px solid #fff;}
/* typography */
#logo a {color: #3a4032;}
.textbkg {border-left: 4px solid #ebf0cf;}

(« is an inserted linebreak.)

Wow. Line breaks? Readability? Was this passed through a bad version of JSMin?

This is from the “Color Scheme” section, but the first directive for #mainpicinner is height. It also has a border, not just border-color but the whole thing. What’s the point of having sections if you proceed to ignore them immediately?

The rest is filled with classes like cols01 and box01 (while there are other cols##, there is no box02).

But that isn’t my real problem. My real problem is about 20 lines further down:

body {position: relative; background: #1f1f1f; «
  font: 70% Verdana, Arial, Helvetica, «
  sans-serif; text-align: center; letter-spacing: 0;}
#container {float: left; display: block; width: 100%;}
#topbar {float: left; display: block; width: «
  100%; background-image: url(images/topbar.png); «
  background-position: top; background-repeat: «
  repeat-x; text-align: left; padding: 13px 0 6px 0;}
#topbar div {padding-bottom: 0;}

#container is back. (As are backgrounds. Pick a spot, already!)

This kind of CSS is hard to read, hard to maintain, and hard to customize. Even if the initial version is perfect—which doesn’t exist—things will start to break as soon as someone opens the file. Even in this published style sheet, the author couldn’t decide if background images and borders belonged in “Color Scheme” or “General Styles.” What chance does a maintainer have?

I am, admittedly, obsessively strict with my style sheets. I like to make very sure that every style affects only what I intend it to affect. But I never let the styles for one element single get broken into two places. Instead, what I try to do is keep similar styles in a similar order inside those blocks:

blockquote.dropquote {
  float: right;  font-family: Arial, «
    Helvetica, sans-serif;
  font-size: 130%;

color: #662020;
  background-color: #ddd;
}

div.login {
  position: absolute;
  top: 0;
  left: 0;

  font-size: 80%;

  color: #fff;
}

Get the idea? Within each selector, I try to keep things in the same order. I almost always keep positioning styles first and then do either typography or color. To me, this is much more readable and maintainable. If my header div is 3 pixels too wide, I don’t have to comb through all the #header sections. I go to one place and fix it.

I like to extract the CSS order from the document order. This doesn’t necessarily stay complete or strict, especially when you have classes that can be used anywhere or you’re controlling tags directly. The header styles do come before the content styles, though, which come before the footer styles. That just makes sense.

Am I the only one who can’t stand this “style” of CSS? Do you use it? Why?