For certain behaviors, I’ve used this technique. I also like it for validation triggered as you go (via onchange) rather than onsubmit.
But for validation triggered from onsubmit, it doesn’t scale and I don’t like how I’m forced to maintain it. After a form gets sufficiently complex, putting the validation parameters within each element becomes difficult to manage and support. It is much easier, in my experience, to clump all of your validation code together within a single function, even if it means that removing a field now means to have to do it twice (once in the HTML, once in the validation script). This becomes even more important when you have interconditional validation such as “If Status is not draft and Time_Sensitive is checked then make sure the estimated date is populated, valid, and, if marked as high priority, also within the next two weeks.”
I’ve finally settled on a standard validation script library ( http://www.openntf.org/Projects/codebin/codebin.nsf/CodeBySubContributor/6B4512863D22FC9288256BF900521391 ) and love it (except that I’ve yet to get around to integrating overlib instead of an ugly alert box).
By the way, a related link you might find interesting mixing presentation with validation by changing the css class name from “RequiredField” to “ValidField” in the onchange: http://codestore.net/store.nsf/unid/DOMM-4RZH6P?OpenDocument Mixing that idea with this article would have some potential.
Good response PPK. Excuse my overuse of metaphors, but redirecting someone in a situation like that would be the equivalent of you driving someone out to the middle of nowhere when they asked you for directions.
I had a thought about getting around the whole validation problem thing. The only solution to use custom attribues WITHOUT any sort of DTD and to have the page validate is, well, there is none. It’s called a “tradeoff”. We have a lot of them (fixed vs fluid-width, text/html vs application/xhtml+xml, etc). I’m suprised so many developers aren’t used to them by now.
Copy & paste the code below to embed this comment.
JD
For what it’s worth, to you probably not a lot, but to my clients a good chunk of change :), I thought I’d add my thoughts.
To start with let me thank PPK and all of you who have taken the time to contribute to this discussion. Not only has this article and comments been informative, but genuinely entertaining to think about. It’s these kinds of issues that make web design and development so interesting to me.
Let me also say that, like many developers, I strive for standards compliant design and development, but occasionally make non-compliant choices (or I should say compliance with older standards) brought on by the reality of today’s browsers. Even the great Eric Meyers, CSS guru, uses a table for the basic layout of his examples in his books. gasp However he strives for CSS usage in all other ways.
So I’ve decided on the following path for myself:
1. I’m going to add one additional attribute to my HTML elements, behavior. I think this will add the least and get me the most.
2. I’m going to keep my values for this attribute as simple as possible. This is how I make my values for the class attribute.
3. I think I need different “groupings” for presentational and behavioral. For example, I want to display form elements in a single form in a consistent manner, but I want to validate email addresses in forms in a consistent way across pages in an application. I think the combination of IDs, classes, and “behaviors” will give me all the hooks I need to handle the situations I’ve seen presented here and reduce redundancy in my code.
4. I think this will keep my JavaScript as simple, clean and atomic as possible.
5. I don’t have a problem with a custom DTD.
6. I want to keep the details of my behaviors external to my structure. For me I’ve decided to keep these details in my JavaScript file. The reason I went with this as opposed to external XML files, etc, is again to keep my JavaScript and other code as simple as possible.
So there it is. My “centrist?” view of the ideas presented here.
Thanks again for providing a space for and participating in this discussion. It’s been very useful for me.
Very often I find myself using a class I’ve written in PHP to generate forms dynamically, by which I mean, you can generate the forms from any database table without prior knowledge of what the table structure is. It is aware of the field lengths in the database and so for input elements it can dynamically include the maxlength attribute.
For me this answers the question of whether maxlength information should be considered structural or behavioural: it just doesn’t matter. There just is no other good place to put the information except in the XHTML file when it is generated, either using element attributes or (as someone else suggested) inside a comment near the element.
I have no problem thinking that the requirements of form fields are structural. What you end up doing when a user breaks the constraints is behavioural. In fact I’d go so far as to say that the choice bewteen textarea and input is more presentational than structural, whereas the validation requirements of the field are more structural than behavioural. The lack of maxlength attribute for textareas is an oversight. But that’s just my take.
I love the idea of using custom attributes. I’ve used classes to achieve this sort of thing in the past, and like the idea of using attributes for this purpose.
The only thing I might add is the use of namespaces to use attributes within my own namespace. For example js:required as opposed to just required. This would clearly call out that the attribute isn’t defined by XHTML, rather some names space called js. Namespaces in XML is a w3c standard: http://www.w3.org/TR/REC-xml-names/
secured to the referenced articles of exploring those greetings off records,why break point?Systematically my motives toward
further highlights to my 1st read indicates it
is coming a-long.Now a natural formatt direct-
ed already impedes as interluctory attributes
however what does this mean?Structured analysis impliments my hope to those compiled
referenced directions.My 1st DTD.reciped add
xhtml,fol.by an ia},nobones;ah you already have my formula,I’ll consolidate when noid +
sign is.RF><LF,turn and attribute live.Romnoid
Copy & paste the code below to embed this comment.
Delbert Mitten
Why not just perform a match on the Name of the text field? For instance, I use an onload=init() for the body that searches through all of the input tags that are type=text and adds onblur=validateDate(this) if the name of the text field contains ‘Date’. I do something similar for ‘Phone’ and pretty much anything else I need to validate.
I can also use the same code to add any number of classes to any or all of the text fields. That way all the structure has to have is “<input type=text name=xyzDate>” and onload javascript attaches both presentation AND behavior so changing either requires absolutely NO changes to the structure.
Copy & paste the code below to embed this comment.
Justin
I’ve been following this debate (and the larger debate on alistapart.com) over structure vs. presentation.
I have to say that part of me that wants things to be logical and efficient leans toward defining my web pages semantically, and then using CSS to control layout and design.
However, the realist in me knows that this is a practical impossibility. Anyone that has designed a slightly complex website – especially one that involves variable formatting between pages – knows that writing perfectly semantically driven code is impossible. We always end up making little compromises to get our layout to work right. stuff like <div class=“clear”></div>
is not semantic – but sometimes its the only way to deal with floated columns. Look at the code for this website – try and argue that its semantic not presentational! If alistapart.com, a magazine which is dealing with very spefic and predicable data chunks and consistent presentation, can’t write semanic code who can?
The funniest thing is that we can kill ourselves designing these perfectly defined documents, but don’t all websites designed this way tend to end up looking very similar? Why? because if we design our documents semantically we lose a lot of layout flexibility. We can use CSS to achieve complex designs that look even better than table based designs – but websites designed this way are never defined semantically – and never will be, because at the end of the day, web pages are presentational documents. We don’t see similar arguments in the print layout community for semantically designed documents – so why in the web design community?
I think the larger debate is an interesting one, but that in truth it applies to only a small subset of website applications, such as content management systems; and that even within this small subset of applications there is a lot or room for flexibility in how one strikes a balance between semantic logic and presentational necessitates.
For MOST websites, none of this should be a concern. We can argue all we want if maxlength=200 is presentational or structural, and those people that design websites with the maxlength=200 hidden somewhere deep in the JavaScript because they have a firmly rooted ideological belief that it is structural not presentational – bring me a website that has no <div class=”clearboths”><div>’s I’ll be very impressed – but more surprised.
Copy & paste the code below to embed this comment.
Delbert Mitten
Justin, your point is well made and quite on target, however, it is possible to make completely semantic sites and then, via JavaScript, add not only the behaviours, but also any “presentational” elements such as the divs you mentioned.
140 Reader Comments
Back to the ArticleJohn Smart
For certain behaviors, I’ve used this technique. I also like it for validation triggered as you go (via onchange) rather than onsubmit.
But for validation triggered from onsubmit, it doesn’t scale and I don’t like how I’m forced to maintain it. After a form gets sufficiently complex, putting the validation parameters within each element becomes difficult to manage and support. It is much easier, in my experience, to clump all of your validation code together within a single function, even if it means that removing a field now means to have to do it twice (once in the HTML, once in the validation script). This becomes even more important when you have interconditional validation such as “If Status is not draft and Time_Sensitive is checked then make sure the estimated date is populated, valid, and, if marked as high priority, also within the next two weeks.”
I’ve finally settled on a standard validation script library ( http://www.openntf.org/Projects/codebin/codebin.nsf/CodeBySubContributor/6B4512863D22FC9288256BF900521391 ) and love it (except that I’ve yet to get around to integrating overlib instead of an ugly alert box).
By the way, a related link you might find interesting mixing presentation with validation by changing the css class name from “RequiredField” to “ValidField” in the onchange: http://codestore.net/store.nsf/unid/DOMM-4RZH6P?OpenDocument Mixing that idea with this article would have some potential.
ppk
>yet when I follow the link to the quirksmode
>site, it doesn’t recognise firefox,
Why should it have to recognize Firefox? Any site should work in any browser (and mine does).
>and so I have to view a java-free version of >the site.
My site is guaranteed 100% Java free because I don’t have the faintest idea how to write Java. Therefore every visitor sees the Java-free version.
JavaScript is another matter, of course. If your browser doesn’t support the W3C DOM it doesn’t get the JavaScript interface.
>Then, on the browser page, no mention of >firefox? What of these 25 million new users?
It mentions Firefox’s parent browser rather a lot, and with lots of details. You do need to know just the tiniest bit about browsers, though.
>I not only had to view an ugly “quirks..site
>doesn’t support your browser” 404 style page,
That’s not what the page says. Please read again.
>but it didn’t even auto-redirect.
Where should it redirect to? Isn’t it better to give the visitor a choice of destinations?
Dante
>but it didn’t even auto-redirect.
Good response PPK. Excuse my overuse of metaphors, but redirecting someone in a situation like that would be the equivalent of you driving someone out to the middle of nowhere when they asked you for directions.
I had a thought about getting around the whole validation problem thing. The only solution to use custom attribues WITHOUT any sort of DTD and to have the page validate is, well, there is none. It’s called a “tradeoff”. We have a lot of them (fixed vs fluid-width, text/html vs application/xhtml+xml, etc). I’m suprised so many developers aren’t used to them by now.
JD
For what it’s worth, to you probably not a lot, but to my clients a good chunk of change :), I thought I’d add my thoughts.
To start with let me thank PPK and all of you who have taken the time to contribute to this discussion. Not only has this article and comments been informative, but genuinely entertaining to think about. It’s these kinds of issues that make web design and development so interesting to me.
Let me also say that, like many developers, I strive for standards compliant design and development, but occasionally make non-compliant choices (or I should say compliance with older standards) brought on by the reality of today’s browsers. Even the great Eric Meyers, CSS guru, uses a table for the basic layout of his examples in his books. gasp However he strives for CSS usage in all other ways.
So I’ve decided on the following path for myself:
1. I’m going to add one additional attribute to my HTML elements, behavior. I think this will add the least and get me the most.
2. I’m going to keep my values for this attribute as simple as possible. This is how I make my values for the class attribute.
3. I think I need different “groupings” for presentational and behavioral. For example, I want to display form elements in a single form in a consistent manner, but I want to validate email addresses in forms in a consistent way across pages in an application. I think the combination of IDs, classes, and “behaviors” will give me all the hooks I need to handle the situations I’ve seen presented here and reduce redundancy in my code.
4. I think this will keep my JavaScript as simple, clean and atomic as possible.
5. I don’t have a problem with a custom DTD.
6. I want to keep the details of my behaviors external to my structure. For me I’ve decided to keep these details in my JavaScript file. The reason I went with this as opposed to external XML files, etc, is again to keep my JavaScript and other code as simple as possible.
So there it is. My “centrist?” view of the ideas presented here.
Thanks again for providing a space for and participating in this discussion. It’s been very useful for me.
JD
Tim Burden
Very often I find myself using a class I’ve written in PHP to generate forms dynamically, by which I mean, you can generate the forms from any database table without prior knowledge of what the table structure is. It is aware of the field lengths in the database and so for input elements it can dynamically include the maxlength attribute.
For me this answers the question of whether maxlength information should be considered structural or behavioural: it just doesn’t matter. There just is no other good place to put the information except in the XHTML file when it is generated, either using element attributes or (as someone else suggested) inside a comment near the element.
I have no problem thinking that the requirements of form fields are structural. What you end up doing when a user breaks the constraints is behavioural. In fact I’d go so far as to say that the choice bewteen textarea and input is more presentational than structural, whereas the validation requirements of the field are more structural than behavioural. The lack of maxlength attribute for textareas is an oversight. But that’s just my take.
Robert Petersen
I love the idea of using custom attributes. I’ve used classes to achieve this sort of thing in the past, and like the idea of using attributes for this purpose.
The only thing I might add is the use of namespaces to use attributes within my own namespace. For example js:required as opposed to just required. This would clearly call out that the attribute isn’t defined by XHTML, rather some names space called js. Namespaces in XML is a w3c standard: http://www.w3.org/TR/REC-xml-names/
}Tommy J.Sexton
secured to the referenced articles of exploring those greetings off records,why break point?Systematically my motives toward
further highlights to my 1st read indicates it
is coming a-long.Now a natural formatt direct-
ed already impedes as interluctory attributes
however what does this mean?Structured analysis impliments my hope to those compiled
referenced directions.My 1st DTD.reciped add
xhtml,fol.by an ia},nobones;ah you already have my formula,I’ll consolidate when noid +
sign is.RF><LF,turn and attribute live.Romnoid
Delbert Mitten
Why not just perform a match on the Name of the text field? For instance, I use an onload=init() for the body that searches through all of the input tags that are type=text and adds onblur=validateDate(this) if the name of the text field contains ‘Date’. I do something similar for ‘Phone’ and pretty much anything else I need to validate.
I can also use the same code to add any number of classes to any or all of the text fields. That way all the structure has to have is “<input type=text name=xyzDate>” and onload javascript attaches both presentation AND behavior so changing either requires absolutely NO changes to the structure.
Justin
I’ve been following this debate (and the larger debate on alistapart.com) over structure vs. presentation.
I have to say that part of me that wants things to be logical and efficient leans toward defining my web pages semantically, and then using CSS to control layout and design.
However, the realist in me knows that this is a practical impossibility. Anyone that has designed a slightly complex website – especially one that involves variable formatting between pages – knows that writing perfectly semantically driven code is impossible. We always end up making little compromises to get our layout to work right. stuff like <div class=“clear”></div>
is not semantic – but sometimes its the only way to deal with floated columns. Look at the code for this website – try and argue that its semantic not presentational! If alistapart.com, a magazine which is dealing with very spefic and predicable data chunks and consistent presentation, can’t write semanic code who can?
The funniest thing is that we can kill ourselves designing these perfectly defined documents, but don’t all websites designed this way tend to end up looking very similar? Why? because if we design our documents semantically we lose a lot of layout flexibility. We can use CSS to achieve complex designs that look even better than table based designs – but websites designed this way are never defined semantically – and never will be, because at the end of the day, web pages are presentational documents. We don’t see similar arguments in the print layout community for semantically designed documents – so why in the web design community?
I think the larger debate is an interesting one, but that in truth it applies to only a small subset of website applications, such as content management systems; and that even within this small subset of applications there is a lot or room for flexibility in how one strikes a balance between semantic logic and presentational necessitates.
For MOST websites, none of this should be a concern. We can argue all we want if maxlength=200 is presentational or structural, and those people that design websites with the maxlength=200 hidden somewhere deep in the JavaScript because they have a firmly rooted ideological belief that it is structural not presentational – bring me a website that has no <div class=”clearboths”><div>’s I’ll be very impressed – but more surprised.
Delbert Mitten
Justin, your point is well made and quite on target, however, it is possible to make completely semantic sites and then, via JavaScript, add not only the behaviours, but also any “presentational” elements such as the divs you mentioned.