Agile Ajax

Progressive Enhancement with Prototype and Custom HTML Attributes

One of the nifty things progressive enhancement can be used for is to allow you to markup your document in a way which allows behaviors to be added to it automatically. Most commonly, this is done by specifying a class name on those elements that you want to enhance. However, this approach does not let you easily pass additional information such as parameters to your enhancement code.

An approach to this problem is to use HTML attributes to mark elements, and Prototype makes this technique easy to implement and work across browsers.


Let's consider a hypothetical use case and solve it using progressive enhancement with HTML attributes.

You have some input fields on your page that you want to spruce up by adding hints/default values inside the field (you know that cool behavior where the text vanishes when you click the field). Not all the fields on the page should have this behavior, so we will need some way to mark the ones we want. Also, the default text is different for each field so we need to specify that in some way.

We could mark the fields we want by using a CSS class, but this doesn't accomplish having unique default text for each field. HTML attributes to the rescue:

   <input type="text" default="foo"/>

Here, we are specifying that this text field has the default text of "foo".

Now, let's look at the javascript to utilize this:

document.observe('dom:loaded', function() {
  $A(document.getElementsByTagName('input')).each(function (input) {
    if (input.getAttribute('default')) {
      // use value in input.getAttribute('default')
    }
  });
});

This works, but we can leverage the CSS selectors in prototype to grab the fields we want:

document.observe('dom:loaded', function() {
  $$('input[default]').each(function (input) {
      // use value in input.getAttribute('default')
  });
});

I prefer the second one myself, as it is easier to read and maintain (however, I haven't tested any performance differences between the two). Regardless of which path you take, you will now have all the fields and can grab the value in the attribute to add your behavior. This approach can work for a variety of different tasks, and is extremely easy to maintain and develop with (especially when combined with OOP).

Comments: 2 so far

  1. Problem with this is that it is not valid HTML. You get into creating all these non-semantic attributes as well that can confuse other developers.

    This should be separated out into JavaScript completely and add a CSS class as the hook.

    Comment by joey, Monday, July 14, 2008 @ 8:18 pm

  2. I have to agree with your valid HTML argument, and using class names which contain the configuration information (e.g. ‘class=”default_foo”‘) can also be used to do the same thing completely through javascript.

    However, I personally feel that specifying unique content information in an attribute of an element is more “natural”. To me, using the class just feels “wrong” (even though it is definitely more correct from a standards point of view).

    class=”default_foo” may make more semantic sense to a computer, but to a developer I think it is more confusing than default=”foo” (especially when taken in the context of a text field). This most likely is the result of the connotation of “class”, which doesn’t really fit well with providing configuration for this specific example.

    This, of course, is just my opinion. Regardless, you are correct that it is not strictly valid nor standard HTML.

    Comment by Anthony Caliendo, Tuesday, July 15, 2008 @ 12:49 pm

Leave a comment

Powered by WP Hashcash

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics

WordPress

Comments about this site: info@pathf.com