Easy! Reader

A few projects back, I decided to rethink our JavaScript organization strategy and came up with a new technique that, I think, helps us better manage behaviors from page to page.

For years, when I needed page-specific interactions, I would either embed the JS (unobtrusively, of course) at the bottom of the page or externalize it to a separate page-specific file. In some sites, that became a difficult setup to manage because we were juggling so many files and we were also forcing our users to download each of those files individually.

Looking for a better way to manage all of the code, I built FunctionHandler. This script takes lets you declare blocks of JavaScript and then target them at pages based on the id attribute on the body element. When the targeted id is encountered, the code block is executed on DOM ready. Here's a quick example:

FunctionHandler.register(
  ['home'],
  function(){
    alert("I'm gonna run some code here.");
  })

As you can see, using it is pretty simple: you make a call to FunctionHandler's register method and pass it two arguments. The first is an array of the id values you want this code block to execute on and the second is an anonymous function that wraps your code block.

What we've found really nice about this setup is that it encourages you to create discrete JavaScript components while, at the same time, easily allowing you to adjust the pages that those components run on by simply adding to or subtracting from the id stack. You can even blanket every page with a given script by supplying a string value of "*" as the initial argument:

FunctionHandler.register(
  '*',
  function(){
    // Typekit
    // Google Analytics
    // etc.
  });

Anyway, I just wanted to take a brief moment to share this script because we've found it pretty handy. Perhaps you will too.

PS - FunctionHandler is available in 3 flavors: native JS, jQuery, and Prototype.

This one took a little futzing around and digging through the TinyMCE forum to figure out, but it's been nagging at me for a while. By default (or at least in the default configuration provided under the LG TinyMCE extension for ExpressionEngine), TinyMCE will remove the alt attribute if it is empty. Obviously, for accessibility and validation reasons, this is highly undesirable and needs correcting. Thankfully, the fix is pretty simple: add the following to your TinyMCE configuration options:

// fix empty alt attributes
extended_valid_elements : 'img[src|alt=|title|class|id|style|height|width]',
verify_html : true,

I choose to add these options right after declaring my cleanup/output options but before the remainder of the configuration. If you choose to tack these options on at the end, just remember to remove the trailing comma.

I wasn't planning to weigh in much on this subject, but I've been asked by several people for my thoughts, so here we go...

This decision by the W3C to not renew the charter for the XHTML 2 Working Group has, rather unfortunately, brought out the worst in the Web standards community. Sure, as a community, we're prone to holy wars over seemingly inconsequential things—abbr vs. acronym, use vs. abuse of definition lists, etc.—but this move has sparked a particularly ugly fight between proponents of XHTML and its detractors (primarily those folks who think it's pointless to use XHTML if you aren't serving it with an XML MIME type).

Personally, I have mixed feelings about the decision. I think there were a lot of good ideas in XHTML 2 (everything can be a link, for one), but it also had a number of shortcomings. I feel much the same about HTML 5; some of the new elements make a lot of sense, but others seem to be solving a problem that really wasn't there to begin with.

In the end, I think this is probably a good move for the W3C as it will, hopefully, allow them to reallocate resources to projects that need them.

But does it mean I think XHTML is a failure? No.

I think XHTML was a phenomenal success as it made us look at HTML in a new light. It forced us to think about how we marked up documents and applied much-needed pressure on developers to make smarter decisions. Without it, I dare say the Web standards movement would never have gotten as much traction as it did and we would still be in the midst of the browser war started more than a dozen years ago.