- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
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).
Topics: Javascript, Progressive Enhancement, Prototype
Comments: 2 so far
Leave a comment
About Pathfinder
Recent
- Roles Testing For Security
- Blackbird takes the pain out of JavaScript logging
- Making GWT JSON not Quite so Painful
- IDEA - preconference workshop 06 Oct 08
- HTML5, Ajax history management, and The Ajax Experience 2008 Boston
- A Look Back At Past Posts
- Flash Player on iPhone gossip
- Microsoft to Jump on Board EC2
- TAE Boston 2008: The Unsexy Presentations
- The Ajax Experience 2008: Hope to see you in Beantown
Archives
- 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


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