First I'd like to clear up two misunderstandings:
Now let's proceed to the critique my article has encountered.
Among others, Shaun Inman wondered:
If browser vendors should not take liberties with custom tags and attributes, shouldn’t individual developers adhere to the same principle?
My answer is a clear No, for two reasons.
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.
Among others, commenter DEFusion quite rightly pointed out:
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.
If we use a
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.
Among others, Paul Hammond feels the creation of custom DTDs has its drawbacks:
There is some truth in this, and I see a few options for solving this problem:
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.
Secondly, we could delve deeper into what I call "inline DTD extensions", like
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ATTLIST input required CDATA #IMPLIED> ]>
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.
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.
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.
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.
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.
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.
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.
This last example extends the idea of custom attributes in one way, and I'd like to mention a few other possible extensions.
<embed> example defines not a custom attribute but a custom tag.
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.
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.
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.
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.
Meanwhile, other web developers will have to take their own stance on this.
If you like this blog, why not donate a little bit of money to help me pay my bills?
Comments are closed.