"JavaScript triggers" — wrapping it up

My JavaScript triggers article and J. David Eisenberg's accompanying Validating a Custom DTD article, have caused quite a few comments, both on and off the ALA forums. Some of these comments are interesting enough to repeat and to discuss further in a rather long entry.

Objection 1: What about the web standards?

First of all, as several commenters to Shaun's article noted, while a custom DTD violates the XHTML standard (it's not pure XHTML, after all), it does not violate the XML standard, which is what we're all supposed to be moving towards.

Also, there are differences between browser vendors and web developers. When a browser vendor creates a proprietary tag or attribute it will work in one browser only. Contrarily, if we web developers do our work correctly our custom attributes (or rather, the scripts behind them) will work in all modern browsers.

Furthermore, the real problem of proprietary browser extensions was not that they existed but that clueless web developers spread them all over the place, thus making large portions of the Web inaccessible to minority browsers. This is unlikely to happen with custom attributes: the techniques to write the scripts that power them are far above the head of clueless newbies.

Objection 2: You're underestimating class and id

If we use a <input class="required" /> this class allows us to trigger both CSS and JavaScript. CSS gives the form field a distinctive presentation so that the user knows it's required, while the script checks if the user has really entered something. (The same goes for id, of course.)

I agree, but only in the case of "simple triggers" like required. When the trigger also has to send a value to the script this technique loses much of its ease of use.

Objection 3: Creating custom DTDs is too complicated

No DTD

First of all, you can simply use custom attributes without creating a custom DTD. This is what I've done ever since I discovered custom attributes while researching Forms, usability, and the W3C DOM. I'm not saying this is the ideal solution, but it's an option that should be considered along with the others.

Inline DTD extensions

This inline DTD extension is easy to code, the W3C validator accepts it, but a browser bug precludes us from actually using it. All browsers except for Opera print out the last ]> on the screen, because they think the > of the !ATTLIST closes off the entire DOCTYPE tag.

Meanwhile it has been discovered that switching to the application/xml+xhtml MIME type solves the bug in Mozilla and Safari, but that still leaves Explorer out of the equation. Therefore we can't use inline DTD extensions yet.

Validation

A personal concern of mine was that J. David Eisenberg's proposed validation method is a bit on the complicated side. Personally I didn't feel much like installing a separate program just for this task.

Fortunately commenter Milan Negovan pointed out that the WDG validator handles custom DTDs fine. I tested it with David's test file and it turns out to work perfectly. So we don't need to install an extra program, we just have to switch validators. This makes using custom DTDs slightly simpler.

Standardized custom DTDs

The best solution would be to use standardized custom DTDs. These standardized custom DTDs would extend XHTML with a fixed set of custom attributes to trigger a fixed number of behaviours.

The advantage is clear: if a web developer wants to use custom attributes he simply links to the existing standardized custom DTD, and he's ready. He could use a standardized JavaScript library for integrating the standard behaviours into his site, or he could write his own scripts.

Nonetheless, creating such a DTD would force us to decide right now which custom attributes all web developers are going to need in the first few years, and which ones they won't need. I feel that we don't yet have the overview to create a standardized custom DTD that will solve the needs of all sites.

Practical examples

Nonetheless, right now there are already a few practical examples of the use of custom attributes or tags that could grow towards true standardized custom DTDs.

Web Forms 2.0

One program which basically uses a custom DTD is Web Forms 2.0. This specification, now in late Draft and lacking only a few finishing touches, creates a large number of controls for forms, for instance a type="date" to denote form fields that should contain a date, or pattern="[some|regular]*expression" to force compliance of the form field value with a regular expression.

Of course these controls are nothing less than custom attributes. Therefore Web Forms is an excellent example of how standardized custom attributes and DTDs will work, and yes, I feel a bit silly that I didn't at least mention it in my article.

I haven't yet closely studied the specification because I'm waiting for it to stabilise — and besides it'd take quite a bit of time, which I currently don't have. Nonetheless any study of the use of custom attributes will have to take Web Forms into account and use it as an example of the technique.

<embed>

Commenter Michael Powers pointed to another contestant for standardized custom DTD-ing: the <embed> tag. As we all know, it's not a part of XHTML but certain browsers (and that means Netscape 4, for a change) require it. The obvious solution is to create a custom DTD which allows the use of this tag.

Extending custom DTDs

This last example extends the idea of custom attributes in one way, and I'd like to mention a few other possible extensions.

Custom tags

The <embed> example defines not a custom attribute but a custom tag. <embed> itself is not a true custom tag but rather a revived proprietary browser tag. It doesn't need any scripting to do its work. True custom tags, though, tags that never appeared in any true (X)HTML specification or browser extension, would have to be accessible to JavaScript.

And JavaScript access is a problem right now. getAttribute(), which powers all attribute-driven JavaScripts, is supported by all browsers. However, the getElementsByTagName() method currently does not work on custom tags in Explorer 5 Windows and Safari. Therefore custom tags aren't yet fully cross-browser compatible, and we should be careful in using them.

Namespaces

More than one commenter pointed to namespaces as a possible alternative for a custom DTD. Since I don't know enough of namespaces I cannot currently judge the merits of this proposal. I've worked with one application that uses namespaces to define custom tags, but I kind of skirted past the technical details, and I'm not sure how this works and/or should work.

Further information, preferably in the form of a link to an in-depth article targeted at web developers — as opposed to "hard" programmers — would be most welcome.

The server side of things

One other possible extension of custom attributes is to use them as triggers for server side applications, like form validation modules, too. Why would an <input required="true /> — or an <input class="required" />, for that matter — be restricted to triggering client side scripts only? Wouldn't it be possible to write a server side script that parses these documents and uses custom attributes like required to determine which form field should be checked for what? That would make the use of custom attributes even more rewarding.

Wrapping it up

So that's where we stand right now. I feel custom attributes are an important extension of the web developer's bag of tools. I was gratified to see that many commenters and bloggers agreed with me, and that even those who added critical remarks don't seem to opposed to the entire idea in principle.

What's next? I have no idea. I'll continue using custom attributes, I'll search for "the best" way to define custom DTDs, and when that's done I'll have moved one step further towards the integration of the behaviour layer in modern web development.

Comments

1 Posted by Jep Castelein on 6 February 2005 | Permalink

Namespaces and DTDs have a different purpose. Namespaces make it possible to mix different XML vocabularies in a single document. DTDs make it possible to check the validity of an XML document.

I have explained some more details on my blog http://richui.blogspot.com/2005/02/custom-tags-namespaces-and-dtds.html

I hope this article can clarify some things for web developers (as opposed to 'hard' programmers :-)

2 Posted by Jim Ley on 6 February 2005 | Permalink

http://validator.w3.org and http://valet.webthing.com both also support custom DTD's - I've been using them for about 4 years (although generally only to add attributes that are supported but aren't in the specs)

You fail to mention the huge problem with the Web Forms 2.0 stuff - how if you've added the functionality with script, you manage to write your script in a way to know that the browser is handling it itself - there's no reliable way, you're back to sniffing browser strings or inferring from other properties and hoping, so mixing script based addition and browser based addition is problematical.

There's also the problem of their browser based being incompatible with your scripts - invent a required="true|false", and you're stuffed, as in WF2 it just has a required attribute and who knows what a browser might do in that situation, it would be in error to the WF2 DTD, but not to yours - but what browers ever look at the DTD, other than for CSS behaviour changing?

3 Posted by Jep Castelein on 6 February 2005 | Permalink

Jim, wouldn't the 2 problems you mention be solved by using namespaces for custom attributes and tags?

4 Posted by Jim Ley on 6 February 2005 | Permalink

Jep,

It can't solve the "does the browser know" question.

Otherwise the validation becomes a lot more complicated, DTD validation is pretty much thrown away, but it's possible. (Maybe reasonably easy if you have NRL or something to help, then you could use the XHTML DTD and relaxNG for your new stuff seperately) but that's overcomeable.

The Web Forms 2.0 are not using namespaces though, they don't believe they're reliable with legacy user agents (and probably more important on their part that users are too stupid to understand an attribute with a ":" in.)

IE doesn't have a getAttributeNS - you can only do getAttribute("chicken:feed") - which means you have to manage the namespace handling, which is for a lot more complicated script!

5 Posted by Michael Kurze on 6 February 2005 | Permalink

Please read my comment (http://www.alistapart.com/discuss/scripttriggers/11/#c10088) on your original essay.

On Objection 1:
Why are we supposed to move XML forward but not XHTML? Who does define the set of XML-Languages that a browser must support if it is not XHTML?
Why should a clueless newbie not use this technique? To me it seems that the clueless newbie will have no problem to make use of the behaviors we talk about. He just downloads something like WebForms 2.0 for example. He _will_ have problems (that he cannot solve) if the attributes get different meanings in future XHTML Recommendations.

On Objection 3:
"No DTD" - You want to throw away the standard as soon as it is uncomfortable. When future Browsers try to apply their validation-methods based on your custom attribute (with different logic, who knows) they will not even know that your document is meant to be some old XHTML 1.0 and not XHTML 7.0 with nice form validation. Fallback: Impossible.

And "Standardized custom DTDs": I thought webpages were written in (X)HTML. A different doctype means a different language in XML terms. I am a really lazy person and I tend to exaggerate a bit, but I fear that things might become rather complicated in the future when Browsers try to guess if your personal language is rather something like XHTML, myMathML or indeed an SVG image with some custom h1 elements.
Bringing XML forward? Honestly!

I have read very useful and very much information on your site for some time now, but this time I must say that this is probably not the way to do it.

6 Posted by Markos Charatzas on 6 February 2005 | Permalink

Although Ive posted my take on this back in alistapart, I think it might get lost in all 12 pages. So here it is.

http://briefcase.pathfinder.gr/download/cue/32015/380791/0/

The 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.

7 Posted by Jim Ley on 7 February 2005 | Permalink

"A different doctype means a different language in XML terms." - No it just means a different document type definition, that may not be a different language (HTML 4.01 and HTML are different versions of the same language).

The techniques discussed here are firmly routed in the SGML world, not the XML one. Namespaces exist in the XML one, and that is the only thing that will suggest SVG or MathML, no browser is going to sit around guessing. However HTML isn't XML, it doesn't have namespaces. The doctype also doesn't define the processing of an element, it's not the <!DOCTYPE ... line that says how something is to be handled by a browser, neither in theory or practice. It should be used to say if the content is valid, but a custom DTD does the same.

For example, I name the HTML.Version entity in my custom DTD's of for example "+//IDN Jibbering.com//DTD HTML 4.01 Strict + validation//EN" It's clear where's it's come from.

If you want to do this with XHTML there is of course the modularisation - http://www.w3.org/TR/xhtml-modularization which is specifically designed to help you do this with XHTML. The techniques are completely valid from SGML and XML viewpoints. I don't think they're effective ones (because you can't bind the behaviour with the creation of the element - see my previous discussions) but they're certainly legitimate from a standards position.

8 Posted by Michael Kurze on 7 February 2005 | Permalink

Okay Jim, you are right about the method playing well with today's standards (while I got some terms wrong).

I for myslf will not adopt it and settle with classes/ids instead as it seems the most future proof way. Otherwise I have to keep track of every place where I used my custom dtd and recheck it as soon as new browsers or recommendations come out.
Adding a sniffer to turn off my behaviors (based on some object or agent-string) won't be enough: My interpretation of the markup is probably not 100% standard-compliant then.

If this technique becomes widely adopted though, it could impediment web-standards' evolution: Imagine for example MS' websites and their intranet full of custom "validate"-attributes. Will MS promote/implement a standard which breaks its application base (consider their weight in w3c)?

Of course using custom prefixes (or namespaces in XHTML) would prevent this.

Markos, your approach sounds interesting (though possibly too bloated for small stuff). Your webserver does not provide any sensible content-type for your URL, though (sending only some gibberish to me).

9 Posted by Markos Charatzas on 7 February 2005 | Permalink

Finally a step out of the argue and a comment on a different approach! :)

Michael, unfortunately I dont have a site I own and this was one way of sharing the code. :( If you have a better alternative plz let me know.

Well, I agree that it may look really bloated at first, but think of it as a "framework" that is based around the idea of components. It will take you a great time to build it at first but you will save a great amount of time as you re-use it and define new components.

To be honest, I haven't got much experience on web designing. Im really a Java programmer so I might be talking crap! :P

10 Posted by Markos Charatzas on 7 February 2005 | Permalink

Id also like to say that the particular example isnt as great to demonstrate the need to seperate behaviour from structure since all it does is validation which could be taking place in the server-side. (Thus looking bloated)

In general though, I believe that although It looks kinda freaky, it addresses all previous concerns (not arguing that it doesn't create new ones! :P)

11 Posted by Iain on 7 February 2005 | Permalink

I thought both articles on this subject were fascinating and this one adds even more food for thought, but I cannot agree with the notion of "standard custom DTDs". To me that's a contradiction in terms. The standards are what are already there in the W3C's painstakingly formulated XHTML DTDs. It is up to the individual author to decide whether or not to take advantage of the modular nature of XML and to do so as they need to, and all cases will be different. Trying to create a standard of customisation would be an impossibility as an almost infinite number of amendments and ideas would create a baffling mountain of DTDs.

The end result would be the opposite of what was intended: an intimidating mess not easily understood by laymen. I understand what you are saying but I don't think it's a practical solution.

12 Posted by Simon Anderson on 8 February 2005 | Permalink

The X in XHTML stands for eXtensible.

13 Posted by Markos Charatzas on 8 February 2005 | Permalink

eXtensible yes, but you need to have standards for the eXtensions as well! :)

Thats the way I see it anyway...

14 Posted by Iain on 8 February 2005 | Permalink

Simon, if you read what I put at no point do I say you can't extend XHTML (I talk about authors taking advantage of the modular nature of XML), rather I say we should not waste time and effort in trying to standardise personal extensions. It would be an impossible task.

15 Posted by Simon Anderson on 8 February 2005 | Permalink

Sorry Iain, my short entry wasn't specifically directed at your previous comment. I do think, though, that the W3C is heading the way of modularisation and the utilisation of XML capabilities.
They have provided and standardised a framework for the very purpose of having it be used. If a reputable designer like ppk sees a use for that capability, I see no problem with that. The only problem with the technology as it stands is that it is very complicated. Even the List Apart article recommends copying and modifying the entire XHTML DTD instead of making a separate module that only defines the extensions. Is XML Schema going to make this any easier?

16 Posted by Michael Havard on 8 February 2005 | Permalink

Just a minor quible about point 1 above in the misunderstandings section. Browsers aren't the only agent that might parse and consume the provided content (i.e. screen readers, agregators, data mining tools, etc).

A browser may also include a validating parser. Most often the validating parser is only triggered when the content is sent as XML. This means that the validator in question may be included as part of the browser package and thus the browser will, in a sense, read the DTD prior to rendering the content.

Validators may also be found in your IDE software package or may be stand alone components that you call from a url or after uploading a document to a server.

17 Posted by Nelson Menezes on 9 February 2005 | Permalink

Peter,

I like your idea of content/presentation/behaviour layer separation, but I don't think custom attributes are the way. In a sense you're attaching behviour to the HTML: a "maxlength" attribute is defining how the element should behave.

That, and the issues raised about forwards compatibility make me believe custom attributes are not the way to go. (All praise to you for getting the ball rolling though.)

Wouldn't it be better to have a true "behaviour sheet" for your elements (like you do for presentation with CSS)? Here's a half-cooked, not-tested idea:

Create a JS file that defines behaviour for elements like this (treat this as pseudo-code):

var behaviour = array(

[0] => object
{
id = "username"
regexp = "[A-Za-z]*"
}

[1] => object
{
id = "comments"
maxlength = "300"
}
)

You'd put this on a "form_validation.js" file that would get included with a tag. Then, you'd include another file that would parse the array above, like so (pseudocode again):

foreach element in behaviour_array
{
x = document.getElementById(element.id)

// apply behaviour to x
}

This approach would have the bonus that the form_validation.js file could be read server-side too (PHP/whatever) and apply the same validation there.

Whaddchya think?

18 Posted by Pumba on 10 February 2005 | Permalink

Well, I think JavaScript is not a very nice thing in the first place. Although you can do wonderfull effects and solutions with it, it actually limits accessibility and usability. My XHTML+CSS page can be accessed both by PC or mobile unit. When I add scripting (that affects presentation), I need two (or more) versions of my XHTML.
And if you go with scripting anyway, I also don't think custom attributes or DTDs is a good idea.
Saying "doesn't matter it's not XHTML anymore, it's still XML" is a bad excuse. XML defines syntax, but only XHTML defines semantics. And the more you modify the language, the more you lose it. With a modern browser, I could create a page using my own made-up XML language and CSS that would look like an XHTML with the same information. But the first one would not "mean" anything to the browser, only to me.
HTML 4/XHTML was cleaned-up from presentation tags and attributes like ant "bgcolor". Now, you're trying to pollute it again, this time with scripting.
As someone pointed out, attributes in a non-XHTML namespace would be a more elegant solution, as it does not affect the language itself.

19 Posted by Matt Inman on 11 February 2005 | Permalink

I've been using this exact technique for nearly 2 years now; as a graphic designer/web developer for an advertising agency, there is a fairly specific set of presentational functions our clients demand [image rollovers and so forth]. This method is magic for providing additional user candy without filling markup with inline javascript - and I've never had issues with semantics or whatever. I've done the arguing with clients about web standards, semantics and all the crap, but at the end of the day it's their party, so they can cry if they want to.

20 Posted by Laurens Holst on 11 February 2005 | Permalink

Pumba, it is very well possible to create JavaScript to improve the user experience while not harming down-level clients. Take the table sorting script on one of my pages for example:

http://www.grauw.nl/interests/anime/

If your browser doesn’t support JavaScript, the tables won’t be sortable. Big deal :). For the browsers which do however they can nicely and easily sort the tables.

Note that this example doesn’t work in IE (for no particular reason, it is very well possible, I just didn't get around to that yet). Be that as it may be, I guess that clearly demonstrates the impact this JavaScript has on clients which do not support it :).

So, what I’m trying to say: JavaScript, when used properly and with regards to degrading nicely, is not the mother of all evil ^_^.

~Grauw

21 Posted by Laurens Holst on 11 February 2005 | Permalink

Pumba: additionally, putting stuff like onclick="alert(this.getAttribute('class'));" in your HTML, *that* would be polluting your HTML. Adding an attribute such as y:sort or wf2:pattern, there is nothing wrong with that, and it looks very clean. Look at amongst others HTML form controls and you will see several attributes used similarly, and if that weren’t proper I frankly wouldn’t know how else to do such things without making it terribly complex.

22 Posted by John Wong on 11 February 2005 | Permalink

I just want to say that, isn't just fine for people to follow the standards, and then extend it when it doesn't it meet their needs?

I mean, if they just follow the standards, and don't break any of the rules, but "extend" their web site, what's the issue with custom DTD's?

23 Posted by Pumba on 11 February 2005 | Permalink

Laurens> I agree, custom namespace looks elegant enough (but not custom DTDs). "onclick" is the worst choice here, too.
Speaking again about scripting itself, I think so far the standards compliance is too low (mostly because of IE). There are interesting features in DOM Level 3 (which I'm using on the server-side), but no support for them. The cost of adapting code for several PC browsers together with not-affecting-the-content downgrading for other clients is rather high, I think. That's way I'm trying to avoid client-side scripting as much as possible. Maybe XForms and XML Events would improve the situation, but again -- no support...

24 Posted by EpsiloN on 11 February 2005 | Permalink

I just wanted to comment on the "The server Side of Things" paragraph.

The truth is that the server can't rely on data sent by the client, because there are security issues that could be exploited if someone saved the html of a web page,
altered some things with the help of a text-editor (for example: max length in input fields) and submitted the form back to the server.

So the server must ALWAYS perform its own validation in any case and not trust what the client sends.
By replicating some of the server logic in javascript, one can enhance user experience (and possibly save on bandwidth too),
because some things can be caught on the client before any postback occures, but that's where the responsibilities of the client end.

(PS: I apologize for my English in advance, since it's not my native language and I am Greek)

25 Posted by Tumble on 12 February 2005 | Permalink

Has anyone considered creating a new attribute for the select form element that would specify the default selection? We could strip down our template libraries some if we simply used JS to add a default="" value to the select, and then skipped the SELECTED attribute of the option element. This of course might not work well with MULTIPLE, but it could really clean up some template code.

26 Posted by zvpunry on 16 February 2005 | Permalink

I think what's missing is that validation needs to be performed by the server regardless. A common "trick" has been to embed validation requirements into hidden input fields, which refer to editable inputs by name and specify validation requirements. But, as mentioned by epsilon, the server cannot trust what the client sends. (D'oh.)

So what is -really- needed is some server-side configuration of form data, which the SERVER then embeds into the form as it's generated. At this point, the page is -completely- dynamic, so it really doesn't matter one iota whether the validation params are in hidden inputs, or in their own javascript array, or custom HTML attributes (hidden inputs seem more clunky anyway, and just add to the noise sent across the wire on form submit). So forcing the HTML designer to then maintain -two- configurations--one in the HTML, via Javascript triggers using custom attributes, and one in XML/whatever for server triggers, is a recipe for disaster.

One could argue that the input elements themselves could be generated dynamically--for example, by using custom tags in whatever templating language is employed on the server side, which has the added benefit of standardizing on field names across forms. Then, yes, custom HTML attributes could be employed as Javascript triggers. But the attributes themselves are not the source of truth for validation requirements. (Hmm, when I started this reply, I was against the use of custom HTML attributes...but now I think I see how they can be effectively employed, without requiring HTML designers/HTML editors to know all the different attributes.)

As a secondary consideration, what are the implications for every site employing its own DTD? What are the implications for browsers recognizing strict mode versus quirks mode? I don't know, I'm just rambling.

27 Posted by Rick on 17 February 2005 | Permalink

I read both the Javascript Triggers and the Validating a Custom DTD articles. I enjoyed and learned a lot from both of them.
But I am puzzled about all the discussion about using, defining and validating the custom attributes. Has no one heard of XHTML 1.1 or read the description (www.w3c.org/markup/#xhtml11), or the specification (www.w3c.org/TR/xhtml11)?
The problem you are all worrying about/discussing has already been mostly solved! If you want or need custom attributes or custom tags, you can just use the XHTML 1.1 doctype and modify the existing DTD's or (for the brave and talented) write and support your own DTD's.

28 Posted by Terry on 19 February 2005 | Permalink

Why not use input type="hidden" and grab the value attribute to include in your script?

29 Posted by Stan Vassilev on 23 February 2005 | Permalink

I can't understand where is the problem with standardizing on one single custom attribute for behaviours. Call it "behaviour".. Then it can contain all requires "subattributes" the application requires.

Just like cookies, assigning value uses "=" and separating variables can use "," or ";". It's not more complex than parsing cookies really (we can also have support for "short" attributes not mentioning values):

[a href=".." behaviour="rollLink;dhtmlTip='hello world'"] ... [/a]

However what bothers me is two things: what will "standard" geeks tell about our sites when they validate them in validators that don't support custom DTD... First...

And second, I've heard custom DTD's trigger QUIRKS mode in IE which is REALLY REALLY BAD.... Anyone care to comment this?

30 Posted by Michael Katzenmayer on 21 October 2005 | Permalink

At the moment, I'm trying to use comments as script triggers. comments are valid HTML, relatively easy to read via DOM methods, can contain "attributes" in whatever form you like and they don't "pollute" your classnames.

Instead of having something like:

you would use

or something similar. This works quite well at least in IE, Firefox and Opera.