XForms and Internet Applications: Using the role attribute to extend XHTML

An interesting suggestion came up recently on the www-html mailing-list. Ahmed Saad suggested that an attribute could be added to HTML which when placed on an element would tell the browser not to execute any script contained within. This could be used to wrap comments added to a blog, and so prevent executable code from being uploaded. Ahmed gave an example of his proposal in action:

<div id="comment123" nocode="true">
  <script type="text/javascript">
    alert('This piece of code will not be executed even ¿
    though it evaded the server-side filter');
  </script>
</div>

It's certainly a great suggestion, but it's also the kind of thing that is just so easy to do with the proposed role attribute, that I thought I'd use it to illustrate how some of the new hooks being added to XHTML allow to be easily extended in a decentralised way, giving different interest groups the ability to bend XHTML to their own purposes.

The `role` attribute

The role attribute is a new feature in XHTML 2 that is being made available via a module so that it can be used in XHTML 1.x. (You might also be interested in The XHTML role attribute: small and perfectly formed, and XHTML 2 and the Semantic Web: Are we nearly there yet?)

Adding functionality

We generally need two things to implement an idea like Ahmed's in XHTML:

some agreed mark-up to allow the author to signal that they want to make use of the feature;

a description of exactly what the behaviour should be.

Traditionally both of these parts of the requirement would have come from members of the HTML Working Group, after much discussion at meetings and conferences, on phone calls and of course with other interested parties, on mailing-lists. But there is no reason for this to be the only way to grow the language, particularly when it comes to 'light-weight' features such as the one being proposed here.

To illustrate, I'll show one way that Ahmed's requirement might be implemented, using the new hooks.

The mark-up

To flag up the use of the feature in the mark-up, we could simply use an agreed value in the role attribute, with Ahmed's nocode="true" suggestion becoming role="nocode":

<div id="comment123" role="nocode">
  <script type="text/javascript">
    alert('This piece of code will not be executed even ¿
    though it evaded the server-side filter');
  </script>
</div>

Even better, we could actually define this block as what it really is--a comment--and let the fact that code should not be executed be a consequence of the block being a comment, rather than some 'floating' property:

<div id="comment123" role="comment">
  <script type="text/javascript">
    alert('This piece of code will not be executed even ¿
    though it evaded the server-side filter');
  </script>
</div>

Globally unique

One of the key ideas of the role proposal is that is makes use of QNames to allow for the clear identification of concepts. There may be some systems in which a comment should contain executable code, for example--in other words, your comments may not be the same as mine. For the sake of our illustration, let's pretend that part of the Atom suite of specifications is a set of terms that can be used in situations such as this, and it includes the definition of atom:comment:

<div id="comment123" role="atom:comment">
  <script type="text/javascript">
    alert('This piece of code will not be executed even ¿
    though it evaded the server-side filter');
  </script>
</div>

Now we have a way of uniquely identifying 'Atom comments' in any XHTML mark-up, without having to extend XHTML (beyond the addition of the @role attribute, that is).

Defining features

Now that we've created a way for an author to tag different parts of their documents, we also need to define what these tags mean. This is usually done in the HTML specifications themselves, but the role attribute gives us a decentralised way to add functionality to XHTML.

The easiest way to define the functionality is in prose. We might say that 'an Atom comment is any text added to an entry, and any mark-up contained in the comment is to be rendered as if it was in a CDATA section'. Or we might say 'any script elements can be ignored'. The actual definition is not important here, the key point is simply that somewhere there would be definition of an atom:comment.

The role specification goes further than allowing simple text definitions for objects, and allows the use of RDF to give more precise, machine-processable instructions. We won't go into the mechanism here, but a trail is already being blazed in this space (with a particular focus on accessibility), by Lisa Seeman and Richard Schwerdfeger; look at their Role Taxonomy for Accessible Adaptable Applications. In particular, they have a great example that shows role being used to indicate that a span is actually serving the purpose of a tri-state check-box.

Conclusion

None of this is to say that we need never extend HTML again, but there are certainly an enormous number of features that could be easily added via the new extensibility hooks added to XHTML--something that vertical markets and distinct interest groups will find useful.