Tim’s got an important point about the danger of splintering standards that took a lot of work to get in place. On the other hand, I see a very practical use for this technique.
My team produces e-learning modules. The practical value of the standards for us is quality control: if every html page in the module validates, that’s one more assurance the client isn’t getting something that’s broken.
But: our work requires that we use <embed>. One of our clients still has some of its employees using Netscape 4.7. <object> won’t cut it. So when we validate, we ignore the multiple errors generated by the <embed> tag.
That means: every time we validate we need to manually read the error messages and make sure that they came from <embed> and not from something else. Which means that someday, we’re going to trip up and ignore an error we should have fixed.
Here’s where the custom DTD comes in: we validate against a custom DTD that allows the <embed> tag. When we validate, <embed> is silently passed by, and we know that any errors we see are errors we need to fix. We’ll likely do the same for the custom tags generated by Macromedia’s CourseBuilder (although placing them in a custom namespace would be more in the spirit of XHTML).
That said, it’s still troubling to work this way. I haven’t tried it out, but I’m guessing that some browsers will remain in quirks mode unless they see one of the public doctypes. For cross-platform consistency, we need to avoid quirks mode. For this reason, we may end up validating against our custom DTD but delivering pages with the XHTML Strict or Transitional doctype. It ain’t perfect, but it’ll do what we need to do for our clients.