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.
Update: You can also use a standard HTML attribute like
titleif you are worried about maintaining semantic markup. Nothing changes in the following examples except, of course, you will be looking for thetitleattribute instead ofdefault.
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).
Topics: Javascript, Progressive Enhancement, Prototype
Comments: 2 so far
Leave a comment
About Pathfinder
Follow the Blog
-
Get a monthly update on best practices for delivering successful software.
Subscribe via email
Subscribe via RSS
Categories
Topics
Archives
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Blogroll
Recent
- Elements of Testing Style
- Aesthetics and Web Design
- Asterisk-Java Testing with Groovy
- 3 Misuses of Code Comments
- Fluently NHibernate
- Digging a Hole and Covering it with Leaves — The Software Development Version
- The Importance of User Experience - Do You Understand It in Your Bones?
- Writing Your Own Protocol With NSURLProtocol
- What’s In Your Dock: iPhone edition
- Feature Fatigue

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
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