That’s a good example, but form validation is often best handled by looking at the form as a whole - i.e. whether a field is valid or not is often dependent upon other fields. As such, finding hacks for fitting in validation for individual fields isn’t as useful as it would first seem.

Probably the best solution would be to generate both the client-side Javascript and server-side validation from XForms on the server, but I have yet to find time to investigate that possibility.

Right now, I don’t think unobtrusive form validation is possible, at least not without having to supplement it with extra Javascript half the time. I really don’t see the point in having a script like that, if it isn’t going to do the job properly, you might as well write the Javascript by hand, it only takes a minute.

As far as misusing valid attributes, you’re right, I don’t condone that, in fact I think it’s much more harmful than using custom attributes.

This happens on IE 5.5 and earlier. Unfortunately, these still have more that 10% of the market here in Poland.

IE6 seems to fix this issue.

A simple example I’d like a suggestion from you which makes semantic meaning as well for: minlength in a form text field.

Another one concerning forms could be an attribute for connecting two fields (i.e. two password fields, to check they are equal to eachother), although I guess you’ll suggest the rel attribute for this, or applying a numbering scheme to the id value (i.e. password1, password2) and then using regexp or similar to hook up the connections.

Although probably not the _worst_ attribute to lack, it’s a simple example where I can’t think of any other attribute conveying the same semantic meaning. You could of course just do with checking for non-zero length and within maxlength or use a specific regexp-format checker.

Maybe I’m trying to argue that there’s just barely a thin line between using an invalid attribute, and misusing a valid attribute semantically But then I don’t think you are advocating misusing attributes, at least I hope you don’t.

On the other hand, if this problem is induced by certain tools, then one’s using the wrong tools. Yah, simple, but it’s just true.

Well, yes…
But a) I’m not the one choosing the tools, and b) if the tools do a good job otherwise, I think a deprecated attribute is a minor problem.

Jim,

you aren’t limited to the class attribute, you can use other attributes and element types - meta, cite, rel, rev, all sorts.

True, although it sounds like they can be a bit misused then; like a rel attribute containing a GUID and such.

As far as deprecated attributes goes, I’d say that if you can’t get rid of them, use a Transitional doctype - unless you run into doctype switching issues of course.

I agree, but then you have the risk with the Almost Standards Mode rendering in Mozilla, which might affect the presentation of certain elements.

As for performance, I’d say benchmark with the correct code and only allow the deprecated stuff through if you have performance problems.

Definitely the best approach, but hard to motivate the time for doing it and the people that needs to be involved, to the manager/-s responsible, if the only errors are a couple of invalid attributes.

Perhaps I’m atypical, but I’ve *never* found a case where this is actually necessary. Every instance I can think of where somebody has wanted to do this, there’s always been a valid way of doing it without it being a hack - you aren’t limited to the class attribute, you can use other attributes and element types - meta, cite, rel, rev, all sorts. I think people forget about these because browsers don’t have any built-in behaviour for many of them.

There is one decent reason for using custom attributes, and that’s when it’s the only way of getting a certain effect in a browser. In particular, Internet Explorer drives me nuts because they could easily have allowed a meta element or similar to do the things that they want, but instead forced people to use invalid code.

To nitpick, I don’t think it’s sensible to talk about whether a DOM tree is *valid*, because validity is something that encompasses syntax, which isn’t expressed in a DOM tree. However, it does make sense to talk about whether it conforms to the specifications, and using custom attributes means your DOM tree is non-conformant.

As far as deprecated attributes goes, I’d say that if you can’t get rid of them, use a Transitional doctype - unless you run into doctype switching issues of course.

As for performance, I’d say benchmark with the correct code and only allow the deprecated stuff through if you have performance problems. Sure, you might have wasted your time in a few instances, but in the most common case, you’ll have ended up with a better product. If there’s performance problems down the line, you can always disable the extra code.

Dave,

I definitely remember older versions of Internet Explorer having problems with multiple classes - try Internet Explorer 4 (Win) or 5.2 (Mac). I’m not sure when they fixed it.

I tried recreating the scenario you describe with IE/Win(6.0) applying styles that begin with those names. I couldn’t recreate that.. do you have more evidence of that happening, or is it with other IE/Win versions?

On the one hand, if one strives for absolute standards compliance, there is no question whether to use invalid attributes (or elements) or not, even within certain time constraints. (The only time I had this problem was when considering sIFR for image replacement - but the “sifr” attribute made it a definite no-go, unfortunately.)

On the other hand, if this problem is induced by certain tools, then one’s using the wrong tools. Yah, simple, but it’s just true.

There are two parallel tracks here, so let me address them separately:

Track one: I do not in any way promote invalid attributes when hand-coding (or Dreamweavering, for those of you who swing that way). In my code I always use correct attributes for correct elements. What I was going for was that deprecated attributes which are automatically generated by your environment (for instance, by .NET) will not affect the rendering in web browsers, thus they end up last on my priority list since they won’t break the web site in question. As I state in my post, if time is given I take care of them too.

Another question I wanted to raise with this was that when there are ways to fix the automatically produced incorrect output through string parsing and such, but there’s a risk it might affect performance (at least for high-traffic web sites), what should you choose? With major .NET projects, I’m personally afraid of getting a lesser performance of the web site just to satisfy my own need to remove a few invalid name and language attributes. If you then have a customer that demands code that validates, you present these options to them and it’s their call. It’s all about prioritizing.

Track two: This is about using custom attributes for JavaScript hook-up. I had an interesting discussion with Jeroen Mulder off-site and he also pointed me to his post Class and ID are not presentation-centered, and I also read Jim’s and other people’s comments thoroughly.

Humbly, I’ll back down on this. Using the class attribute isn’t only for attaching CSS and it’s definitely applicable to use the class attribute for something else like this: class="required". But Frode is on to something: in very advanced web applications, sometimes a single attribute isn’t sufficient and one doesn’t want to do string parsing of different hyphen-separated values in the class attribute value.

Dustin,

My take is that if you don’t accept invalid attributes in the HTML code, you shouldn’t do it through DOM either.

Yes, the class-attribute is quite semantic and functional for hooking up behavioral Javascript - and you could even make the analogy of it being similar to implementing Interfaces in OOP. But attributes have a purpose of giving a value to some property of the element, and how would you go about doing this with class-names? Create your own class-name-format, using a hyphen to separate property from value (i.e. class=”equalTo-anotherElement”)?

I’m not completely against using invalid attributes, but I mostly see uses for it in more advanced web-applications. Adding class-names for describing behaviour/functionality of an element through Javascript is really fine, and makes sense to me, and it facilitates even more unobtrusiveness in the script.

BTW, everyone interested in using class-names for adding behaviour should look into Simon Willison’s original getElementsByClassName or it’s improved versions. And maybe Ben Nolan’s Behaviour as well..

You could create a form description class that takes a form ID as part of the constructor.

But alas, I’m just being pedantic. Tying into the class attribute works just fine, too.

I’ve been searching for an open source CMS that fits those requirements for some time, but have so far struck a blank.

On the invalid attribute issue I get your point, but I disagree ;-). As Jim already said: how will you quickly and easily tell when you have a “real” error? And if you have clients that specifically request that their sites validate, how are you going to teach them to distinguish a harmless validation error from a catastrophic one?

Sure, put fixing that .Net stuff at the bottom of your list. But do fix it.

I strongly disagree with your feeling that class is just for CSS. It’s never been true, the only loud voice that pushes that misconception is ppk, and I think his overenthusiasm for his technique is clouding his judgement in that respect.

The HTML specification itself states that class is, among other things, suitable for general purpose processing:

The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes. A class name may be shared by several element instances. The class attribute has several roles in HTML:

* As a style sheet selector (when an author wishes to assign style information to a set of elements).
* For general purpose processing by user agents.

The id and class attribute allow authors to assign name and class information to elements for style sheets, as anchors, for scripting, for object declarations, general purpose document processing, etc.

I can appreciate that if you have only ever used class for stylesheets before, the use of them for scripting can appear to be a bit of a hack, but that’s simply not the case. The class attribute has *always* been bigger than mere styling. It’s just that, until recently, the Javascript community has been dominated by scripters who are unaware of the W3C and choose to invent their own ways of doing things instead of using existing attributes in the manner in which they are intended. CSS, on the other hand, has always had a strong contingent of W3C-aware developers and is more reliant upon the class attribute.

Thank you for those!
After looking at them, I remember seeing one of them a while ago.

Also, when it comes to the customer, they would never accept that their web site doesn’t validate in the W3C validator just because I used a custom DTD for some attributes.

http://www.alistapart.com/articles/customdtd
http://www.alistapart.com/articles/customdtds2

I was mainly going for old deprecated attributes when describing them as not important. They should be safe to have there anyway.

Jeroen and Tommy,

In my opinion, using a class attribute that doesn’t have any corresponding rule in the CSS feels like an incorrect approach, although I share Tommy’s fear about using a custom attribute name that then might show up in a future specification. Personally, I therefore don’t use custom attributes but I wish there really were some that could be used for JavaScript-only hook-ups.

Marco,

I agree with every word you wrote.

Kalle,

I have to use the saying “get a project to harbor” more often!

If it’s written in an agreement that it has to validate, it’s a totally different question.

And I haven’t tried the validator with a custom DTD.

Jim,

I do promote writing valid code, and as you state, it’s really helps less experienced web developers if it’s all valid instead of trying to guess which errors are “ok” and which aren’t.

When it comes to custom attributes, see my answer above to Tommy and Jeroen.

How about if you went from completely valid and zero errors to invalid and one error? Will you notice then?

What about when your new junior hire starts making mistakes? Is he qualified to know when some errors are okay and others aren’t? Are you going to spot his mistakes even if he doesn’t?

When there’s no way to do what you want and also conform to the specification, I understand deviating from spec. But there’s really no need for inventing new attributes. Sure, you might be able to cut a few corners here and there, but you are only shifting that extra work into QA. Obviously the people who don’t do any QA won’t notice and tout the “savings”, but it’s really just false economy.

I think that there are two ways of seeing this, the HTML and the XML way.
In the world of HTML there has always been quirks and I believe that that it will continue to be like that as long as non-pro’s are maintaining their personal websites…
But in the world of XML a “faulty” attribute would force you to remove the attribute or update your DTD.

If you as a developer have comitted yourself to deliver standards compliant code in a business agreement you actually don’t have the option to ignore some faulty attributes, if you stick to the agreement that is…

// Kalle

BTW: has anyone tried running the W3C validator on a page with a custom DTD? Does it work at all?