I'm currently on parental leave till September. During that time, I will not read any e-mail or blog comments.

Until I'm back, please read through my archives, take a look at my code/applications and check out my pictures.

Have a great summer, and a splendid winter to you aussies and kiwis!

How bad is an invalid attribute?

Published on Tuesday, October 11th, 2005

To start with, if this is not your first visit here, you know I’m all for web standards. But from time to time, I feel that things get exaggerated. There’s a validation frenzy and way too much work, time and focus put into the wrong details.

IT projects are almost always under a tight deadline and compromising is usually a way of web development life. So, my pet peeve is invalid attributes on elements. When I write code, of course I refrain from using them, hence making it valid. But in my case, I work in a lot .NET-based projects and Web Forms and such in it produces invalid code, especially when using a strict HTML or XHTML doctype. Examples can be attributes like language=JavaScript and the name attribute on the form tag. There are ways to take care of this, but they might affect performance, especially for a web site with a lot of visitors.

While these attributes render the page invalid, to me it doesn’t really matter. I regard it as much more important to focus on writing accessible and semantic code, and where the presentation is a 100% controlled from CSS. And, as Peter-Paul Koch writes in Why QuirksMode, there are a lot of cases where using custom attributes whould make the code a lot cleaner and understandable. Having an attribute named “mandatory” on a form element would make a lot more sense that adding a class for it. Especially if the class attribute then weren’t used for any presentational purpose whatsoever, but only for hooking it up with JavaScript.

So, my advice is: Make sure your code is well-formed, but after that, focus on the important parts instead of unsignificant things like an invalid attribute. Then, if you have time, take care of the attribute too.

23 comments

Jeroen Mulder
October 11th, 2005 at 12:19

Definitely. Validation is a good way to test for incorrect use of current standards, but it just doesn’t always cover all bases.

Though, I must disagree with your and PPK’s point about a mandatory attribute and whether classes are solely used for Javascript ‘hookups’ or not, but that might be something for a new article
Tommy Olsson
October 11th, 2005 at 13:42

The risk you take by using a non-standard attribute is that it will eventually become standard - but with an entirely different meaning.

Using old attributes like language on a SCRIPT element ought to be quite safe, since the W3C won’t reuse those.

Making up your own, like mandatory, is more iffy. For required form fields, class="required" should be perfectly all right. The class attribute exists so that we can assign various traits to our elements. Granted, it is normally used for presentational aspects, but it will work just as well for behavioural aspects.

No need to reinvent the wheel.
Marco
October 11th, 2005 at 13:43

If you’re working with .NET objects or other pre-written code that generates garbage HTML (a lot of .NET modules excel in this stupidity) there’s no point in trying to be valid anymore. Like you said, you just produce nice and well-formed code and you’ll do fine most of the time even though the validator doesn’t like it.

As long as you don’t put a ‘Valid XHTML’ link on your site I guess no one is going to whine as browsers really don’t care about invalid attributes. You just won’t get accepted at StyleGala
Kalle Wibeck
October 11th, 2005 at 13:50

Of course there are times when you have no option but to compromise in order to “get a project to harbor” (anglification of a swedish saying).

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?
Jim
October 11th, 2005 at 13:58

Okay, so when you are validating, and your error count goes from 123 (all “okay” errors) to 124 (123 “okay” errors and one “proper” error), are you going to notice?

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.
Robert Nyman - author
October 11th, 2005 at 14:09

Tommy,

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.
Jens Wedin
October 11th, 2005 at 14:18

Have you read the articles over at ALA about custom DTD’s? Quite interesting.

http://www.alistapart.com/articles/customdtd
http://www.alistapart.com/articles/customdtds2
Robert Nyman - author
October 11th, 2005 at 14:28

Jens,

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.
Jim
October 11th, 2005 at 16:19

Robert,

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.
Roger Johansson
October 11th, 2005 at 17:48

I agree with Jim here: the class attribute is not just for CSS. It’s perfectly fine to use it to add hooks for a script.

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.
Steve Williams
October 11th, 2005 at 20:37

Perhaps I could stand on the shoulders of giants and graciously ask what full-blown CMS *is* recommended for valid, tableless, semantic code when you’re free to choose?

I’ve been searching for an open source CMS that fits those requirements for some time, but have so far struck a blank.
Jonathan Snook
October 11th, 2005 at 21:05

If your intention is to set attributes for hooking into the behavioural layer, why not just describe any of these attributes at the behavioural level.

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.
Dustin Diaz
October 11th, 2005 at 23:38

I think it’s invalid if it’s deliberately inserted by hand, but there is a clear exception made when they are put in thru DOM scripting. The DOM memory may show that it’s invalid, but as far as the original source and validator is concerned, your document remains completely valid.
Frode Danielsen
October 12th, 2005 at 0:02

One part of my answer is at Roger Johansson’s follow-up.

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..
Robert Nyman - author
October 12th, 2005 at 10:17

Thanks everyone for sharing your opinion!

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.
Patrys
October 12th, 2005 at 10:57

Actually, class attribute can accept any number of space-separated names. This works equally fine for both CSS and JS. Well, with one exception, if you do something like class="foo bar", Internet Explorer for Windows will apply all styles with classes that begin with both foo and bar instead of performing a exact string match. Thus .fooBaz will also get applied. Simply, if you use multiple classes for one element try to keep your class names unique in terms of common prefixes.
Jens Meiert
October 12th, 2005 at 11:03

Two thoughts:

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.
Dave M
October 12th, 2005 at 15:24

Patrys:

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?
Jim
October 12th, 2005 at 15:55

I agree with Robert, Frode has a point - that custom attributes allow you to assign arbitrary values to arbitrary properties without using a hack with the class attribute or similar.

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.
Robert Nyman - author
October 12th, 2005 at 16:49

Jens,

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.
Frode Danielsen
October 12th, 2005 at 23:28

Jim,

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.
Patrys
October 13th, 2005 at 12:53

Dave M:

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.
Jim
October 19th, 2005 at 11:42

Frode,

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.

All the proceeds from ad clicks will go to charity. However, if you like to give something directly to charity yourself, I recommend choosing from the listed ones below.