Comments on: Vanadium: Semantic client side validation

By: dawn

dawn — Wed, 23 Sep 2009 16:44:36 +0000

@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’ :-)

By: whatgoodisaroad

whatgoodisaroad — Sun, 20 Sep 2009 22:02:34 +0000

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/

By: daniello

daniello — Sat, 19 Sep 2009 19:36:18 +0000

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

–
Daniel

By: medikoo

medikoo — Sat, 19 Sep 2009 15:57:33 +0000

@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 ?

By: daniello

daniello — Sat, 19 Sep 2009 09:46:57 +0000

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

By: functionform

functionform — Fri, 18 Sep 2009 18:23:53 +0000

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

http://bassistance.de/jquery-plugins/jquery-plugin-validation/

By: idio

idio — Fri, 18 Sep 2009 18:11:03 +0000

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/

By: reinis

reinis — Fri, 18 Sep 2009 17:35:35 +0000

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.

By: eyelidlessness

eyelidlessness — Fri, 18 Sep 2009 17:12:22 +0000

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.

By: erikharrison

erikharrison — Fri, 18 Sep 2009 17:11:13 +0000

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.

By: sashasklar

sashasklar — Fri, 18 Sep 2009 17:06:17 +0000

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.

By: Jadet

Jadet — Fri, 18 Sep 2009 16:40:27 +0000

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.

By: Darkimmortal

Darkimmortal — Fri, 18 Sep 2009 15:39:08 +0000

Just make up your own attributes…

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

By: Liquidrums

Liquidrums — Fri, 18 Sep 2009 14:39:00 +0000

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?

By: compbry15

compbry15 — Fri, 18 Sep 2009 13:31:25 +0000

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.

By: sentientholon

sentientholon — Fri, 18 Sep 2009 12:42:55 +0000

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.

By: ywg

ywg — Fri, 18 Sep 2009 12:30:54 +0000

@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.

By: fabienmenager

fabienmenager — Fri, 18 Sep 2009 12:23:56 +0000

@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);
}

By: jmar777

jmar777 — Fri, 18 Sep 2009 12:12:06 +0000

@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.

By: fabienmenager

fabienmenager — Fri, 18 Sep 2009 11:59:15 +0000

@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.