- From: David Woolley <david@djwhome.demon.co.uk>
- Date: Fri, 6 Oct 2006 21:31:01 +0100 (BST)
- To: w3c-wai-ig@w3.org
> David, can you clarify where this requirement is spelled out? In many The HTML 4.01 specification <http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.4>: HTML documents are constrained to conform to the HTML DTD both before and after processing any [134]SCRIPT elements. > cases it doesn't make sense - if I use javascript to modify the DOM, I'm > not modifying the HTML that has the validation linkage, I'm modifying > the browsers interpretation initial interpretation of that HTML. Which should be the DOM. You are creating a non-conforming DOM that only a particular browser may be able to understand and render sensibly. You can, of course, do browser sniffing, but browser sniffing tends to produce documents that are inaccessible because they fail very badly when a new browser comes along (witness the number of documents that broke on Netscape 4 because they tried to use Netscape 3 proprietary scripting methods). (Note that the HTML specification predates the W3C DOM, which uses actual DOM manipulations to modify the original downloaded document and doesn't permit document.write, except in contexts where it is the only means use to create every character of the written document.) > > I understand that you are objecting to the embed element in the > document.write statement, and that's fine. There are ways to avoid > using the embed element, but it does require some means of > differentiating between browsers. I'm objecting to not being open about the document failing validation against a W3C DTD. As far as I can see, the scripting only serves to prevent validator.w3.org, and similar, from correctly recognizing the DTD violation. It simply makes the document more fragile. It's similar to automatically placing [image.jpg] in all alt attributes.
Received on Friday, 6 October 2006 20:31:13 UTC