Friday, September 18th, 2009

Vanadium: Semantic client side validation

Category: JavaScript, Library

Vanadium is a new client side validator that allows you to set semantic validation logic via the class attribute. The main page has examples such as:

  1. <input class=":required" type="text"/>
  2. <input class=":integer" type="text"/>
  3. <input class=":length;4" type="text"/>
  4. <input class=":min_length;4" type="text"/>
  5. <input class=":format;/^(vanadium)+$/i" type="text"/>
  6. <input id="pass" class=":ajax;/username_checker/check.json" type="text"/>
  7. <input id="pass" class=":email" type="text"/>
  8. <input id="pass" class=":required" type="password"/><input class=":same_as;pass" type="password"/>

Posted by Dion Almaer at 6:04 am

2.7 rating from 46 votes


Comments feed TrackBack URI

I’m not too sure where I stand on the obtrusive nature of this technique but I’m leaning towards opposing it – I’m not sure an abstraction like this is really needed – I like the simplicity – but, really, validation isn’t complicated – Most of the time it’s better just to roll your own.

Not only does this require jQuery, it’s also 20k in size (minified)… And 38k not minified! How on earth did that happen!? Seriously! And, I’m wondering, what exactly is the benefit in this line:

Vanadium.all_elements = function() { return $(‘*’); };

Comment by JimmyP22 — September 18, 2009

The site does not work on Opera.

Besides I’ve always wondered, why people try to misuse the class attribute ?
Why don’t you use a custom attribute like vanad:pattern=”:mypattern” ?
You may validate your page since the W3 validator check against the DTD, but this does not make your page really valid : the class attribute isn’t intended to be use like that, and your pattern isn’t a valid Qname for the CSS parser.

Comment by ywg — September 18, 2009

Definitely agree with @ywg. Not to be overly critical of the project, because it looks interesting – but there’s nothing semantic about class=":format;/^(vanadium)+$/i". Enough people started rallying against abusing the rel attribute, so now we just stuff everything inside of class.

Comment by jmar777 — September 18, 2009

@ywg I don’t agree with you, the class is not reserved to be used by CSS, it can contain things that define the DOM element. The class attribute is generally used to add semantics to the DOM, when the available tags or the valid attributes are not enough (I think about the type attribute of the inputs).
Furthermore, an input marqued as “required” could be styled differently, thanks to a CSS stylesheet, very easily. That’s for all these reasons that I think the class is a good choice to do such things.

Comment by fabienmenager — September 18, 2009

@fabienmenager – I went to W3C to check on that, and…. you’re right. According to W3C (

The class attribute may be used as….
– As a style sheet selector […]
– For general purpose processing by user agents.

I had never noticed that before.

Comment by jmar777 — September 18, 2009

@jmar777 Well, I didn’t know this was mentionned in the spec ;)
But I agree with your comment : a className looking like this is not really ideal, a better solution would be to refer to a JS function taking the input value in argument and returning a boolean. That would be useful for regex checking like in your example. We would have class=”:format;checkFormat” and the function :

function checkFormat(v) {
return /^(vanadium)+$/i.test(v);

Comment by fabienmenager — September 18, 2009

@jmar777 : I didn’t knew that either.

@fabienmenager : “Furthermore, an input marqued as “required” could be styled differently, thanks to a CSS stylesheet, very easily.” Maybe, but an input marqued as “:required” or “:format;/^(vanadium)+$/i” can’t be styled at all because theses strings are not valid Qname and will be discarded by the css engine.

Comment by ywg — September 18, 2009

Yes classes can be used for behavioral semantics, not just appearance, but I agree with other commenters that “:format;/^(vanadium)+$/i” is an awful, if technically legal, class name.

Apparently the tool allows you to specify rules unobtrusively via JavaScript as well. I’d definitely go that route.

Comment by sentientholon — September 18, 2009

I think some of the previous solutions we have seen in the past, which specify validation requirements in a separate JS object are better solutions than this for a few reasons. As mentioned previously, this seems to completely nullify any ability to style the inputs through CSS. Another reason is that, although it might require slightly more typing, putting the validation requirements in the JS files as objects or something will better serve to separate form and function (both literally and figuratively).

This separation would also would help on larger sites which might have multiple forms across its various pages which all share the same validation requirements. All you would need do is include 1 js file across all pages with forms. The js file would end up being cached and you would be able to re-use your previously coded validation rules. Also, when you want to globally add more validation rules you simply modify one file, rather than needing to change all templates having to do with forms. I suppose you could abstract out that form template, but I still think the other way is better.

Comment by compbry15 — September 18, 2009

The problem isn’t where the custom attributes are stored but in doing validation on the client-side that requires this much logic & maintenance.

The form will have to be validated on the server-side in the end, so why not simply do partial validation via AJAX and intelligently handle the results?

Comment by Liquidrums — September 18, 2009

Just make up your own attributes…

Messing with class/rel/alt/title isn’t cool.

Comment by Darkimmortal — September 18, 2009

Creating your own invalid attributes is bad.

Better to be creative with existing attributes, and try to keep things elegant while you are at it.

Comment by Jadet — September 18, 2009

I don’t see this as an improvement over the current favored abstraction: placing form validation rules in the behavior (JavaScript) layer. There’s also an assumption here that validation rules are a static attribute of the form, but that’s rarely true in applications of any complexity.

Comment by sashasklar — September 18, 2009

The class attribute was intended for this kind of work – as someone has pointed out, it’s in the spec, and more the point, we’ve been adding magic behavior via the class attribute for years now.

Such a tool (though possibly not this one) is probably very handy. It makes it trivial for designers to implement complete and correct validation. Validation is hard (in fact, this tool’s email address validation rule is broken), and providing a prebuilt tool that your HTML/Photoshop guy can just drop in and it works is a Good Thing, and in this case it scales up nicely to more complex tasks without having to completely replacing the validation tool.

Comment by erikharrison — September 18, 2009

There’s nothing wrong with creating your own attributes. It’s been encouraged since XHTML (with namespaces) and in HTML5 (with data- prefix). Nevermind that it has a clearly practical use that, if you’re sane about naming your attributes, is not going to do any real harm.

The use of class this way is ridiculous in comparison.

I’m all for easier-to-use validation, but this misses the mark with its completely unintuitive and abusive syntax.

Comment by eyelidlessness — September 18, 2009

I have no trust for people who don’t even know how to use fixed positioning. The footer in their site jerks around all over the place.

Comment by reinis — September 18, 2009

This is basically the same idea as fValidator, which has been out for a while. We’ve been running fValidator on a handful sites in production for a few years now. I love it.

Comment by idio — September 18, 2009

jQuery validate plugin for the mature, less-intrusive version of this. (no misuse of class attributes)

Comment by functionform — September 18, 2009

Hi Folks,

I’m the author of the VanadiumJS. First of all thank you all for the comments. Secondly apologizes for demo page not working in Opera.
Let me clarify some things.

1. class attribute is not only way of declaring validations. You can do it by attaching external file in JSON format. So it doesn’t mix with the HTML (for purists) ;)

2. I already got comment about not being semantic requiring creating elements holding error messages while there are no validation errors yet. You are not forced to do that. One can simply not create advice element. Vanadium will create it dynamically for you and delete it when the validation passes. One can create empty message advice (styled empty placeholder), Vanadium will detect the advice is empty and rather just showing it / hiding it, will inject the dynamic message to the advice having empty text element. The only problem is when we do not like build-in messages e.g. we want to internationalize page. In that case useful thing will be coming new feature, allowing you declare dynamic messages in mentioned external JSON.


Comment by daniello — September 19, 2009

Instead of ‘class’ why you haven’t used ‘data-*’ attribute ? It’s standard HTML5 way and I think it’s more appropriate for this case.

In HTML5 we also have type for input but you go totally different way. You think HTML5 won’t make it to browsers? What will you do when browsers will start to support HTML5 input types natively ? You’ll change Vanadium API to make to compatible ?

Comment by medikoo — September 19, 2009

Good point that would be ‘data-validation’ I guess ;)


Comment by daniello — September 19, 2009

I’m shamelessly tooting my own horn, but I started the jQuery.validity project because I wanted a less obtrusive, more flexible validation framework. Also, it can take care of some more complected validation rules than the jQuery Validate.

Comment by whatgoodisaroad — September 20, 2009

@daniello, : anywhere in your class attribute (e.g. class=”myns:req stylingcn”) will confuse CSS and styles will not be applied on the element for that class or any other classes in the attribute. In the example given, .styleingcn{} styles would not be applied to the element.

I found this out the hard way, so at my work, we’re using “JS_” to mark out unobtrusively added functionality for that exact reason. It also has the added benefit of demarking which classes are for styles and which are for unobtrusive JavaScript for other developers.

Something like JS_minlength(4) or JS_length(min=4,max=6) works fine cross-browser.

As for choice of attribute, I think class is the right way to go because:
1) it can be validly added to a wide range of element, unlike rel.
2) the data inside the class attribute is just CDATA as far as semantics are concerned, which is not the case for attributes like rel.
3) data-* will solve the issue, but its not yet in a recommended candidate. you might as well be using myrandomattr=””. if you want to see the risks of premature implementation, look up ‘ppk’ and ‘drag and drop’ :-)

Comment by dawn — September 23, 2009

Leave a comment

You must be logged in to post a comment.