How bad is an invalid attribute?
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
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
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.
- March to Your Own Standard by Mike Davidson
- Standards-wielding maniacs by Peter Krantz
- How to generate valid XHTML with .NET by yours truly
Definitely. Validation is a good way to test for incorrect use of current standards, but it just doesn't always cover all bases.
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 <code>language</code> on a <code>SCRIPT</code> element ought to be quite safe, since the W3C won't reuse those.
Making up your own, like <code>mandatory</code>, is more iffy. For required form fields, <code>class="required"</code> should be perfectly all right. The <code>class</code> 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. 😉
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 😀
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?
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.
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,
I agree with every word you wrote.
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 <acronym title="Document Type Definition">DTD</acronym>.
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.
Have you read the articles over at ALA about custom DTD's? Quite interesting.
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:
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 <acronym title="Document Type Definition">DTD</acronym> for some attributes.
I agree with Jim here: the <code>class</code> 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.
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.
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. 🙂
One part of my answer is at Roger Johansson’s follow-up.
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..
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.
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
languageattributes. 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.
Humbly, I’ll back down on this. Using the
classattribute isn’t only for attaching CSS and it’s definitely applicable to use the
classattribute 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
My take is that if you don’t accept invalid attributes in the HTML code, you shouldn’t do it through DOM either.
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 <abbr>sIFR</abbr> 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.
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.
True, although it sounds like they can be a bit misused then; like a
relattribute containing a GUID and such.
I agree, but then you have the risk with the Almost Standards Mode rendering in Mozilla, which might affect the presentation of certain elements.
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.
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?
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.
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.
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.
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.
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.
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.