11 Great article!

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.

posted at 12:51 pm on February 1, 2005 by Charles Martin

12 What if...

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.

posted at 12:52 pm on February 1, 2005 by Justin Perkins

13 Great!

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.

posted at 12:55 pm on February 1, 2005 by Michael Havard

14 A custom DTD but...

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?

posted at 01:03 pm on February 1, 2005 by Woolly Mittens

15 the class debate

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.

posted at 01:09 pm on February 1, 2005 by Will Rickards

16 DTD with onmouseover?

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.

posted at 01:12 pm on February 1, 2005 by Kamil "Brego" Dzielinski

17 Excellent articles!

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.

posted at 01:13 pm on February 1, 2005 by Bobby van der Sluis

18 Great articles

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?

posted at 01:25 pm on February 1, 2005 by Jonathan Broome

19 2 comments

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.

posted at 01:47 pm on February 1, 2005 by ppk

20 Regarding Standards

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.

posted at 01:54 pm on February 1, 2005 by Pork Chop