text:
Comments on JavaScript Triggers
by Peter-Paul Koch Published in JavaScript
140 Reader CommentsBack to the Article
Woolly Mittens (article author)
I've been poking into this method of seperating the functionality from the markup too. I scan the document for certain key classnames and I add fun little event handlers accordingly. You might want to have a look over here: http://www.woollymittens.nl/content/weblab/lib_classbehaviourCopy & paste the code below to embed this comment.
Adrian Holovaty (article author)
I'm interested in hearing more reasoning about why "the class attribute should only be used for CSS," as I've used classes for unobtrusive JavaScript for a while now and find it to be an incredibly useful technique.
It seems like it's not worth the hassle to create a custom DTD just for the sake of adding custom attributes. What's really that wrong with using classes?Copy & paste the code below to embed this comment.
Dante (article author)
I hope you can hear my applause in the Netherlands, PPK. This is why I respect you so much, for insight like this. Great!!Copy & paste the code below to embed this comment.
Jacob (article author)
Isn't this a bit of a slippery slope? What is the point of writing to standards if you are just inventing your own? I agree with Adrian, it doesn't make sense to go to the trouble of reserving Class attributes for CSS while creating ficticious attributes just for your javascript.Copy & paste the code below to embed this comment.
Jonas (article author)
"y.onmouseover = addBehavior" is non-standard (doesn't comply with ECMAScript or W3C DOM). The right way to do it is to use addEventListener(). Internet Explorer doesn't support addEventListener(), though (as most web developers know, it lacks support for a lot of W3C-standardized stuff). The solution is to try the standards-compliant way first (which modern browsers such as Firefox, Mozilla, Konqueror, Safari, Opera, etc. support), and - if that doesn't work - fall back to the non-standards-compliant method:
try {
y.addEventListener('mouseover', addBehavior, false)
catch (exception) {
y.onmouseover = addBehavior
}Copy & paste the code below to embed this comment.
Dave S. (article author)
Adrian's question is my question: I'd like to see some more reasoning behind why the currently-valid class attribute shouldn't be used for scripting.
The separation of structure/presentation/behaviour doesn't appear to benefit any more from custom attributes than it does from 'misused' classes. The spec—http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2—clearly states that the class attribute may be used for style, but also that it's open for general usage. The latter implies to me that using it for scripting is not a huge stretch.
Further, saying that custom attributes clear up the issue of stating 'deploy behaviour here' that classes introduce is simply untrue. The same argument applies equally to both applications. Your final result in both cases is an indication point in the markup for your script to tie into, you're simply introducing new syntax.
Your suggestion of custom attributes and a custom DTD forms a perfectly valid, future-compatible solution. I just think it seems more trouble than it's worth.Copy & paste the code below to embed this comment.
Dave S. (article author)
Good article, by the way. I'm glad we're talking about this.Copy & paste the code below to embed this comment.
Justin Perkins (article author)
I've struggled with this very problem and because I didn't want to add custom attributes I opted for the class method. I don't think I would have ever thought of creating a custom DTD, but now that the point has been made it seems like a no-brainer.
I always felt as though it was always a hack to use class names for custom Javascript behavior, this easily solves the problem. I don't agree that adding a custom DTD to *extend* the XHTML DTD is bad, I think that is the entire idea behind the the standard allowing the ability to specify your own DTD.
Great work Peter-Paul, this really opens a lot of doors for interactive forms and such.Copy & paste the code below to embed this comment.
ppk (article author)
Dave, Adrian, Jacob,
I have a form validation module that reads out a custom attribute I may define on any form element:
validate="required numerical date"
which means: "this field is required, it must contain a number and it's part of a date". My module reads out all values the custom attribute and then performs the necessary checks one by one: first required, then numerical, then date.
I can be certain that all values of the validate attribute have something to do with the form validation process, but I cannot be sure of all the values of the class, which will probably contain one or more CSS triggers.
It can probably be done, but I feel my solution is more elegant. Feel free to disagree, of course. This is a subjective argument and cannot be conclusively proven one way or the other.
"Further, saying that custom attributes clear up the issue of stating 'deploy behaviour here' that classes introduce is simply untrue."
Correct, and I didn't say that.
They clear up the issue of sending extra information ("maxlength is 300") to the script, something that can be done with classes, but not as easily or as elegantly.Copy & paste the code below to embed this comment.
mateo m (article author)
The main advantage of using custom attributes is that, as the article explains, it allows you to have multiple values passed to your triggers. For example, using custom attributes, you could define a number of validation rules for each form element, like 'require 2-10 integers', which would be pretty messy using the class attribute. So in my opinion, only in the simplest of cases is a custom DTD more trouble than it's worth…Copy & paste the code below to embed this comment.
Charles Martin (article author)
I did appreciate this being brought up as it has been lingering deep in the back of my mind since just about every job I've had required doing development specific to IE alone (either Intranet applications or B2B where it could be dictated what was required). Thus, when coding for IE, who gives a flying flip about standards?
However, I find myself much more leery of jumping into the same scenario when adding javascript and such to my personal website. At some point, we all realize that we have to break the rules somewhere.. whether rules written down by some "authority" on web standards or rules we have laid out for ourselves when developing. What complicates the whole issue is NOT just because the development of web-based applications is limited, but because the demands are on as web developers to jump over those limitations.
Some of the most nightmarish code I've dealt with was because of hearing the phrase "this would be cool.. do you think we can do it?" It wasn't a matter of whether or not it was standards-compliant, we just couldn't back down from a challenge. So we do the cool… and somehow lose a piece of ourself because we broke the rules.
The demands on web developers are growing, while the framework we use is remaining stagnant (due to slow acceptance of the newest standards and lack of standards-happy innovation among browser-developers). Now I'm gonna go curl up in introspective silence.Copy & paste the code below to embed this comment.
Justin Perkins (article author)
So, somebody comes along seeing this article and is trying to add trigger events to their form controls. They are also trying to make the page validate as XHTML, so they think they probably shouldn't use the "onclick" methods to attach events.
Then they see this article and decide to create a custom DTD that allows "onclick" to be in the attributes.
That would be funny.Copy & paste the code below to embed this comment.
Michael Havard (article author)
We've been doing this for a few years now. It helps a lot with validation being able to say 'class="required string"' which then we can apply a certain style to and coopt to use with automated scripting routines. We do alot of this using scripting to either look at the document structure to attach behavior or looking into the classes and other properties for cues as to where to attach functionality. I.E. we have a div with a class="section" which has other divs and headings underneath to show subsections of content. When the class is changed to "section tabpanel" then the script kicks in and attaches clicks to the headings and arranges them in a tab panel format, hiding and showing the sections depending on which heading is selected. It allows for a great deal of customization without touching the content or content structure. It's great to see an article on the process finally.Copy & paste the code below to embed this comment.
Woolly Mittens (article author)
If you're going to write a custom DTD just to add the attributes you need to bolt your event handlers onto. Then why not just add attributes like "onmouseover" and be back where you started?Copy & paste the code below to embed this comment.
Will Rickards (article author)
I think the use vs not use the class attribute debate comes down to this. Using custom attributes leads to cleaner, easier to read html/xhtml code. I have no idea if this makes it more semantic. It probably also leads to less javascript code as the article demonstrates.
I won't bother creating a custom DTD. I don't think it is worth it. I know my code is valid.
Thanks for the great article and the great site.Copy & paste the code below to embed this comment.
Kamil "Brego" Dzielinski (article author)
No. Why? Because the meaning of the article was separating js-logic from data. The problem would be solved by adding some extra DTD-based attributes - but it would be re-invented if one would add an event-handler to it.Copy & paste the code below to embed this comment.
Bobby van der Sluis (article author)
Although in this case there are different ways of achieving the same goal, I think Peter gives enough arguments why using classes for JS triggers isn't the most optimal method.
Is his method better? I think so. Besides the fact that it is cleaner, I think it is pretty future oriented. If you look at WHATWG Web Forms 2 specs you will see that a lot of new attributes for 'built-in behavior' are in the pipeline.
By using your own custom attributes, you could already get used to this way of coding, and if you do it well, you could even use JavaScript to move into a more seemless future.
Peter-Paul and David, kudos for these two articles (great tag team), I enjoyed reading them.Copy & paste the code below to embed this comment.
Jonathan Broome (article author)
Great articles, PPK & David.
In favor of custom attributes, I like that while you tweak the DTDs to your favor, it cuts out parsing strings or remembering why the class attribute contains 'fake' info that shouldn't be removed or re-ordered lest my quickly-poorly-coded parser quit working.
Even though it's convenient when a 'required' class in the attribute both colors the field background and triggers js on the element, I run into so many one-off validation requirements (e.g. "this required if that=x") that the class approach gets messy, fast. At least with custom attributes the mess is confined/self-explained.
Two questions:
Do browsers tend to cache the custom DTD info once it's read, or is it requested with each page? Caching makes sense, just wondered if anyone knows for sure.
If it caches, is that per session or do I have to worry about future visitors not getting version 2 of a tweaked DTD unless I rename it?Copy & paste the code below to embed this comment.
ppk (article author)
Jonathan, browsers do not load the DTD at all.
Bobby, you're completely right. Web Forms 2.0 is a powerful argument in favour of custom attributes.Copy & paste the code below to embed this comment.
Pork Chop (article author)
Personally, I think the idea is a good one and don't see how it deviates from web standards. XHTML is an XML language, afterall; and so, in the spirit of XML, go ahead and create your own attributes if they suit your needs. As long as they are supported in your DTD, all standards are essentially being followed, no?
In any case, excellent idea that brings up an issue that it sounds like a lot of developers (including me) have been trying to tackle.Copy & paste the code below to embed this comment.
dru (article author)
This is absolutely ass-kicking awesome. Finally some frigging seperation. W3C can you hear us. These are the kinds of things app developers want.Copy & paste the code below to embed this comment.
sam (article author)
I think the article makes a lot of sense, but I think that it's important to realize that not all javascript is behavioral. There is plenty of useful presentational javascript, such as Image Replacement and TOC Generation (to use two examples from PPK's site).
I think the best practice for implementing PPK's suggestions is to use custom attributes for _behavioral_ javascript triggers, but not for presentational javascript triggers. For example, I think it would be fine to latch a JIR routine, for example, onto a 'class' attribute, because JIR is presentational. (Of course, you might want to keep your JIR routines—and all your presentational javascript—in a separate js file from your behavioral javascript).
Thoughts?Copy & paste the code below to embed this comment.
Jim Ley (article author)
You miss out some important problems, if you add behaviour to your html outside of the HTML, there's a time period where the user can interact with the HTML without the proper behaviour, either they'll trigger the no script fallback - which could be annoying they get a much worse user experience, and you've wasted your time writing the script. Or as is more likely for the majority of readers, they'll get a load of nothing happening.
The delay in behaviour loses one of the key elements of UI that of consistency.
You can of course author your script in such a way that this isn't a problem, however to do that you can't abstract out your scripts, they have to be inline next to the elements and immediately follow the HTML elements they're modifying.
Seperating script and HTML simply isn't practical in todays mark-up languages. Simple onsubmit form validation might cut it, just about, because the user is unlikely to interact with the form enough until after the behaviour has been attached, but the more complicated validation that provides real-time feedback, that'll be down the same problem of "onload='someformelement.focus()'" where most users are well into the field before being viciously snapped back to the first.Copy & paste the code below to embed this comment.
ppk (article author)
Jim, what you're really saying is that the load event is not good enough, since it may fire too late.
I completely agree, but I don't know what to do about it. I assume a solution will be found one day.
Meanwhile we should solve the problems we *can* solve.Copy & paste the code below to embed this comment.
Sean Upton (article author)
Would use of XML namespaces be a more appropriate solution for marking up elements with purpose-specific triggers than forking an XHTML DTD?Copy & paste the code below to embed this comment.
Lach (article author)
Why choose custom attributes & custom DTDs over simply storing the information in a remote XML file, and loading it via XmlHttpRequest?
It seems to me that in the case where a class can't hold necessary information (eg, your textarea length example), it would be simpler to add ids to the elements in question, then load a remote file which ties the id to the data being imparted. Indeed, in more complex cases this could prevent a serious outbreak of attribute-itis in your html.
And if you were going to follow such a path for different scripts, it'd be fairly trivial to develop a small library which could be told the files to load, and return data: value combinations tied to specific ids.Copy & paste the code below to embed this comment.
Justin Perkins (article author)
It's interesting you mention this because I am in the middle of implementing such a feature at my work. I built the server-side validation to utilize an XML file for required field information, error text, regular expression patterns to run against form values, etc…
In this article, PPK is primarily discussing attaching triggers to input controls (like a textarea). While using an XML file for validation is a great idea for error messages, required field and such, it does not help with attaching triggers to controls (to monitor max lenght as text is typed).Copy & paste the code below to embed this comment.
Jim Ley (article author)
Yes the point is that onload is too late, even Google's very simple page, I often run into focussing problems (where I've already entered my search term and have tabbed to a submit button before I get focus'd back onload.
The other parts of the idea, using attributes to encode validation values etc. and how to validate those is very useful techniques. However I don't think we should advocate not having a onsomething="dosomething()" in elements that should have behaviour, there's great arguments for generalising dosomething as much as possible, but because user behaviour is degraded with the onload techniques, we hurt ourselves more than we gain.
One of the problems of this is that it's something that's so rarely picked up by developers or their testers, they tend to have cached pagesm and good local connections - even if they test with a bandwidth limiter on, they rarely test with a simulation of the wifi suddenly disappearing so image number 5 isn't downloaded until much later than normal.
So take the idea of validation of abstracting out values into the markup, but please leave your intrinsic event in the document! Your users will thank you.Copy & paste the code below to embed this comment.
J David Eisenberg (article author)
Dante (article author)
Seems to me that storing all that data in an external file and loading it via XMLHTTP is like going all the way to china just for noodles. You can get them at the grocery store. Don't separate *too* much; as PPK says Keep it Simple. After all, PPK is just extensifying a page. It would be silly to call a language 'eXtensible' without being able to extend it, wouldn'it?Copy & paste the code below to embed this comment.
Davids Schontzler (article author)
I'm a bit surprised only one person mentioned XML namespaces. It's a much more convenient way to add on what you need without have to decloare your own DTD. I'd argue that going the custom DTD route isn't worth the trouble since browsers rely on DTDs to determine what rendering mode to use. I'll warn you that, if I recall correctly, you have to use slightly different scripting to deal with namespaces in the major browsers.
Personally, I'm all for throwing in custom attributes and walking away. Parsers look for well-formedness, not DTD validity (except for in extreme cases). It's easy enough to ignore extra info, just don't break my parser!
Sidenote: It's nice to see a decent JS article on ALA. Cheers.Copy & paste the code below to embed this comment.
David (article author)
enough said
(great article!)Copy & paste the code below to embed this comment.
stylo~ (article author)
>>storing the information in a remote XML file, and loading it via XmlHttpRequest?
Why xml? Far better and lighter and more crossbrowser, just have your classes detailed in your js file that is doing the validation, or a 2nd js data-only file. Then your js is truly separate, not half spilled around various html attributes, and half in js files. On second thought, wouldn't you agree, PPK?
Who said class is only for css? The id attribute isn't only for css, but is used by both js and css. Also, classes do seem best for this to me because most of this info is being reused, thus truly classes (if not use, the id). With custom attributes, you have to change each individual one during upkeep, like old font tags, rather than update your class definition in your js file.
If you really must include data in the class itself, you can use classes like js-classname-data and then pickup all "js-" classes and split them in js. Very easy.
Finally, anyone who uses custom attributes (and maybe best in certain cases anyway) then goes to the trouble of writing a custom dtd to tell a computer at w3c to ignore certain items he already knows to ignore has too much time on his hands and hasn't really thought about what he's doing. -Unless of course he's being paid to do exactly that :-)
Personally, I wouldn't use xhtml either, but that's another article…Copy & paste the code below to embed this comment.
Joel Bernstein (article author)
If you can assume that each element has only one behavior, you could simply define a "scriptclass" attribute which would behave like a class attribute but not be stylable.
The main benefit over the method in the article is that you wouldn't have to update your DTD every time you write a new behavior.
It might even be possible to use a comma-delimited list of behaviors that gets parsed on page load, though you'd have to be sure your function parameters don't intersect with each other, and it wasn't too bad of a performance hit.Copy & paste the code below to embed this comment.
A very appreciative student (article author)
Wow just wanted to comment with how useful ALA and this article have been in helping me develop to standards and create very efficient code. I learned from here much more than tens of credits at WWU.
Thanks!Copy & paste the code below to embed this comment.
Justin Perkins (article author)
In regards to Dante's comment about too much separation being a bad thing…
The thought is that if you're going to perform server-side validation *and* client-side validation, why wouldn't you abstract the validation out of the code for an ease of maintenance standpoint?
My vote is for dependency, but there are those that prefer to be redundant and that is fine. There are pros and cons to each.Copy & paste the code below to embed this comment.
peterned (article author)
It's good to think about proper script triggers without polluting the markup, but I strongly disagree with the class attribute being a presentational attribute. The . and # are merely shortcuts for doing the same thing with the attribute selector. In a way that makes it ironic that IE only supports the shortcuts, and not the generic way.
See also: http://www.rikkertkoppes.com/thoughts/class-and-style
This doesn't mean that I think this is a bad article mind you ;) It's an important concept, and the right way to go. But I do think the examples chosen to show how to use triggers between the different application layers could have been better.Copy & paste the code below to embed this comment.
Martin (article author)
At the start of your article I noticed this particular sentence: "For instance, it should be possible to rewrite the entire presentation layer without touching either the structural or the behavior layer."
CSS reacts upon structural data, some of that data is expanded by id's and classes which are two ways of providing extra information about the structure. For instance a class can explain to the CSS-parser that a couple of groups of structural data are of a similar kind and thus can have similar presentation applied.
A behavioural layer should react upon events in the structure of a document, investigate if it is of a nature that it needs to react and if not become dormant again. All the information that needs to be supplied for writing a behaviour is already in the structure, even in forms.
The structure can tell the behaviour that the key-press occurred in a text-area and what the name of the text-area is, a well-written behaviour could now, easily, determine wether or not the maximum length of the textarea is breached, even if the entire presentation is changed.Copy & paste the code below to embed this comment.
Michael Ward (article author)
If extending XHTML by adding your own attributes, you should be careful that you're not specifying an attribute that is going to popup in a future spec with a different meaning.
Try adding a prefix that is likely to be used in the formal spec (think of Mozilla's -moz- css3 implementations).
Other than that, I feel quite comfortable using the class atribute as a hook.
class="required large" could receive both the correct styling from CSS and behaviour from Ecmascript.Copy & paste the code below to embed this comment.
AkaXakA (article author)
// "I think it is pretty future oriented. If you look at WHATWG Web Forms 2 specs you will see that a lot of new attributes for 'built-in behavior' are in the pipeline." //
No. As Michael already noted, it might be used in futurespecs. What might be worse is that it might be used _in an entirely different_ way.
Also, as others have said classes _are_ to be used for this kind of thing, not to mention that you can reuse them in your CSS. Reusing them will also mean that your CSS and JS will be easier to understand together, as they'll both be using the same names for the variables.
That said, the basic idea of not using "onMouseOver" attributes is a excelent one.Copy & paste the code below to embed this comment.
Nick Fitzsimons (article author)
I've come to the conclusion from experience on several recent projects that using XML namespaces is the cleanest way of using custom attributes in XHTML. After all, that's what namespaces are for - to allow one to mix elements/attributes from various types of document while making it clear which comes from where.
This also takes care of the question of attributes of the same name turning up in a later version of whatever standard - my nf:required="true" attribute won't ever be the same as any other "required" attribute, as they live in different namespaces.
Totally off-topic, does anybody know why there's no "Preview" button on this form?Copy & paste the code below to embed this comment.
Jürgen (article author)
Hello there,
I guess I am dense, but I can't get that to work. Only worked in IE (ugh). Could someone point me to some more real-life examples how it gets implemented?
How should I understand that line here:
y.onmouseover = addBehavior;
I tried
x.style.behavior = 'url(htc/externallink.htc)';
which made it work in IE, I guess.
thanksCopy & paste the code below to embed this comment.
Adrian (article author)
This is a very clean and semantic-rich way of going about things. I love it.
My only complaint is that class="required" is a better way to go—it signifies this input belongs to the group of elements that are required.
However you won me over with the maxlength attribute. Well done.Copy & paste the code below to embed this comment.
TC (article author)
The described approach has its merits however there is an alternative that I believe is more versatile and no more complicated…
Although these comments may strike fear into the hearts of some developers, especially those that aren't familiar with OO concepts and patterns, it really isn't as complicated as it sounds.
<input name="name" class="required" />
textFields[textFields.length] = new TextField("name", true, false, 10);
It should be noted that this approach is extremely versatile and isn't limited to one object per HTML element. Several complimentary HTML elements can be combined together to form a "super" component. The TextField class, for instance, could be given the ID of an associated "img" element that can be set according to the status of the input field. I believe that Tapestry (part of the Apache Jakarta project http://jakarta.apache.org/tapestry/) takes this approach to the framework level.Copy & paste the code below to embed this comment.
Dave Cardwell (article author)
Is the structure layer the appropriate place to stick constraints on user input? For example we could add a 'mask' attribute using the methods described in this article to do something like the following…
<!ATTLIST input mask CDATA #IMPLIED>
<input id="name" mask="^\\w+(\\s\\w+)+$" />
if( obj.getAttribute("mask") ) {
var re = RegExp(obj.getAttribute("mask"));
if( !obj.value.match( re ) ) {
// do something about it
Name isn't a particularly good one to constrain since there are too many different styles of name, but it makes for an easy example.
And how about things like:
<!ATTLIST input confirms IDREF #IMPLIED>
<input id="pass" type="password" />
<input id="pass_conf" type="password" confirms="pass" />
if( obj.getAttribute("confirms") ) {
if( obj.value != document.getElementById(obj.confirms).value ) {
// do something about it
Do these examples belong in the structure or the behaviour?Copy & paste the code below to embed this comment.
Laurian Gridinoc (article author)
By a custom DTD you register an element or attribute in a namespace you don't own, doing it by DTD is more like to validate the page, but the new element/attribute semantics does not belong in the current/default namespace.
I would go for custom CSS declaration for behavior and not for a custom attribute, something like:
#superInput {
foorequired: true;
foomask: regexp;
Or have the behavior in a RDF file, ie. using URIs for element IDs, and a javascript parsing the RDF and applying the rules (ie: see function ui() from http://www.grapefruit.ro/ui/script/grapefruit.js and the RDF http://www.grapefruit.ro/ui.xml).Copy & paste the code below to embed this comment.
Will Rickards (article author)
Interesting point about the load event happening too late. It really is convenient just having to modify the .js file though. Kind of like just having to modify the .css file. But this practical issue may change some of my implementations.
However, inline scripts have another disadvantage, that is that other elements they need to reference might not have been loaded yet at the time they are invoked. This leads to much more defensive coding and probably more code.
For forms, this is why I prefer to validate all the fields again in the onsubmit handler.Copy & paste the code below to embed this comment.
Jim Ley (article author)
Will, onload firing is no guarantee that your elements are there and scriptable - try pressing the stop button as the document is loading - onload still fires.
For me there's no extra defensiveness inline to onload, they're as equally likely to fail.Copy & paste the code below to embed this comment.
Michael Kowalski (article author)
I've been using this kind of technique a lot in the last couple of years and found it very useful for code reuse on web application GUIs. That's a practical benefit rather than a theoretical one.
One thing in favour of CSS class names is that you typically want to give the user a visual cue for whatever behaviour that you're adding to a control. As IE doesn't support attribute selectors, you have to use a class name for this anyway.
I tend to attach a standard prefix (say, "ui-") as a kind of bogus CSS "namespace" to differentiate behavorial class names from purely presentational ones.
Here's an example:
<input type="text" class="ui-date ui-required" id="birthday">
I've built some pretty complex client-side controls like this (collapsible trees, etc, as well as a more or less complete implementation of the new WebForms 2.0 input types).
But I agree that CSS is not such a good approach for adding behaviour like RegExp validation.Copy & paste the code below to embed this comment.
Eric Moritz (article author)
Dean Edwards of IE7 fame, has an awesome javascript function called cssQuery. It allows you to select elements by css selectors.
http://dean.edwards.name/my/Copy & paste the code below to embed this comment.
Joe Theory (article author)
using the first simple div example verbatim the event fires for each element right when the document loads. so that if i have
y.onMouseOver = alert("yo");
and 4 <li> elements as in the example i get 4 alert windows upon loading the page.
after that, mousing over the elements dosnt trigger any action. this is true for both firefox and IE though in IE it only pops up 1 alert.
any thoughts on what im doing wrong? thanksCopy & paste the code below to embed this comment.
sam (article author)
nice link. i was in the middle of trying to write that very thing. i'm glad to find out its (a) been done (b) by a better coder.
combine cssQuery with a js that parses css files and there's some nice potential for extending css via presentantational javascript.
perhaps do JIR, for example, by using a custom "replace" css attribute
replace: url("images/mycoolbutton.png");
cssQuery selects, another script parses the css and does the image replacement. meanwhile the variable presentational elements are tucked away nicely in your css file.Copy & paste the code below to embed this comment.
Eric Moritz (article author)
I thought that we were seperating the behavioural from the structural. Isn't putting a maxwidth="20" in the tag defining the behaviour? If you had to change the behaviour of accepting 30 chars instead of 20, then you would have to modify the structural data. That doesn't seem right to me.
It would be better to refer to that element by it's name or id in javascript. And apply the restriction of 20 chars directory in Javascript. Then if you need to modify the behaviour you can leave the xhtml allow and only modify the javascript.Copy & paste the code below to embed this comment.
Michael Havard (article author)
I don't know, to me maxlength defines the structure of the input first (how many characters can be held) and the behavior second (what happens if it goes beyond x characters) and lastly visual style (how does it display when rendered). Much like how the type attribute defines what the control will be (text/radio/checkbox).
There are plenty of such properties that skirt the line of providing some aspect of structure, behavior, and visual styling. Those properties could be considered convenience properties in that they help impliment all the levels without needing to invoke some other language (js, css). This allows for the document to mean something to user agents that don't have the ability to use / or poorly impliment those other languages.Copy & paste the code below to embed this comment.
dave (article author)
BeCSS is an interesting, related technology that stalled awhile ago:
http://www.w3.org/TR/1999/WD-becss-19990804Copy & paste the code below to embed this comment.
Dante (article author)
The replace property has been added in CSS3 under the name of the icon property. For example:
h1 {
display: icon;
icon: url(image.gif);
is the CSS3 way to do Image Replacement. No browser supports it yet, though.Copy & paste the code below to embed this comment.
Paul Roe (article author)
Great article, and I have been using this technique ever since I read the article on "usable forms" on your web page. Thank you Mr. Koch for all of your contributions.Copy & paste the code below to embed this comment.
Ash Searle (article author)
function readSpec(classs) {
var f = function (a) {
return a.match(/=/) ? a.replace(/=(.*)/, ":'$1'") : a + ":true";
var o;
return eval("o={" + classs.replace(/\S+/g, f).match(/\S+/g) + "}");
This turns the class attribute into an object, allowing you to write more easily maintained code such as:
var spec = readSpec(inputField.className);
if (spec.required) {
// check non-empty…
if (spec.minlength > 0) {
// validate input data…
if (spec.phone) {
// phone number validation
} else if (spec.email) {
// email validation
} ...etc…Copy & paste the code below to embed this comment.
DEfusion (article author)
Your content layer is now dependent on your behaviour layer. Say you want to scrap all your behaviour - instead of just removing the behaviour scripts you now have all this junk laying around whose only purpose is to support the old behaviour layer.
I created a reusable validation script, which seems to be a regular example of usage of this method in this discussion, and all it relies on is field IDs. The information on how each should be validated is related to the behaviour layer only - so there is an external XML config file which the validation script uses in combination with IDs.
I've never found it a problem to use IDs and classes for behaviour layer hooks/triggers, as far as I see them they are not exclusivly the domain of CSS, they're just their to identify unique elements or groups of related elements - thats it.
I see adding a custom attribute required="true" to be the same as applying a color="red" attribute - it just doesn't belong in the content. The content shouldn't know or care about behaviour or styling.
-DCopy & paste the code below to embed this comment.
Austin (article author)
This is an interesting debate.
Is maxlength="30" behaviour or structure? I think we can probably agree its not presentation.
If its behaviour, then it should not be an attribute of the element, it should be in a .js somewhere or perhaps in an external .xml
I dont like the class method much but can see the argument for using it, take the example of classing elements that are required. ie. class="required". Its a valid class. Taking that further then I suppose it is valid to clasify or group all content with a maximum length of 30, ie. class="maxlength=30", but I do think the class method does get a bit messy.
I started out having read the article and having used the technique before, agreeing with the author, but after reading all the comments I find myself agreeing with both all three view and unsure if there is a right way or a wrong way.Copy & paste the code below to embed this comment.
R Cotton (article author)
The article includes a few problems to my mind, which have been touched on, but not properly followed through.
The concept of seperating behaviour and presentation from structure is slightly incorrect thinking from the very begining: they re NOT seperate, they are DRIVEN BY and hence coupled to the structure. (even in CSS the presentation of elements is constrained by their order in the structural document. i.e. no "float: top;", the structure constrains vertical positioning)
Second; the "id" and "class" attributes ARE NOT presentational triggers. They are unique and group identifiers, which are used by CSS to drive its specific rules, and which ca be used by javascript (or other things), to drive their activities. This is why we try to use classes like "product_description" rather than "justify center-block red bold larger".
Also remember that you write the structure document supplying semantically meaningful hooks on which to hang your other (presentation or behaviour) code. We should be using class to define as much semantic meaning as possible in a structure document; if you have a paragraph that has product description in it; set the class to "product_description"—it is a seperate question whether there are any special style rules in CSS that you are actually going to set for that paragraph; its STILL got the product description in it! (this way you have MORE chance of writing a new pres. layer without touching the structure - CSS Zen Garden is a demonsration of this principle in effect)
You are NOT required to only use class values in your structure that your CSS has rules for! Therefore you are at liberty to use some class values for behaviour hooks; they just get dealt with by the JS, not by CSS.
Finally, and fairly obviously to anyone who can actually program code, the parsing script shown is INFANTILE in the extreme. It should therefore be discounted as an argument for not parsing the class attribute.Copy & paste the code below to embed this comment.
ppk (article author)
"Your content layer is now dependent on your behaviour layer."
"Say you want to scrap all your behaviour - instead of just removing the behaviour scripts you now have all this junk laying around whose only purpose is to support the old behaviour layer."
Possibly, but not necessarily. Just as you could scrap the style sheet but retain the classes and ids as triggers for the new CSS, you could retain the old behavioural triggers but rewrite the script.
If you see this as a drawback of custom attributes, would you also oppose the deletion and insertion of classes and ids when the presentation layer is changed?
"Is maxlength="30" behaviour or structure? I think we can probably agree its not presentation."
Interesting question, and I don't readily have an answer. Is class="mainheader" structure or presentation?Copy & paste the code below to embed this comment.
DEfusion (article author)
"If you see this as a drawback of custom attributes, would you also oppose the deletion and insertion of classes and ids when the
presentation layer is changed?"
No, I agree with what R Cotton said. Classes and IDs can be used as pseudo semantics specifc to your content, whether you are using these hooks for style/behaviour etc. does matter to the structure. Without the style/behaviour layers being there a given 'product' can still have the class 'product' applied - I'm not sure the same goes for custom attributes.
Although I've never looked at it to the extent of adding IDs & classes prior to their requirements for style/behaviour I can see the advantages.
-DCopy & paste the code below to embed this comment.
ppk (article author)
"Classes and IDs can be used as pseudo semantics specifc to your content, whether you are using these hooks for style/behaviour etc. does matter to the structure."
I see what you mean, and for something like "required" you might be right. Personally I don't think that "maxlength=300" belongs in a class, though, so that's where I draw the line.
Feel free to disagree, though. This is uncharted territory, and the more opinions we have the better.Copy & paste the code below to embed this comment.
Larry P (article author)
Although I benefitted from this article's discussion about adding custom attributes, I would caution against using the term "triggers."
Traditionally, in comp sci when we refer to triggers, we are talking about items that trigger the invocation of an event or method, usually in response to an action. Databases use triggers all the time after an insert or an update, for example.
In the context that the author is using them, his "triggers" are search terms, and perform no more triggering than any other identifier.Copy & paste the code below to embed this comment.
ppk (article author)
"Traditionally, in comp sci when we refer to triggers, we are talking about items that trigger the invocation of an event or method, usually in response to an action."
Which, as far as I'm concerned, is a perfect description of what JavaScript usually does.Copy & paste the code below to embed this comment.
DEfusion (article author)
"Personally I don't think that "maxlength=300" belongs in a class, though, so that's where I draw the line."
I agree, I don't think it belongs in a class, and in this instance it could be argued that it would be an example to extend the DTD. However I personally would much rather have this behaviour config in something that's related to the behaviour - be it a xml or js config file.
The structure would have an ID/class associated with the field and the config would have any behaviour requirements associated with the ID/class.Copy & paste the code below to embed this comment.
ppk (article author)
But then the site would lose clarity. You'd end up with interminable arrays like
var maxLengths = new Array(
and that's a construct I'd rather not use. It's ugly and it doesn't allow newbie webmasters to easily change the maxlengths of textareas.
Besides, if the maxlength is the only behaviour associated with a textarea and we use a maxlength attribute, we don't need an id at all.Copy & paste the code below to embed this comment.
Rikkert Koppes (article author)
You state that classes should only be used for CSS, this is not true.
Classes are an extension to the element's name. More like subgroups of elements.
However, I agree with the use of custom attributes in some cases.
I've written something on classes once: http://www.rikkertkoppes.com/thoughts/class-and-style
point is, there is no specific attribute that is intended as a trigger for CSS, nor should there be for JS triggers. attributes should only be added if there is no other attribute that could indicate it's meaning (adding rel="external" for external links and applying some JS on that category is perfectly fine, no use for an extra attribute).
When defining attributes, keep semantics in mind, just as you would do by adding custom elementsCopy & paste the code below to embed this comment.
a scuba diver (article author)
One more step toward 100% semantic markup and no more behaviours in the XHTML. This article explained it brilliantly.
In CSS you can stack classes upon classes in your tag, so I can apply multiple classes selectively to my elements.
for example: <div class="loud fresh inabox sideways">
Can the same method apply to behaviours?
For instance, can I use external scripts to control the status bar, turn up the volume of my flash movie, and replace an image, all in one go with class names representing each of those behaviours?
<a class="gostat newimg louder">click</a>
While most people put lots IDs and CLASSes in their html, some hard-core coders do not Get their Elements By Id. Instead, these hard-core semanticists iterate through the DOM numerically to apply a behaviour to the third link in the fourth table cell inside the first table inside body. It's only a matter of time before I have my CMS building javascript to apply styles and behaviours to elements without bulking up my code with class definitions.
We don't live in a classless society (yet), but I can build a classless website! (some would argue that most of my sites don't have class to begin with ;)Copy & paste the code below to embed this comment.
R Cotton (article author)
"While most people put lots IDs and CLASSes in their html, some hard-core coders do not Get their Elements By Id. Instead, these hard-core semanticists iterate through the DOM numerically to apply a behaviour to the third link in the fourth table cell inside the first table inside body."
Err, no. Hardcore idiots do that. Add or remove a link, and you have to re-write the whole lot. Going down that route will be a (thankfully lonely) treck backwards for you. Good luck, more good luck to anyone needing to maintain your work!
The class attribute exists to classify an element; literally to note that it belongs to a type, which can have multiple members. The id attribute allows you to assign a unique identifier to an element. CSS allows you to add presentation rules based on these, by selectively taking parts of the article, you can use JS to add dynamic behaviour based on these.
To tackle the maxlength for a textarea example that recurs in this discussion, imagine that you have your textarea; for the sake of comparison with CSS, lets also imagine that you want to give it a red background.
The idea of redefining the DTD to allow a maxlength=300 attribute is directly analogous to redefining it to add a background=#FF0000 attribute; most people now prefer to add either a class or id to the textarea, then use CSS based on the class/id to add the background setting.
So, to follow through; add a class or id to the textarea, id if you feel it should be uniquely identified, class if you expect multiple 300 character limited textareas. Your javascript then adds the behaviour, based on the classification or identity of the element.
Remember that the example was NOT to create a textarea element structurally limited to 300 characters; it was to add the BEHAVIOUR to a structurally bland textarea that refuses characters after the 300th. It is the job of the behaviour-defining code to know the specifics of the bahviour you want; you should be altering the definition of the behaviour should you want to move to a 250 character limit, not every place the behaviour is invoked.
The paradigm in use in XHTML +CSS (+JS with this method) is to classify and identify "special" and meaningful elements in the structure, and then in the supporting source documents to assign extra instructions to them.
Move away from that paradigm, and it seems the natural inclination is to revert to specific instructions for presentation or behaviour in the structure document. Some seem less inclined to notice the reversion than others?Copy & paste the code below to embed this comment.
R Cotton (article author)
"Is maxlength="30" behaviour or structure?"
IF the structural element supported having its length limited, it _could_ be structural; example an element for input of data that MUST be limited to 30 characters by its nature. Without that support, and specifically if you are using it to drive addition of behaviour, it is behavioural. (and therefore does not belong in the structure document)
I'm going to add a third example of my own, but in the middle;
Is align=justify presentation or structure?
Hopefully its pretty obvious that this is presentation, and does not belong in the structure document. This is why it has been deprecated over time.
"Is class="mainheader" structure or presentation?"
This is structural, and the right way to go about things. Replace "mainheader" with something else appropriate for a textarea, and it becomes reasonable to look at attaching both justified presentation and character limit behaviour to that element. Or nothing; because the classification is structural. It is because the classification is structural that we are safe to assign behaviour or presentation on its basis…Copy & paste the code below to embed this comment.
Jim Ley (article author)
A Scuba Diver
"While most people put lots IDs and CLASSes in their html, some hard-core coders do not Get their Elements By Id. Instead, these hard-core semanticists iterate through the DOM numerically to apply a behaviour to the third link in the fourth table cell inside the first table inside body"
Please, please don't do this! It's a very bad idea, R Cotton has already talked about the maintenance problem, but there is another more serious one - Accessibility Aids, often have to modify the DOM of a document so it renders effectively for their users - perhaps adding links for them to get more info next to each image, or some extra elements to add DHTML too, or removing some elements to simplify the document.
If you use gEBI type approaches, (or indeed JS triggers) then this is generally perfectly safe for them to do. However assuming the DOM on the users machine is identical to the DOM on the developers machine is simply not a pragmatic choice.Copy & paste the code below to embed this comment.
sam (article author)
"assuming the DOM on the users machine is identical to the DOM on the developers machine is simply not a pragmatic choice."
does that mean you can't use css parent, child selectors?Copy & paste the code below to embed this comment.
Puzzled (article author)
A couple of readers have asked about this line in the first, simple example involving id's, with no response so far: "y.onmouseover = addBehavior;"
I too am confused. PPK, what could you have in mind that both works across browsers and triggers for each mouseover?Copy & paste the code below to embed this comment.
ppk (article author)
I just want to show how you can go about adding event handlers to elements. I have no idea what addBehavior would do, that's something I leave to the fantasy of the reader. For this article it doesn't really matter.Copy & paste the code below to embed this comment.
Jim Ley (article author)
Sam, I wouldn't call them reliable certainly, and I wouldn't use them on anything that relied on the functionality succeeding, e.g. position absolute on one element and then only give the background colour on the first-child, 'cos that could break. but with CSS optional it hopefully should never break your page - remember users who are sprinkling elements throughout other peoples pages are more interested in the functionality they're gaining than what it looks like!Copy & paste the code below to embed this comment.
Boris (article author)
Anyway I don't think handling data validation should be done on clientside, don't you ?Copy & paste the code below to embed this comment.
Sainkho (article author)
Firstly, I'm no expert, I'm no wood nymph, troll or flamer either. I'm always in awe of the articles and discussions hereabouts but how come it took eight pages of chat before Boris stated what I always thought was the bleedin' obvious - validate client-side?
ppk (article author)
"Anyway I don't think handling data validation should be done on clientside, don't you ?"
Why not? As long as you also do it server side there's no problem.
Client side form validation is more user-friendly, while server side form validation is safe. Combine the two and you get a user friendly safe application.Copy & paste the code below to embed this comment.
Svein Atle (article author)
Of course, you should never rely on client-side validation only (or really any data coming from the client), but using it in addition to server-side validation may make your pages more userfriendly/comfortable.
Anyway, I don't think the purpose of the article was to show how to do client-side validation, but to discuss ways to seperate structure and behaviour.Copy & paste the code below to embed this comment.
Svein Atle (article author)
... and now I look like I'm just rephrasing your post ppk :/Copy & paste the code below to embed this comment.
Sainkho (article author)
Granted this article is about adding general functionality (with the chosen illustration of validation) but what if client-side scripting isn't available? Do those users lose out, with validation or whatever whizz bang is being offered by the technique?Copy & paste the code below to embed this comment.
ppk (article author)
What if client side doesn't work? We leave it to the server side script.
And… (now for the requested whizz bang) ...
The server side script can use *the same custom attributes* to determine which field should be checked for what!Copy & paste the code below to embed this comment.
DEfusion (article author)
"...but what if client-side scripting isn't available? Do those users lose out…"
No, that's the whole point of seperation of behaviour from structure. In the same way that users can still see the content if they have stylesheets disabled when style is seperated from the content, they should also be able to access & use the content without the behaviour applied.Copy & paste the code below to embed this comment.
DEfusion (article author)
"The server side script can use *the same custom attributes* to determine which field should be checked for what!"
This could also be said if you were using XML to determine which field should be checked for what.Copy & paste the code below to embed this comment.
Boris (article author)
"Why not? As long as you also do it server side there's no problem."
Sure, but what a peanuts work… I mean you work twice for nothing (I don't say user friendly is nothing).
It would be fun to try an httpRequest on form content when changed or submited in the way Google suggest works.Copy & paste the code below to embed this comment.
Larry P (article author)
Not to get into a debate on semantics, and perhaps I do not fully understand how the author is presenting "triggers", but according to the article, the given example for an id "trigger" is:
var x = document.getElementById('navigation');
if (!x) return;
var x is first assigned to, then x in the boolean evaluation is being used as a flag, and we are taking action based on whether that flag is null. This is a typical branch: why would this be called a "trigger"?
Every imperative language has this facility, it is not particular to JavaScript nor event-driven programming in general, and branching and taking action based on a condition is one of the fundamental ideas of programming.
How are these "triggers"? ppk, what am I missing?Copy & paste the code below to embed this comment.
R Cotton (article author)
The "triggers" refers to the method of embedding information in the document that tells the javascript where to attach its event handlers.
Its a misnomer if you are an actual Programmer; they are in fact what we might refer to as "hooks"; the "trigger" would be the event that causes the javascript function to be called (which we would refer to ass the event firing the trigger…)
I think its one of those situations you get where Design and Programming clash, and group 1 uses a term that group 2 has assigned a specific meaning to, not realising that group 2 will misinterpret based on their specific subject domain meaning. You'd probably see the same thing in reverse if I started refering to the bottom of anything in general as a baseline :)
I do fail to see why the server side validation would be parsing the xhtml document served to the client side to get its instructions for validation. Far more likely is that it would use the instructions it used to BUILD that xhtml document in the first place!
(you know, from where it knew which classes or invented attributes to add to the xhtml elements…)Copy & paste the code below to embed this comment.
Dante (article author)
How can anyone think 'class="maxlength=300"' is even close to being semantically correct?
What you could do if you don't want the bother of the DTD is do something like
Before the textarea, then use this:
var el = document.getElementById("textareaId").previousSibling;
var maxlength = el.nodeValue.susbtr(el.indexOf('=')+1);
Which is easier? You decide.Copy & paste the code below to embed this comment.
Patrick Gotthardt (article author)
First of all: Nice article.
So, now the critics: Neighter "class" nor "custom attributes" is the easiest way to do this.
An much easier way would be, to put it into your JS-Code. Here is how I would do it:
var validator = new FormValidator("id_of_the_form", FormValidatorOptions.VALIDATE_ON_SUBMIT);
validator.addRule("id_of_textarea", ".{0, 30}");
validator.addRule("id_of_required_textfield", ".+");
// that "addRule"-method might take a ValidatorRule-obejct or something similiar instead of the two strings, but it should be clear what I mean.
Isn't that a lot simpler and cleaner? As a plus this javascript could modify the view of the elements to a proper one (e.g. change the class to one showing the result being not valid it if it isn't valid yet).
Someone mentioned MVC previously… I would more like to say it this way:
XHTML is the model. It get's modified and contains the data. It can't be anything else.
CSS is the view. Nothing else, just the view.
ECMAScript is the controller. It is able to modify the data (XHTML) and the view (CSS).
So, having that said, does a modell know what kind of data it is supposed to contain? I don't think so. It just trusts on the controller that prevents bad content from being inserted.
(That's just a note on why I think that my way is correct)
Anyway, I'm not a professional designer or something like that, so I might have just said stupid things. Sorry if I did so.Copy & paste the code below to embed this comment.
R Cotton (article author)
"So, having that said, does a modell know what kind of data it is supposed to contain? I don't think so. It just trusts on the controller that prevents bad content from being inserted.
(That's just a note on why I think that my way is correct)"
This is wrong in the case of XML.
If we were talking about an unstructured text document or a simple array, you would be right; it would not know what was in it.
But XML (and its sibling XHTML) have a TON of information in them about what the data is.
Consider this fragment:
<h3>This is a heading</h3>
The DATA in that fragment is "This is a heading", the "<h3></h3>" pairing is information that describes what kind of data that is; its a heading. Because the xhtml has as its job to hold the data and the typing/structure information to go with it, it most certainly DOES have as its job holding the data, and knowing what the data is.
JS is best restricted to adding "atomic" behaviours to elements; optional behaviours without which your page still works.
The XHTML (and possibly whatever generates it) is the "boss" of the website; without that element you get NOTHING on screen at the client end. Every other element must be treated as an optional add-on; the page mus still WORK without them. This includes CSS, JS, Flash (spit), ActiveX (vomit) and even images…
(so don't think of the JS as the controller of the xhtml, that is BADNESS)Copy & paste the code below to embed this comment.
Patrick Gotthardt (article author)
Thanks for your reply.
So, looking at your sample with headings, I would like to explain a bit of my point of view.
You're saying, that a h3 is a heading, this is true. It also specifies what has to be in it, but does it prevent you from adding _wrong_ data? It doesn't. You can put a hole paragraph within a heading and XHTML won't tell you that this is wrong (ok, it does from a logical point, but not from a practical).
So, this is valid XHTML:
<h1>My very long, very stupid paragraph used as whatever it might be used. It might also be styled as a paragraph, but that really doesn't matter, doesn't it?</h1>
However, it is sementically wrong. But XHTML doesn't stop you doing this. And that is, what I meant.
Another point to consider: form-elements aren't the same as other XHTML elements. They allow direct user input.
Also it seems as if you have misunderstood my sample. The code I've shown won't create XHTML or something like that. It would add EventListeners to the structure and might change view properties. Thus I'm perfectly separating structure from behaviour.
I'm just _modifying_ the structure with it, letting a functional version of it for those without JS.
As an example: I've created a rich text editor for a CMS I've been working on. However, it only appears if the browser is able to work with it. The others get a textarea. So, I'm absolutly familiar with this thing. ;)Copy & paste the code below to embed this comment.
R Cotton (article author)
"<h1>My very long, very stupid paragraph used as whatever it might be used. It might also be styled as a paragraph, but that really doesn't matter, doesn't it?</h1>"
But that is STILL a heading; the fact you've re-styled it to LOOK like a paragraph, and that you personally have decided the length makes it a "paragraph" in your mind, does not change the fact that it is IN FACT a heading…
Recall, again, CSS may not be in effect, in which case it will render as a HEADING because the xhtml DOES carry structure information!
And in the absence of anything better, that structure information will be used as presentation instructions; which means you must not go around redefining it on a whim!Copy & paste the code below to embed this comment.
R Cotton (article author)
Patrick, I seriously think you are confusing "what xml/xhtml supports/does" with "what a buggy/non-strict parser (browser) will let you get away with"
You should form you mental abstractions of how things work based on the former, not the latter.Copy & paste the code below to embed this comment.
Sebastian Redl (article author)
Nice article.
First, Patrick Gotthard, you are making a simple mistake here. You are saying that XHTML doesn't enforce the semantics of its content, even though it defines it. This is absolutely correct. You said:
> So, having that said, does a modell know what
> kind of data it is supposed to contain? I
> don't think so. It just trusts on the
> controller that prevents bad content from
> being inserted.
Well, in the case of XML dialects, it has already been shown that the model indeed knows what content it is supposed to contain. But, lacking the active capabilities, it cannot enforce this and must rely on the controller to enforce it.
Given this view, it makes perfect sense to put a validate="..." attribute into the XHTML and read it out with JavaScript.
Of course, in an ideal world we'd all be using XHTML 2.0 by now, where the Schema explicitely allows foreign attributes. Then we could just define them in a different namespace (if you're using any version of XHTML, you should do that anyway) and not mess with custom DTDs, which, among other things, mess up the validator's automatic charset detection.
That said, there are some things in the article I disagree with. Mainly the thing about the class attribute:
> However, the class attribute's proper use is
> defining CSS triggers.
This is incorrect. The HTML standard says about class:
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.
This "general purpose" processing very well includes behavioural hooks.
But I do agree that class is not the right thing for everything. class="required" is all right (and you might want to style required elements differently anyway). class="maxlength:300" is not. class sorts elements into groups. That's all it should do.
One more thing about events. I've developed a fairly complete group of functions that can be used to bind stuff to events. It supports the EventHandler functionality even for IE, meaning that you can bind an object that implements handleEvent (or whatever it's called) to an event instead of a function. This has big advantages if you want to carry information.
I'll post it soon on my website.Copy & paste the code below to embed this comment.
Patrick Gotthardt (article author)
... all websites I made so far are valid XHTML 1.1 (no, thanks to IE I'm not sending the right content-type - lukily it is still only a "should be"- and not a "must be"-thing…).
So, I'm familiar with webdesign. It's not required (or of any use) to explain the use of XHTML/CSS to me. Of course my work cannot be compared to what you guys do, but I'm pretty sure that I know what I'm doing. You won't see me using any not required element or anything not standard.
> Given this view, it makes perfect sense to put a validate="..." attribute into the XHTML and read it out with JavaScript.
If this would be possible - yes. But it isn't (you said it will be when XHTML 2.0 is supported? Sounds good - it's sad that this won't be supported for a long time… at least from IE).
If you roll up with your own dialect of XHTML you're not using a standard (and this is the case when you create your own DTD). So, the result isn't a valid XHTML-page. Using what I suggested, the page would be absolutly valid XHTML and could contain this kind of additional functionality.
If you take a look at what this article is about ("triggers" - or I would like to name them "Jump-In points" - for Javascripts) and then think about the solution the article has (create your own DTD and put a lot of your own self-made attributes in your side), then take also a look at where this would end.
My suggestion: There would be people create an attribute for everything where they could need it.
Just take a look at his first sample (the menu). Where would we end when we define an attribute for how the items are supposed to _behave_?
We would end up with the same thing you've had (no, I haven't had this time - I started somewhere in 2002 with webdesign - and I'm happy about this) some years ago, using something that could be rendered on some ways by some browsers, but that wasn't a standard.
This time you add an attribute for form-validation, the next time you add an element for something!
What I want to say is quite simple, but maybe my english is so bad, that you're misunderstanding me…
I will try to repeat it:
Keep behaviour in the behaviour-part and don't put instructions on how something is supposed to _behave_ in the structure. From my point of view, the "class"- and "id"-attributes are structural as well. They help to identify the content of their elements (if they have good names). So, a link with a class "external" will not have that class because of instructions for the view, but for the structure.
But things like form-validation / input-control (do you see that "control"? ;) ) are not part of the structure.
And that is, what I wanted to say. Nothing else.
An attribute "validate" is (just looking at the word) an instruction. Instructions are not part of a structure, or am I wrong when thinking that a structure itself is static? What does a "mask" say about an element?
So, just to say it again, from my point of view an input-validation is part of the behaviour as instructions for it are. Therefor there is no need to put it into the structure.
And creating a custom DTD when it is not required isn't worth this.Copy & paste the code below to embed this comment.
None of your Business (article author)
Well, if every Web designer now makes his own "standard" (that means: your own attributes in your own DTD) we are back again in 1996. With the small difference, that today not two browser manufacturers are writing the rules, but thousands of designers.
If you use custom attributes there is no need for a Document Type Declaration or Document Type Definition in today's Web at all. Because you are not following existing standards (like HTML 4.01 or XHTML 1.0), there is not much need for validating to see if you follow those rules.
Of course you might use custom DTDs in XML, but that is nothing that should be served in public on the Web. It might be fine on some XML applications on your intranet. When you want to publish on the Web, you have to follow standards like HTML 4.01, ISO-HTML, or XHTML 1.0. Otherwise we get a mess.Copy & paste the code below to embed this comment.
None of your Business (article author)
Well, if every Web designer now makes his own "standard" (that means: your own attributes in your own DTD) we are back again in 1996. With the small difference, that today not two browser manufacturers are writing the rules, but thousands of designers.
If you use custom attributes there is no need for a Document Type Declaration or Document Type Definition in today's Web at all. Because you are not following existing standards (like HTML 4.01 or XHTML 1.0), there is not much need for validating to see if you follow those rules.
Of course you might use custom DTDs in XML, but that is nothing that should be served in public on the Web. It might be fine on some XML applications on your intranet. When you want to publish on the Web, you have to follow standards like HTML 4.01, ISO-HTML, or XHTML 1.0. Otherwise we get a mess.Copy & paste the code below to embed this comment.
Average Non-Programmer Idiot (article author)
It seems absolutely snobbish to me to refer to people as idiots and not "real" programmers because of such minor things as people have pointed out. I happen to spend the majority of my time developing using HTML, CSS, and ECMAScript alongside other developers who program in primarily in JAVA. I constantly hear this pettiness about how I'm not a "real" programmer (even though I do program in C++ and JAVA). Some people seem to think that if you don't speak in the market speak given to you by some certification or didn't graduate with a CS degree that you are somehow less worthy of producing content then some others in the field.
If there's an inconsistency in a term, something a laymen might interpret as the author expected but an "expert" would misinterpret, then do point it out. Or if there's an inaccuracy in the coding or a more efficient way, then do point those out also. It would be great though if the statements came with a little less of a judgemental tone and just a little less bickering happened. Treating each other like idiots isn't going to produce better sites or hone anyone's skills.Copy & paste the code below to embed this comment.
Tino Zijdel (article author)
>... all websites I made so far are valid XHTML >1.1 (no, thanks to IE I'm not sending the right >content-type - lukily it is still only a >"should be"- and not a "must be"-thing…).
Yes, that goes for XHTML 1.0 (but even than it is considered 'harmfull'), but NOT for XHTML 1.1. You MUST sent XHTML 1.1 as application/xhtml+xml.
But maybe you should consider why using XHTML at all instead of HTML.Copy & paste the code below to embed this comment.
Michael Havard (article author)
I've been doing development on an internal web application for about 6 years. As the app has grown and we've added more forms and a wider variety of controls some of the inconsistencies in the standards have caused issues. For instance something that matches the article: Text inputs have a maxlength while text areas do not. Until recently each page with a text area had a custom script to handle validation of the length. The initial scripts validated length after pressing submit and later scripts tied to the keypress event for a more user friendly cutoff notice. However that's all wasteful coding and would all be solved by just having a maxlength attribute on the textarea element.
Add the ability to created your own custom attributes and a DTD to tell other agents about that attribute, mix in a little script, and you have a nice easily reusable component. No longer do the designers have to script a special validation for some textarea by ID or CLASS. Simply loop through the textareas on the page, attach the generic keypress handler and use the maxlength to decide the cutoff point for entry.
This is all part of how the standards are supposed to work. Custom elements/attributes are the goal of XML and XHTML. It allows for the developer to create a page that might be used one way internally and yet still be readable/usable by someone on the outside.
We have a redundancy approach to validation. Part of the reason why we do this is to provide the client with friendly interfaces and quicker response times when a validation error occurs. The other reason we do this is because we work within a web service model. Our server side code services more than just our one web client and so we cannot count on those other agents having built in client side validation. We must do validation on both sides.
One additional factor that people may run into is an inconsistency in the way that "valid" data should display on the client vs. the way that it needs to be sent to a back end. (i.e. on the client it validates and displays as (405) 555-5881, the backend legacy system only allows 4055555881). Or as with dates, users might expect to see and enter 2/5/2005 or 2005/05/02 whereas the back end only allows 2005-02-05 12:00:00Z.
It's not always in the best interest of the user to do a round trip for relatively simple validations. The majority of validations can be done on the client side quite easily. Using this article as ONE example can make it even easier.
Assume that you have all of your validation routines separated out. You create a generic function that loops through the elements on a form when the submit button is pressed. The function checks each elements class for cues on how to validate the field and runs the validation displaying error messages at the end of the validation. The cues would be simple i.e. class="required date", class="optional string", or class="required currency". The notation allows for the script to easily identify between fields that must have data over those where an entry can be validated but can also be empty. It also allows for visual cues to be set via CSS so that the user can easily identify what's required or not or allow the designer to align fields based on data type.
You can use the concept with Cocoon, STRUTS, XML/XSLT creating XHTML or PHP or JSP or whatever. It's not only a this way or that solution.
It's all very simple loops and switch/case statements, very simple class identifiers, relatively no learning curve when used within a team setting. Plus you can create very robust functionality that's extremely easy to maintain and extend.
E_X_tensibility is the key in all this. We want to keep the content accessible, beautiful, functional, AND be able to add on "perks" like validation, custom controls, or other nice-to-haves, AND be ready for whatever the future holds.
Stuffing all these properties into some javascript object or reading them out of an XML file via script could end up being very complicated. Lets say that I have a notes section that is reusable and dynamically inserted on many different pages. I would need to assign scripted properties either to the notes body (thus cluttering the structure with JS content) or add it to each parent page via include, js file, or just duplicating code. When you have one such page it may not be much of an issue. Imagine though if most of your site is made up of small reusable components and content that is dynamically included based on user, referrer, or some other criteria. It becomes very messy.
This is one of the things that many frameworks are available for and attempt to eliminate. Unfortunately it's usually either at the cost of functionality or at the cost of a high learning curve to use the framework.Copy & paste the code below to embed this comment.
Aaron Whyte (article author)
Whether you use the class attribute, or some otherCopy & paste the code below to embed this comment.
Aaron Whyte (article author)
You can encode any number of parameters in an attribute and get them out again without having to write tricky parsing code.
In the example below, "someattrib" could be "class" or some custom attribute you made up using a custom DTD.
<textarea someattrib="params={maxLength:10, required:true, customMouseoverText:'hello', listOfStuff=['foo', 27, 'lala']}">
JavaScript can get all the values out using the dangerously powerful 'eval()' method:
var element = ...; // DOM element
var params = {}; // empty object by default
if (element.someattrib && element.someattrib.substring(0, 6) == 'params'))
// Now "params" is a JavaScript object
// containing zero or more custom values.
if (params.maxLength != null && params.maxLength > 0)
There are many other ways to use/abuse eval(). For security reasons, never eval() user-entered data.Copy & paste the code below to embed this comment.
Patrick Gotthardt (article author)
> Yes, that goes for XHTML 1.0 (but even than it is considered 'harmfull'), but NOT for XHTML 1.1. You MUST sent XHTML 1.1 as application/xhtml+xml.
So it's my fault while translating "should not"?
English is not my native language, but "should" shouldn't be the same as "must", or am I mistaken? "Should" should be a suggestion on how something is supposed to be, but it's still optional - it must not be that way. As far as I understand it.
A nice article about this: http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html
> But maybe you should consider why using XHTML at all instead of HTML.
Because of better (more specific) rules and because I will went pretty soon to XHTML 2.0 when it's wildy adopted by clients.
Another point: I've never used HTML, why should I start with it now? That would be the same as if I would start programming in assembly instead of Java.
However, I don't think this should be part of this discussion, hm?Copy & paste the code below to embed this comment.
Patrick Gotthardt (article author)
I've written down a quik sample of what I meant, as I'm still not sure that I've been understood…
It should be enhanced, but it should also be enaugh for a small demo.
It's fully standard compatible (the XHTML - I didn't care much about the javascript) and includes the desired functionality (or at least it covers a part of it, it could do more if I had spended more time on creating it).
And all of that without the need of creating my own DTD.
(Note: I've tested it only with Firefox, so I don't know if it works in other browsers as well…)Copy & paste the code below to embed this comment.
Markos Charatzas (article author)
Hello all!
First of all congrats to everyone involved in alistapart.com, excellent site!
Second kudos to ppk for his magnificent article! It really got me thinking on a lovely Sunday afternoon.
Id like to say that although Im a proficient Java developer, I got carried away by your conversation here.
Ive only fiddled around with .css and .js but Im really jealous of all web designers and the awesome work they produce and that is why I was so excited to get my hands dirty with what you have here.
However, I have to admit that although I had my solution ready straight after I read all 11 pages' posts, I struggled to put it in practise since my experience in .js is limited! (took me over half an hour to get my head around .js' OO implementation!)
Into the problem!
*"How do we add good JavaScript triggers that allow us to pass both a general alert ("deploy behavior here") and an element-specific value to the script?"
Well to answer to this I would say that we dont! Any attempt will result in an non-standard implementation. Not that it terribly wrong!, just not an orthodox one Im afraid.
I agree that class and id should only act as "hooks" (well put!) to presentation and behaviour, and not provide a whole lot!
Namespaces on the other hand sound like a great idea (natively supported by xhtml) only that again (as mentioned) it leads to lots of namespaces around being developed by different developers, hence not standardized.
So why play with fire? Afterall Javascript is suppose to handle all our behavioural needs why not use it that way? My idea is based around "components" that you define and match the desired behaviour. Simply add an "id" to an element and "hook" it to the component providing that behaviour. Here is my take on the problem.
I appologise that I havent got a web server to upload the example for a live demo.
Copy & paste the code below to embed this comment.
Markos Charatzas (article author)
Just noticed that the page displays only in greek.
In any case just click the button on the left to save the file!
Sorry about that.Copy & paste the code below to embed this comment.
Michael Kurze (article author)
I very strongly agree with the poster "None of your Business":
Under the hood of supporting web-standards, this technique undermines them completely. You even carmouflage this act by rewriting the validator itself. Essentially tis is like saying: I want to use "li" as child of "body" but XHTML doesn't validate me, so I rewrite the Specs for me.
What to do if future TR's of XHTML/XFORMS introduce a "validate" attribute and your client complains about two alert windows, one by you, one by the compliant browser?
No future release is going to "fix" this for your personal by chance XHTML _looking_ markup once standards are broadly accepted.
Fine, you want to republish all your Markup once future Browsers rely on DTD's for their rendering. They will _hopefully_ want to know if it is XHTML, XML+XSLT+CSS or RDF they are receiving - and in which version.
The class and id attributes are perfect places for this Kind of information:
With "ID", the element says: You can refer to me by this particular identifier, apply styles and behaviors to me, look up my creation date in a database or do anything you can imagine to me alone.
With "CLASS", it says: I am one of these; one of this class of elements which may share styling information or anything. It might even occur that I am one of those strange "maxlength=30" elements which have a maximum length of 30.
This kind of classification is not wrong, but probably going to outdate faster than, say, "mediumsized". Various readers suggested to use a custom XML or JS configuration file for this. I agree, it even can be simple:
validationConstraints = {
name: { maxlength: 30 },
anyRequired: { required: true }
anyMediumsized: {
maxlength: 400,
mayContainTheWordFuck: false
Here I use the any-prefix to specify rules for classes. Of course an XML-Description of these constraints would be even more robust and also usable on the server. But it also would require more work to be done.
How we apply these rules during client interaction is not of interest here (and also not necessarily complicated).Copy & paste the code below to embed this comment.
Michael Havard (article author)
You missed the point again. Defining a custom DTD is allowed and encouraged by the w3 recommendations (standards). You are not going outside of the standards by adding your own custom attributes as long as you define the DTD. It isn't rewriting the validator either. It's letting the validator know how to validate your custom elements/attributes so that they are handled properly. That's a feature of the validator.
Again this is the whole premise behind the X in XML and XHTML. Extensible. You can, are capable, may, have permission to, extend the structure when and where necessary to fit your particular use as long as you provide a definition of your extensions.
Can it be abused? Sure. People could go in and add back in all of the "bad" attributes like align, bgcolor, margin, and the things we hate. That's why we want to encourage best practices as well as standards. Standards can and will be abused (ALWAYS) (i.e. using tables for layout is still available in standards but generally against best practice).
Could newer standards create a conflict? Possibly. But it's simple enough to add in an object sniffer that says if the agent supports validate don't use custom scripting. Or you could write something on the server to handle these issues (via PHP, JSP, etc.) It's not a mountain of a problem.Copy & paste the code below to embed this comment.
Michael Kurze (article author)
To me it seems that you follow standards by their letters, not by their intention. The future-compatibility is one of the things that drive XHTML forward.
Why should I bother about adding a sniffer later when I can avoid the problems now? Perhaps I have something else to do when my customers of the old days come and complain?
Of course XML is extensible, that is no problem, but the mechanism for extension is XML-NS not a copy-paste-dtd.
Browsers are made to understand and interpret (X)HTML and not any XML that you throw at them (though some do so).
A custom DTD or XSD might be appropriate in an intranet environment, of course. But in the web, I try to _keep_ things simple and not to do simple tricks now that lead to problems later.
Let me be a bit extreme now.
In fact, the method we talk about is a hack: Todays Browsers do not require/check for XHTML, so we give them what we like.Copy & paste the code below to embed this comment.
Michael Kurze (article author)
Please excuse my use of capital letters for non-names. My German tongue tricked me again.Copy & paste the code below to embed this comment.
Dante (article author)
Doesn't the BitfluxCMS (http://wiki.bitflux.org/) do something like this (correct me if I'm wrong). It uses XML and XSLT as a template engine. This means you could theoretically do something like <tag required="yes"> and then let the server-side XSLT parse it.Copy & paste the code below to embed this comment.
Michael Havard (article author)
It's not likely that you're going to spend any significant time building a sniffer mostly because anyone using JS already has one built in or has pulled one from another site and secondly because they are so extremely simple to do. That's not going to take any time away from more important aspects of a project. And if you were worried about one of your element/attributes being a problem in the future you'd probably already get a plan in place prior to customers complaining.
An intranet IS the best place for custom solutions like this, but it's not the only place. It's up to the developer to determine what the needs of the consumer are and whether the benefits outway any potential risks.
As far as I know all the major browsers today have support for XML. The current use of XHTML allows for backward compatability and forward extensibility. This means that we can send it as XML/XHTML to apps that understand it and HTML to apps that don't. Either way it would still be valid per the recommendations. One might say that that is a hack but the way I read it it's by design.
It's the difference betwee "should" and "must". "Must" is an absolute - you CANNOT do it any other way. While "should" is not absolute - you CAN do it another way but here's the way we recommend. Too many people read "should" as "must".
Yes there are multiple methods for defining document elements, families of elements, and extension modules. DTD, Namespaces, Schema or XSD. In many cases they can be complimentary (i.e. see XHTML modularization). I'm unsure what you mean about a "cut and paste" DTD. DTD's are just a very simple way to define the document to the user agent. It came out before namespaces and XSD so it's likely to be understood by a wider variety of industry tools and it's easily discarded when no longer in use.
Everyone acts as though this is high maintenance work. If I have 120 XHTML documents sitting on a server and decide to no longer use the DTD or use some attribute does anyone really think I'm going to go into 120 documents and manually strip out each and every occurance. No I'm going to at the very least allow my IDE's find/replace or regex engine do it for me, create an XSLT file for transforming the docs, or strip a couple of lines out of my JSP/PHP code. We're talking a few minutes worth of effort if you've coded thing right from the beginning. Better yet I'm going to have it already coded so that it can be turned on or off from a property file or from a flag from the user agent.
I think all the arguments so far against the technique are trying to make it sound much more complex and much more fragile than it really is. The truth is that the approach while being "experimental" is already in use by plenty of people and doesn't in any way go against the existing standards or even run affoul of any best practices tips I've seen to date.Copy & paste the code below to embed this comment.
david gee (article author)
"What is the point of writing to standards if you are just inventing your own?"
XML : eXtensible Markup Language
XHTML : eXtensible Hypertext Markup Language
Extensibility is part of the standard, Jacob.Copy & paste the code below to embed this comment.
Michael Kurze (article author)
The XHTML 1.0 Recommendation (the standard) says under "A.1." (a normative appendix):
"The W3C recommends that you use the authoritative versions of these DTDs at their defined SYSTEM identifiers when validating content."
True: XML is about extensibility. Yet the intended mechanism for this is "XML Namespaces" which plays unfortunately not well with DTDs (that in turn root in SGML and thus do not yet adhere to our nice extensibility philosophy). One would have to use the XSD
schemes for validation and use namespaces for custom attributes.
If you just replace the doctype you do not extend XHTML but instead replace it with your own vocabulary. No fancy "valid XHTML button" then, and rightfully so. This is Jacobs point, I guess.
To Michael Havard: Of course, in most of the cases anyone uses the custom DTD-technique everything will probably go fine.
But if you have all the changes already prepared that are necessary in case your approach should break in future - why not just apply them now and save the double work?
And honestly - do you already know what exactly these workarounds will be? I am not talking about just some object sniffer, but about the case where future standards introduce your syntax with a different meaning or using different attribute values (which is more probable). Turning off your behaviors to new agents will not suffice, because the behavior of your page is going to differ among user agents.
I see my opinions might be a bit standards-zealous, but hey: This site is a member of "The Web Standards Project" after all.
Of course, on the bottom line I also agree that this method has been marked as being "experimental and controversial". So anyone who reads the article has been warned, hopefully will consider such dangers, and make the best out of this creative approach.Copy & paste the code below to embed this comment.
Eric Fleming (article author)
You can use this code to make sure the user doesn't paste info to get them over the maxlength of the textarea:
First add the following to the textarea wher the onkeypress event is added:
x.onpaste = checkLength;
Then add this to the checkLength function:
this.value = this.value.substring(0, max);
You may also want to check the conditional logic to read as it makes sure the max is the true max sent and not one less:
if(this.value.length >= max){
Just thought I would share what I changed when using the script, thanks for the article!Copy & paste the code below to embed this comment.
fritz (article author)
I have been using custom DTDs the way described in the article for quite some time - even going as far as putting rollover states for images in the HTML like this (not everybody's cup of tea):
<state label="focus" src="pix/focus.gif" >
<state label="on" src="pix/on.gif" >
For completeness, I would add that many people (mostly backend programmers) consider custom DTDs unacceptable, because they make a website too "top-heavy", as it adds another 30/50k to the first page a user visits.
A solution I used in that case is to add a "preparatory" script at the beginning of each page, roughly in this form:
window.onload = function()
document.getElementById( 'x' ).addAttribute( 'aname', 'avalue' );
document.getElementById( 'y' ).addAttribute( 'bname', 'bvalue' );
//... etc
Again, this approach may or may not be to people's taste.Copy & paste the code below to embed this comment.
Marty (article author)
Discussion seems incomplete without including mention of microsoft's css behaviors extension and .htc files. Far simpler interface, and a truer form of "trigger", but admittedly probably not useful for the form validation example in this article.
Lots of good comments though, to which i would add that if your XHMTL is being passed through an XSLT layer, you can output the validator scripts dynamically, before it ever reaches the client.Copy & paste the code below to embed this comment.
Jason Gill (article author)
I guess you could say I'm "trigger happy" now!Copy & paste the code below to embed this comment.
MAREK MÄND (article author)
Peter Paul Koch is not writing here something interesting that has news value.
In fact he keeps rewriting his more than one and half year old writing
Forms, usability, and the W3C DOM : Comments
By Peter-Paul Koch
Published on May 30, 2003
and sells this for newbees as a new article and as seen here very many praise him.
He just has added doubtful paragraph about custom DTDs and thats pretty much it.Copy & paste the code below to embed this comment.
.yosh (article author)
Matching a class name in JavaScript can be tricky, especially if you want to be able to apply more than one class to an element and still not match trick classes (like on the last list item).
In this example we're looking for an expression that matches the first four items in the list.
Note that the last method is the correct approach, the first two are wrong.
<li class="two">Crocodile</li>
<li class="one two">Beaver</li>
<li class="two three">Pig</li>
<li class="one two three">Monkey</li>
<li class="one-two-three">Horse</li>
Following two methods will not work.
if (element.className == "two") {
// Matches first list item only
if (element.className.indexOf("two") != -1) {
// Matches all list items
This one however will.
if (element.className.match(/( |^)(two)( |$)/)) {
// Matches first four list items
}Copy & paste the code below to embed this comment.
R Cotton (article author)
var temp = element.classname.split(" ");
for(i=0; i<temp.length; i++)
// now match with == or use switch/case
// and all is well
}Copy & paste the code below to embed this comment.
Aaron Gustafson (article author)
Inspired by PPK's article, I revised the forms for the Drink-Drive-Lose Ad Challenge: http://www.drink-drive-lose.com/adchallenge/notify.phpCopy & paste the code below to embed this comment.
ppk (article author)
Marek Mänd is not writing here something interesting that has news value.
In fact he has written absolutely nothing that has any value whatsoever.
And sells this for newbees as a viable critique of an article he couldn't have written himself.
He just has established beyond doubt that he's jealous and thats pretty much it.Copy & paste the code below to embed this comment.
Dante (article author)
Oops. I fell for the Capital letter meme.
PPK's method is just one method. We can rule out behaviours because:
1. They don't validate
2. They are browser proprietary
Admitted, PPK's method fails #1 too but it does pass #2. Like it or not I still say that a custom attribute is the most semantically correct way.Copy & paste the code below to embed this comment.
Ben Davies (article author)
As Adrian and Dave pointed out, the ability to use the class attribute for things other than CSS classes is allowed. I'm not sure I follow the idea that this doesn't allow us to keep the seperation between structure, presentation and behaviour, as the class attribute is already used to "bind" presentation to a structural element, why is this very same technique frowned upon for behaviour?
Would Peter-Paul feel that having an attribute labelled "behaviour" with the ability to specificy function/object names better suited? Because this is essentially what the classnames are doing, only for presentation.
The argument that mixing behaviour in with class names doesn't allow for a clean seperation between structure and behaviour doesn't really hold water with me, as this is exactly the same technique that is used to associate presentation with structure.
However, I DO see a need to maybe seperate behaviour assignments from presentation assignments: this will lead to confusion (although were quite fortunate that this wont lead to a problem similar to what namespaces hope to clear up, as a classname could contain a behaviour called "button" and a CSS class called "button")
Anyways, fantastic article: some real food for thought there. Keep it up! I look forward to more articles from this author!
BenCopy & paste the code below to embed this comment.
Sander Maréchal (article author)
First off, great set of articles :-)
In the entire class vs attribute discussion I personally think that it's more logical to use the class. It's just a matter of "abstracting" the behaviour in the same way as we now abstract the presetation through the CSS. To me, writing maxlength="300" is about the same as writing a .red, .blew, .green, etcetera CSS class and applying them at random.
I think that you need to separate the behaviour based on "what it _is_", not on "what it should do", exactly like we define CSS based on "what it is" (i.e. header) and not "what it should look like" (i.e. red, center). The most appropriate solution to me would be to simply have a <textarea class="message"> and then define somewhere else how a messae textbox looks (CSS) and how it should behave (JS).
This means that in my mind, values such as the maxlength should be put in the JS script or in a separate file/definition the JS reads from, and not in the (X)HTML markup.Copy & paste the code below to embed this comment.
A Soul (article author)
I've marvelled at many of the articles at ALA, and I agree it's up to any individual designer to press the limits. My only annnoyance here is that ALA has been a champion of 'standards' yet when I follow the link to the quirksmode site, it doesn't recognise firefox, and so I have to view a java-free version of the site. Not standards friendly - from the start. Then, on the browser page, no mention of firefox? What of these 25 million new users? I have no doubt that quirks' owner is a brilliant programmer/designer etc etc, but this is not doing std comp any favours. Love tips/tricks etc, but in the scheme of things, this article is not much better than an article on some MS proprietory easter eggery - until "standards" catch up. Is ALA now hoping to do what MS did and champion buggy and restrictive, limited access techniques for delivering 'cool' content to those who are dumb enough (in a bug infested world) to enable java everything - for the sake of viewing 'cool' sites. Btw, I not only had to view an ugly "quirks.. site doesn't support your browser" 404 style page, but it didn't even auto-redirect. Not a good look. In ALA's best defence, this is the first article where I feel ALA may have 'jumped the shark'. (jump the shark: episode of Happy Days where Fonzy goes to Florida and daredevil style, ski-jumps over a killer shark - 2 part episode.. ratings fell immediately. Keep it real. This article can only add fuel to the fire that is the argument that: code-freaks will always find a way to break things and in doing so, make arguments for MS to fix us up.Copy & paste the code below to embed this comment.
apartness (article author)
A Soul asked:
>Is ALA now hoping to do what MS did and champion buggy and restrictive, limited access techniques for delivering 'cool' content to those who are dumb enough (in a bug infested world) to enable java everything - for the sake of viewing 'cool' sites.
No.Copy & paste the code below to embed this comment.
John Smart (article author)
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.Copy & paste the code below to embed this comment.
ppk (article author)
>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.
>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?Copy & paste the code below to embed this comment.
Dante (article author)
>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.Copy & paste the code below to embed this comment.
JD (article author)
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.
JDCopy & paste the code below to embed this comment.
Tim Burden (article author)
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.Copy & paste the code below to embed this comment.
Robert Petersen (article author)
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/Copy & paste the code below to embed this comment.
}Tommy J.Sexton (article author)
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.RomnoidCopy & paste the code below to embed this comment.
Delbert Mitten (article author)
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.
Justin (article author)
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 (article author)
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.Copy & paste the code below to embed this comment.
- Sorry, commenting is closed on this article.