Are invalid attributes valid?

How bad is an invalid attribute? Robert Nyman asks the question and mentions the invalid attributes that .NET controls tend to output as an example of when you can live with a few harmless validation errors if the project deadline is so tight that you have to cut corners.

Obviously if there just isn’t time to fix errors that won’t prevent anyone from using the site, there may be more important things you should spend your time on. But I think that leaving invalid attributes in your markup is something you should think very carefully about, for several reasons:

  • It makes quality assurance more difficult. How much time will you have to spend scanning through the list of errors reported by the validator, looking for “real” errors?
  • Who will decide and take responsibility for which errors are harmless and which need to be fixed?
  • How will you explain to your clients (assuming they are the kind of clients that care about validation) why their sites do not validate? How much time will you need to spend on teaching them the difference between harmless and potentially catastrophic validation errors?
  • What’s next? Allowing invalid elements? Not caring too much about well-formedness? Leaving invalid attributes in your markup may be the start of a slippery slope. It doesn’t have to be, and in Robert’s case I know it won’t be, but the risk is there.

In my opinion, leaving invalid attributes in your markup should be seen as a last resort.

Posted on October 11, 2005 in Quicklinks, Web Standards

Comments

  1. As part of k2 default it has the Mac’s which defautlts if not on a Mac to text otherwise gives a swanky search field. Purely asthetics but it’s not completely wrong and it doesn’t muck things up.

    Also they use ‘autocomplete=”no”’… which makes sense really. Quite a functional non-real attribute.

    I think both are ok to be honest. Both do not affect the running of the page and I think thats the important thing

  2. Not on Mac’s, but in all browsers based on WebKit 412 or newer.

  3. You have to wonder if they’re invalid upon when they’re inserted. If they are diliberately inserted by hand the first run through, then I would say it’s invalid… but if inserted thru dom scripting, then what? it’s valid to the regular source, but not according to the DOM memory… who’s the judge… it gets real tricky around that area.

    In general I’ve always followed the rule that it’s valid when inserted into the DOM with JavaScript, but not valid when hand-coded… if that makes any sense. If others disagree, then I could potentially see why. It just so happens that custom attributes give you much more freedom when developing (like xml).

  4. It’s a tricky dilemma, for sure… The WebKit example brought up by Zach is kind of different. This time it’s a browser vendor who’s introduced a few new attributes and actually also tags. In my own view, most of those from WebKit are sensible, and I hope the W3C and other browser vendors at least considers them seriously.

    On the other hand, you have the possibility of using invalid attributes which can be accessed and used purposely through DOM scripting. Another one to use carefully, but especially in controlled circumstances (i.e. in a web-application you have browser-requirements for) this could be useful for giving a better user interface.

    But, the kind of invalid attributes Robert Nyman mentions first is in my view bad to ignore. These are attributes which have been deprecated and been replaced by other more versatile attributes. Of course, they need not be the first thing you fix, since they won’t necessarily break stuff, but I wouldn’t ignore them completely in a production.

    God these long comments of mine sure make me feel in need of using a blog of my own to comment.. In due time, I promise..

  5. October 12, 2005 by Poncho

    It’s a fair question and I guess it applies mostly to server generated code from .NET or PHP (assuming you know what you are doing with (x)html).

    If you need to have complete control over every generated form field sometimes that means ‘fixing’ the appearance of each generated element and on large complex web applications, that doesn’t always afford much time for anything else ie. the application :-)

    I have seen a few sites purposefully breaking valid code just because they wanted to use an invalid ‘required’ attribute. I don’t see why we can’t use ‘class’ attributes or even an element naming convention to hook into javascript. Sure, we may have ‘required’ attributes in the future but why use invalid code now? A little extra effort gains the same functionality AND it would validate.

    I have great hopes that Web forms 2.0 will be accepted and ratified by the w3c, that would make dealing with forms that much more manageable.

    Cheers; Poncho

  6. I find creating a new namespace for extra attributes I would like to use to have more information about elements works well in some cases.

  7. It’s been my experience, with .NET anyway, that invalid attributes are actually a sign of something far worse. An outright ignorance of the necessity of valid markup. I sat in on an MS .NET conference and hearing the speaker talk about markup and CSS was torture. My experience has been that for the most part programmers see markup as a triviality and that the real work happens in their code. Which, of course I find to be quite nearsighted. But I digress…

  8. October 12, 2005 by hostyle

    I’m with Super K on this one. If you can’t validate you shouldn’t claim to do so by including a DTD. If you must break the validity of your (X)HTML build your own DTD schema - ALA covered this a few months back. While its not something for the average Joe, surely Microsoft have people intelligent enough to do this (create their own DTD that allows invalid .NET attributes to validate)?

  9. I’ve replied this in my comment.

  10. Gosh, what’s going on - recent discussion on www-style proposed to allow proprietary CSS properties in validation, now there are considerations if invalid attributes are acceptable. […]

  11. I agree you might as well create a Schema or modified DTD rather than create nonsense attributes if it appears within the final HTML.

  12. October 12, 2005 by Paul D

    What the XHTML spec really needs is some provision for custom attributes – perhaps starting with a hyphen, so as not to clash with future XHTML attributes. That way, you could do something like -foo=”bar” or -required=”false”. Attributes are semantically different from classes, and combined with CSS gives you more design flexibility.

    Barring that, custom DTDs sound like an okay way to handle the problem. It be useful if someone made a web application that could generate custom DTDs.

  13. Paul,

    What the XHTML spec really needs is some provision for custom attributes

    XML/XHTML has had this for years, it’s called namespaces. You can only use them with application/xhtml+xml though, so we’re stuck waiting for Internet Explorer 8 before they become viable.

  14. Shouldn’t you just code the project from the beginning without invalid attributes? That makes more sense than putting them in, or the wrong ones in, and having to go back through it all again to correct validation mistakes.

  15. October 13, 2005 by Roger Johansson (Author comment)

    the english guy: Oh, yes, definitely. Unfortunately that isn’t always possible for those who use a CMS based on Microsoft technology.

  16. October 19, 2005 by Eric Shepherd

    I’m actually just running into this, not because we use .NET, but because we need to call tracking code for some links and write a “friendly name” into the tracking report. What seems to me to be a good idea instead of using a class, is to use a custom attribute track=”Official Name for Tracking Report”. I don’t want to just use a valid element for a purpose it wasn’t designed for, but I don’t want to use a class=, because I’d have to parse through it to add spaces and commas and the like.

    We’re not using XHTML (yet) so we can’t even write our own extended DTD, and I’m not sure I want to go to that extreme anyway.

    This seems like a case where a custom attribute wouldn’t hurt anything and would give us the functionality we need with correct semantics as well, and it’s not like any outside UA needs to know what the attribute means. It’s just for a JavaScript to write tracking code.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.