Put that data-* attribute away, son...You might hurt someone

27 JAN

HTML 5 data-* attributes allow us to add custom attributes to elements as long as they are prefixed with ‘data-’ and since this was first discussed on John Resig’s blog I’ve been interested in how people will use and abuse this feature. I greeted the feature with mixed feelings. It’s definitely a simple way to enrich the semantic value of HTML pages as well as helping to improve some of the more toxic parts of Microformats. XML namespaces are definitely a more complete solution but this is a simple and immeadiately adoptable means to add invisible semantic data to HTML documents.

However, as John hinted in his post, there’s an enormous temptation for JavaScript authors to use this to embed configuration data for their scripts directly into HTML. Many developers have been itching for an excuse to do this for a long time. Some just added attributes willy-nilly like crazy web standards bandits, some would love to do add arbiturary configuration into their HTML but felt a bit squeamish about moving away from the HTML specs and opted to abuse the class attribute from within the standard. For the record, I’d tend to side with the former. If it works and there’s a good reason for it then I say do it. However, back then I explained why there is no good reason to add unsemantic configuration data into your HTML and now that we have standards-approved carte-blanche to do this I’d like to reiterate that it’s still not the way forward. If you’ve not read that article then its worth a quick read before you go on.

By all means, use data-* attributes to add semantically valuable data to your HTML but if you are just using it to prop up a script you are writing think again.

An Example

If you’ve not already watched it go now and watch Yehuda’s Screencast on evented programming with jQuery. The ideas in here represent a massive progression in client-side scripting. It’s nothing short of essential viewing. However, it also happens to be the latest example I’ve come across of needless use of data-* attributes and, while not wanting to take away from how progressive and clever the content is as a whole, I feel the need to use it as my counter-example for this article.

In the screencast, Yehuda is creating a tab interface. The markup he proposes is something like this:

<ul class="tabs">
  <li data-content="first">First</li>
  <li data-content="second">Second</li>
  <li data-content="third">Third</li>
</ul>

<div class="pane" id="first">Some content</div>
<div class="pane" id="second">Some content</div>
<div class="pane" id="third" class="selected">Some content</div>

The idea being that when the tab <li> is clicked the script then interrogates data-content to decide which div to show. However, without the JavaScript operating on this the HTML has no semantical value. The <li>s are just list elements (and will be read as such by assistive technologies). In fact, the browser doesn’t know that those list elements are in anyway associated with <div>s below. Here’s how I think it should be marked up:

<ul class="section-nav">
  <li><a href="#first">First</a></li>
  <li><a href="#second">Second</a></li>
  <li><a href="#third">Third</a></li>
</ul>

<div class="section" id="first">Some content</div>
<div class="section" id="second">Some content</div>
<div class="section" id="third">Some content</div>

Now, before we even add JavaScript we have links that we can click that will jump you to the specified content. If you click the back button you will jump back to the previous tab’s content. With this in place you could even make tabs work solely by using CSS and the :target pseudo-selector. If you wanted to go HTML 5 crazy you could even use <nav> and <section> elements which would further enhance the semantics of the document. By correctly associating the tab link and the tab content we can take advantage of the browsers facilities to navigate this type of content even before we get out the old JavaScript crowbar.

With this markup as a base it’s then just as trivial to hook in the script but instead of interogatting data-content we just look at the anchor of the link. Because we are now using anchors, users can deep link into a particular tab, it would be trivial to support the back button and assistive technologies will make better sense of it, amoung other things.

Leave Yehuda Alone!

Of course, I’m picking apart what was a very simple and purposefully contrived example, but as usage of data-* attributes picks up, it’s important to not abuse this facility and to continue find as many semantic hooks for your scripts as possible. It may now be a “standard” but it doesn’t mean that its a good solution. When looking for hooks for my scripts, this is the process I follow:

1. Build up your markup to be as meaningful as possible. If it submits a request it should be a <form>, if its linking to another piece of content it’s an <a>. Even if you’re building a very complex piece of UI seek to build as much of it as you can into your document (while keeping the semantics intact) before you go anywhere near your JavaScript.

2. Write your script to take advantage of the semantics your HTML document has to offer. This will get you a long way in many cases, however, you may well find that there is still configuration information you need to pass into your script. Rather than turn to data-* attributes its best to consider inferring this information via context in the same way that CSS does. This way you can assert things like “all <input>s with type ‘slider’ and a class ‘day’ have a min of 1 and a max of 31” then you can change this in one place rather than visiting each element’s data-* attributes individually. Read this article for more detail on how to do that. We don’t need to change the heading colour in every single heading element in our site now we have CSS, let’s not start doing that kind of thing again now we have data-* attributes.

I welcome the data-* attribute. It’s a simple and immediately useful method to add custom semantic data to HTML documents. Just avoid using it to litter implementation-specific crap into your documents :)

Posted under: JavaScript | 21 comments | Read More →

Low Pro for Prototype and Firefox 3.5

02 JUL

Just a quick note for those googling for a solution to this. Older versions of Low Pro for Protoype will be experiencing problems with behaviors in Firefox 3.5. This issue has been fixed so pick up the latest version from GitHub

An interesting upshot of this is that I found out something pretty nice which is kind of obvious but had never occurred to me before. If you create a function in a closure then that function can refer to itself because it has access to that closure’s variables. I normally use arguments.callee to get a reference to a function from within its body but there’s never really any need to do that:

(function() {
  var aFunction = function() {
    aFunction.thing = 47;
  };

  aFunction();

  alert(aFunction.thing); //=> 47;
})();

Posted under: JavaScript , Low Pro | 16 comments | Read More →

It's Been A Long Time...

23 JUN

But I’ve not just been sitting on my arse playing GTA IV, oh no. Well, not all the time anyway. The reason I’ve not posted anything (or been particularly active on the web in general) is that I’ve been damn busy. Most importantly, Catherine kindly gave birth to our first son, Max, back in March which has been quite a change and sapped a lot of my hacking time. I have to say though, despite the horror stories that many veteran parents like to feed you, our experience has only been good. In fact, not good, great. I recommend this reproducing lark.

Secondly, I’ve been hacking away nearly full time on one of my favourite projects to date, Peoples Music Store with LRUG stalwart and renowned anarchist, James ‘Bringing London To Its Very Knees’ Darling which is maturing nicely under private beta as we speak. Peoples Music Store is a great idea from some of the guys behind bleep.com whereby users can construct and customise their very own download store from the music they love then get free music themselves if people buy from their store. It’s a great way to both promote and show off you’re own music taste or in depth genre knowledge and find new music from stores you trust while getting some free digital swag along the way. I’m probably not explaining it well so just drop me a line if you want and invite and the site will explain itself. Public launch is coming in a month or so.

Building Peoples Music Store has been a great learning experience. We run the site on a cloud computing platform and from content ingestion to audio preview delivery to application servers to download packaging and delivery everything has been designed to scale horizontally – and I’m pretty proud of it. Thin, Rack, Sphinx, God, Starling and a whole load more cool open source gear is all running in there. I really need to get to blogging some of what I’ve discovered about working with Rack. It simply is the dog’s bollocks.

So, enough of the excuses. What’s on the horizon?

Speaking and Conferences

I’ve taken some time of speaking and conferencing in general so as to spend lots of time with Catherine and Max but come September I’m restarting the conference trail. Firstly, I’m doing a presentation and a tutorial (with Jarkko Laine) at RailsConf Europe all about JavaScript related Rails stuff and I’m likely to have a slot at @media Ajax as well. Also, I’ll be heading to dConstruct as is the tradition.

Hacking and Open Source Business

Although I’ve not commited to Low Pro or Low Pro JQ for a good while now they are both very much alive. I’ve simply not come across anything that I’ve felt the need to add for a while. If you have any suggestions or patches do let me know. I’ve actually got time to commit them at the moment. Another little project that I’m hoping to get off the ground is called Evil which is going to contain lots of Merb/Rack goodness. The first by-product of which is the merb_openid gem for consuming OpenID in Merb apps (it’s still not quite production ready though so don’t go using it just yet). I’ll let you know what Evil actually does when (or if) I actually get something working.

So, that’s all for now. Just a bit of a status report. I promise I’ll get some useful content written that you actually care about very soon.

Posted under: Events , JavaScript , Low Pro , Misc , Rails | 11 comments | Read More →

How To Use Low Pro For jQuery

03 FEB

Class-based OO

In order for Low Pro behavior classes to work with jQuery we need a class implementation. The one I’ve based this on is the version from Prototype originally based on Alex Arnell’s work. This is detailed in this article on the prototype site. The only difference is that instead of using Class.create you use $.klass:

Draggable = $.klass({
  initialize: function(options) { },
  onmousedown: function() {}
});

GhostedDraggable = $.klass(Draggable, {
  onmousedown: function($super) {
    // do extra stuff here then call original method...
    $super();
  }
});

Attaching the behavior class to elements

To attach the behavior class to some elements you can use the attach method:

$('div.product').attach(GhostedDraggable, { anOption: thing });

attach creates a new instance of the given behavior class for each element in the collection and attaches them to these elements. Any subsequent arguments are passed to the class’s initialize function. A few magic things happen here. First, this.element in the behavior instance is set to a dollared version of the element it’s attached to. Secondly, every method beginning with on (eg. onclick, onsubmit etc) gets bound as an event handler on the attached element. However, in the event handler functions themselves, this points to the behavior instance rather than the element so you can call it’s other methods. You can obviously get to the element by using this.element if you need to though.

And for the bonus round…

So, that’s about all there is to it. One added bonus is that if you are using livequery then Low Pro will automatically use it to attach any new behaviors after the DOM is changed without you needing to worry about it.

Here’s a super simple example behavior that simply adds and removes a CSS class name when it is hovered over. It’s about as bare bones as you can get while showing off most of the features:

Hover = $.klass({
  initialize: function(hoverClass) {
    this.hoverClass = hoverClass;
  },
  onmouseover: function() {
    this.element.addClass(this.hoverClass);
  },
  onmouseout: function() {
    this.element.removeClass(this.hoverClass);
  }
});

jQuery(function($) {
  $('span.name').attach(Hover, 'myClassName');
});

For more information about how you might use behavior classes take a look at this article. ANother good point of reference is the built-in Remote.Link and Remote.Form behaviors that are built in to Low Pro. Take a look at the source Also a Low Pro site is on its way shortly. As I use it more myself I’ll post more real examples but you can post any questions to the Low Pro list.

Posted under: JavaScript , Low Pro | 10 comments | Read More →