views:

107

answers:

3

Up to what level of abstraction does the <!DOCTYPE> declaration (and content-type) of a document remain relevant?

For example, if I'm working with XHTML but want to use an element which is not available in XHTML - an easy example being an iframe - would it be bad practice to programatically add the element with JavaScript? Or do I either have to not use the iframe or not use XHTML?

A validator will still validate the document - since it doesn't execute the JS - but is there something theoretically wrong with modifying the DOM so it is no longer consistent with the <!DOCTYPE> (and returned content-type), or is the <!DOCTYPE> only relevant to the markup when it is in textual form?

Addendum

To be more specific, my question isn't about how the <!DOCTYPE> will affect JavaScript or how JavaScript will execute, but how it should affect a developers choices with respect to adding and removing and modifying elements programatically.

My example is if a client both wants XHTML compliance and WYSIWYG editors, what do you do with the iframe which often comes with WYSIWYG editors? Should you remove it from the markup, only to document.appendChild() it in the JS? Or do you tell your client they have to choose between the two - iframe or XHTML?

+3  A: 

The DOCTYPE definition, in standards terms, describes the markup. Thus once the markup has been parsed by a user agent, the DOCTYPE is irrelevent in that respect. In practical terms, the DOCTYPE also triggers browser behaviors, so what you do with/to the DOM dynamically is in that way affected by the DOCTYPE.

Pointy
I have edited my question to specify that my question isn't about hot the DOCTYPE will affect the JavaScript but rather about how it should affect what I aim to do with JavaScript.
LeguRi
But his point is, if you use JavaScript to insert an iframe where the browser doesn't expect one, because it uses some kind of "strict" mode, odd things might happen. So I'd say don't do that.
Peter Eisentraut
A: 

I am by no means a rules or standards fanatic, but inserting HTML elements into a doctype that doesn't support that element is stupid, because it may lead to subtle problems down the road that are impossible to debug.

So: It probably will work, and be no problem. (Your boss or client will never find out, as the validator can only run on the basic HTML).

I still wouldn't recommend to do it.

Pekka
Sorry but "subtle problems down the road" will happen equally likely with 100% valid code. They are usually the result of browser bugs.
DisgruntledGoat
Maybe, but browser bugs can mostly be identified by looking around on the web or asking on SO, as they have already happened to somebody else. Bugs or strange behaviour because you are using a `xyz` in doctype `abc` cannot. As I said, it will probably work fine, and I would have no problem applying some patch or workaround this way. But I wouldn't recommend it to anybody as a way of working.
Pekka
+1  A: 

Eesh, I see your point. If you’ve got one of those clients who thinks that a web page isn’t any good if it’s not XHTML, it could be tricky to talk them out of it.

Worth a try though: it seems pointless to spend time writing JavaScript to insert elements that aren’t valid in XHTML, rather than just using a doctype that allows the elements.

<iframe>'s still allowed in XHTML 1.0 Transitional though, isn’t it? Is that an option?

Paul D. Waite
Ya, iframe validates in XHTML Transitional.
LeguRi
I didn't think of this as a good practical solution... that is to say this is a good solution, which I didn't thing of.
LeguRi