Friday, January 20, 2012

Violating Language Specifications

In my previous post about using jQuery to provide default values to text fields, the comments here and on social media got a bit interesting. First, suggestions for improvements came from Erik (which I edited into the post itself). That suggestion revolved around using a CSS class to track which fields should have a default value and then using a custom html attribute to maintain the value that the field should have. This technique dramatically simplifies the implementation. Sounds good, right?

Well, there's one problem. Maybe. Adding a custom html attribute results in markup that violates HTML specs. By employing this technique to make current and future development cleaner and more pleasant, you are technically creating invalid HTML pages. Sounds bad, right?

I'm not so sure. The risk you run by violating specs on a language are pretty straight-forward: There is a significant increase to the chance that a browser somewhere will render your page wrong and/or your code will utterly fail. Further, you may complicate the maintainability of the codebase by confusing future developers with your non-standard practice. Some violations are more likely to be problematic than others.

When I was creating my StackExchange clone, I made the mistake of unintentionally including a <div> inside a <span> element. On most browsers, this was rendered fine. No other developer would be confused by it. But about 1% of the time, Firefox 3.5 (the most common version that hit the site at that time) would drop text-styling from the offending element. So on a page displaying 15 questions, there was a 10 - 15% chance that at least one of the questions would be almost inexplicably styled wrong. Once the cause of the problem was found, it was an easy fix, but it was certainly a pain to find. And in fact the only way I did find the problem was through running the pages through an HTML validator and fixing the resulting violations.

On the other hand, there are definitely reasons that violating spec are worthwhile. HTML spec requires javascript includes to be at the top of the page, in the HEAD. Yet any good developer will put as many of these includes as possible at the end of the file, so that the html is rendered before the javascript is retrieved (as this often results in pages that seem significantly faster to the user). This is a violation that is so common it has become a virtual standard. Many tools for checking page load times specifically search for this factor. Certainly then this violation is one that we all agree should be employed.

In the end, I think it comes down to balancing the dangers of violating a language's specification with the benefits of the violation. If the benefits outweigh the risks, I submit that violating specs is a proper coding practice. What do you think?

4 comments:

  1. Trying to comment from my phone :-)

    I think this might be another one that's becoming standard practice. I know of several libraries that use custom attributes for i.e. tooltips or default / placeholder text.

    ReplyDelete
    Replies
    1. Phone worked :)

      I agree, which would make the relative risks of this particular violation pretty slim. As a partner here at Rubicite said "It may be invalid HTML, but it's the right thing to do!"

      Delete
  2. Isn't this valid HTML5? I mean, assuming you use data-yourattribute as the name, instead of just yourattribute.

    ReplyDelete