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:
HTML:
-
-
<input class=":required" type="text"/>
-
<input class=":integer" type="text"/>
-
<input class=":length;4" type="text"/>
-
<input class=":min_length;4" type="text"/>
-
<input class=":format;/^(vanadium)+$/i" type="text"/>
-
<input id="pass" class=":ajax;/username_checker/check.json" type="text"/>
-
<input id="pass" class=":email" type="text"/>
-
Related Content:
2.7 rating from 41 votes
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 $(‘*’); };
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.
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.@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.
@fabienmenager – I went to W3C to check on that, and…. you’re right. According to W3C (http://www.w3.org/TR/html401/struct/global.html#h-7.5.2):
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.
@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);
}
@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.
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.
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.
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?
Just make up your own attributes…
Messing with class/rel/alt/title isn’t cool.
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.
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.
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.
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.
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.
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.
http://zendold.lojcomm.com.br/fvalidator/
jQuery validate plugin for the mature, less-intrusive version of this. (no misuse of class attributes)
http://bassistance.de/jquery-plugins/jquery-plugin-validation/
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.
Cheers,
Daniel
@daniello
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 e.g.email 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 ?
@medikoo
Good point that would be ‘data-validation’ I guess ;)
–
Daniel
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.
http://validity.thatscaptaintoyou.com/
@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’ :-)