Discuss: More About Custom DTDs
by The W3C QA Group
- Editorial Comments
2 change from the ground up
It seems to me that what Peter-Paul Koch did was to make a compelling reason for other developers to use his techniques. They work well, and if many developers use the same technique it may put pressure on the members of W3C to incorporate those attributes or tags, or to provide a similar way to do the same thing in the next release of a particular recommendation.
I’m not entirely familiar with how the W3C is run, but I suspect it is a slow moving beast and its probably quite difficult for a sole developer with a useful idea to encourage any changes from within. By doing what he did, PPK got some developers excited and the W3C nervous.
I think the article is well founded, but PPK showed that perhaps if a technique that is philosophically wrong becomes popular, the standards makers will take notice.
posted at 10:49 am on May 17, 2005 by Jim
3 CDATA attributes
Good to hear W3C say validation is not a goal in itself!
But was it a warning or an opportunity when the article said: «The content of attributes, for instance, are generally defined in the DTD as being CDATA (more or less equivalent to “any kind of text”) [… ] Nothing in a DTD, for instance, can enforce that the content of the lang attribute must be a language code from RFC1766…»?
According to this, and to relate it to Koch’s article about JavaScript triggers one should be able to “invent” things like
style=”[removed]triggervalue;
and still get validated XHTML documents. And, yes, the W3Validator does indeed valdiate such documents. So, is it a limitation of the validator or a feature of (X)HTML? I tend to think it is the latter.
posted at 01:18 pm on May 17, 2005 by Leif Halvard Silli
4 Interesting Article
Very complete and thoroughly thought out article! While DTD’s can be custom defined, it doesn’t mean browsers will support them all. Pretty soon, as each platform is setout, such as on Mobile, PSP, etc, the custom DTD’s will soon become standard.
posted at 01:21 pm on May 17, 2005 by Oliver
5 Great article on the internal uses of Modular XHTM
I wrote a (pretty much unknown) article on using modular xhtml for an internal project several months ago (http://jeremy.marzhillstudios.com/programming/archives/000067.html). It was really useful internally although not so much to the outside world. I used modular xhtml to build a templating engine.
posted at 02:00 pm on May 17, 2005 by Zaphar
6 Take a step back and remember the original objecti
While I appreciate the authors’ point of view and recognize their expertise, I’d like to take a step back and consider the points of the original articles by Mr Koch and Mr Eisenberg.
The original Koch article was about separating behavior from structure and style — a desirable W3C objective if I ever heard one.
Mr Koch provided a quick way to achieve that W3C objective. But achieving a W3C objective at the cost of validation wouldn’t be right, so Mr Eisenberg stepped in with a way to validate pages that use Mr Koch’s method.
The authors of the present article seem to have ignored or discounted the original objective (separating behavior from presentation and structure).
Unless I’m being thick and slow, the authors’ alternative (modularizing XHTML) doesn’t seem to address the original objective of separating behavior from presentation and structure. It also seems harder than using JavaScript triggers, at least to me.
Just one designer’s opinion.
posted at 05:15 pm on May 17, 2005 by sanchez
7 This is all about embed
Look, this article goes completely off the rails when it uses a hypothetical example of a poetry element. (Typical of the W3C to use a hypothetical example rather than solving a problem we actually are dealing with.)
Where standardistas want a custom DTD to make an element valid is the case of embed and pretty much nothing else. W3C made a mistake in not incorporating embed into the spec. (It works everywhere but Lynx, while object barely works anywhere. More theory over practice.)
We don’t really care that a resulting XHTML+embed DTD won’t be XHTML Transitional or one of the cherished few family members in the W3C. It doesn’t have to be. The W3C doesn’t write all the rules; by the nature of XHTML, we can write the rules. Under WCAG Level AA, all we have to do is produce valid documents according to a published specification, not the specification that W3C nabobs want us to use.
So why don’t we have a nice tidy article— an applied article— from the W3C on how to make embed a valid element in our pages?
By the way, I’m at the point where if the only validation error on your page is the use of embed, as far as I’m concerned your page is valid because every reasonable device is going to understand it and you’ve already avoided tag soup.
posted at 08:15 pm on May 17, 2005 by Joe Clark
8 What about <input required="1" /> ?
My own interest in this is for adding custom HTML attributes that are recognised by javascript.
Essentially, I want to serve my “customised XHTML” to the big wide world, as is. Should I be using a custom DTD or not?
It seems to me that using namespaces would be the most “semantically valid” way of adding such functionality, but these still require a custom DTD to validate correctly.
In the light of this new information, what do people think?
posted at 10:56 pm on May 17, 2005 by Sam
9 Languages Evolve
The problem is that the W3C is not moving fast enough to meet the needs of web developers, so we’re forced to invent things like <input required=“1” /> to solve today’s problems now.
You assert that these extensions are “proprietry” and should be avoided, but fail to credit the previous author for openly documenting his extensions. In fact, these extensions could hardly be considered “proprietry” since the author is not imposing ownership of the technique. Rather, it’s out there, available for anybody to use, and available to any user-agent developer to learn its semantics.
Yes, it was a simple XSLT solution you provided. Show me how you would transform <input required=“1” minvalue=“10 maxvalue=“100” /> into standard XHTML and then I’ll be impressed.
posted at 06:43 am on May 18, 2005 by Adrian D.
Discussion Closed
New comments are not being accepted, but you are welcome to explore what people said before we closed the door.
Got something to say?
Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.
Create a new account or sign in below if you’d like to leave a comment.
Subscribe to this article's comments: RSS (what’s this?)
1 Real-world Example
A real-world example of the interoperability issues discussed here would be the W3C markup validator itself. Take some random German HTML document. Chances are that it’s in ISO-8895-1, ISO-8895-15 or Windows-1251 encoding. All three encodings are not HTML standard and must therefore be made known somehow.
The best option is always the server, which should send an encoding along with the content type. It may not be able to do so, however, especially on large servers with many accounts for individual users (e.g. Geocities). There, each user might have a different encoding in their files, so the server can’t make assumptions.
In XML files, the next place is the xml declaration.
<?xml encoding=”…”?>
But the file in question is supposed to be HTML, so there’s no such thing.
The validator accepts a third source, and that’s the meta tag.
<meta http-equiv=“Content-type” value=“text/html; charset=ISO-8895-1”>
Works fine, as long as you use a default HTML DTD. Modify or even extend it with a local subset:
<!DOCTYPE html PUBLIC “…” “…” [ <!ENTITY words “some words”>
]>
and suddenly the validator will no longer use the meta data – because the document is no longer HTML.
posted at 08:58 am on May 17, 2005 by Sebastian Redl