Talk:Document Object Model

VTD-XML is not spam

VTD-XML is an emerging XML processing model that combines the best of both DOM and SAX. Putting it in the description gives people more choices to meet their development needs. —Preceding unsigned comment added by Jzhang2007 (talk • contribs) 07:52, 31 October 2006 (UTC)

Information Not Current

It would be helpful if this page would discuss current implementation of DOM2/3 in the latest round of Web Browsers. Presently the article is two versions behind for IE, making it seriously outdated.

It would also be helpful if the article would update the progress of the DOM WG since the 2004 release of DOM3. Has the DOM working group continued its work, or is the standard essentially finished and stable? Cadwallader 13:40, 18 July 2007 (UTC)

Article Quality

I think the quality of this article is seriously lacking. There is very little information actually regarding the concept of the DOM, and not some tangent.

Also the firt subsection, "Levels", is completely without context: There is no explanation of what a DOM level even is.

I am going to put the cleanup boilerplate on the top of the page. Andy 17:53, 16 November 2005 (UTC)

I think I have copyedited the article enough to justify the removal of the cleanup message. Anyone disagreeing should feel free to add the cleanup message back. Aapo Laitinen 18:10, 19 December 2005 (UTC)

I’d have to agree with Andy that this article has some problems. I made some minor fixes but I think that it needs a significant re‐write as it seems like not much consideration has been put into the flow of the article. Unfortunately, I don’t know enough about the DOM and its history to do that. JustSomeGuy 01:35, 21 November 2006 (UTC)

The implementations section suggests that Konqueror, Opera, and Safari are Gecko based like Mozilla and Camino; when in fact Konqueror / Safari are based on WebKit/KHTML and Opera on it's own Presto layout engine. 65.13.19.19 (talk) 17:50, 5 January 2008 (UTC)

Title Letter Case

Should this article's title be lowercased to Document object model? Yes, I know it's a moot point once Wikipedia implements case-insensitivity, but until then... --Damian Yerrick

I don't think so, the W3.org on DOM page has Document Object Model. -- HJH

Some more things concerning the DOM can probably be mentioned in the article, for instance the fact that it is not only used in web-browsers but also for xml processing in other applications. A summary about the different levels of the DOM and what purpose they serve could also be helpful in my opinion. Also some links to implementations and libraries that are based on the DOM could be a good entry point for people reading this and being more interested in practical DOM. I never contributed to Wiki projects due to general lack of time, maybe I'll eventually get it going here. -- _tc

W3C Recommendations

Could anybody explain what is "W3C Recommendation"? Is there any difference between some Level 3 specification which is included in W3C Recommendation and which is not?

Answer

The entire W3C Process is described on the W3 site. Basically, working groups are created to make up working drafts, which pass through a series of revisions until they are finally released as recommendations. The recommendations are the 'standards'.

The various levels show major revisions - DOM 0 is essentially everything before W3C, DOM 1 was the first W3 standard, etc. DOM 2 is pretty well supported by nearly all browsers, DOM 3 is quite extensive and as yet its extensions to DOM 2 are not fully or widely supported (but it's getting there).

OzFred 07:19, 25 October 2005 (UTC)

W3C DOM

The article so far discouraged the use of the DOM giving the reason that browser support is not sufficient (including some Microsoft bashing). However nowadays the situation is fairly stable and many methods of the W3CDOM may be used without problems in a cross-browser way. I have added thow that it is a good practice to test first for the availabilty certain DOM-API functions. Hirzel 09:31, 20 August 2005 (UTC)

More W3C DOM

The discussion on feature detection is somewhat misleading and seems to suggest something only marginally better than good 'ol browser sniffing. The idea of feature detection is to test every feature that either may not be supported or may be supported differently on various browsers. The classic are of course getElementById and document.all, but there are many, many others such as clientX/clientY and pageX/pageY etc.

The outcome of feature detection is that either the appropriate code is offered for the environment, or nothing at all. There should be no errors shown to the user - the user should not even be aware that something has not happened.

Feature detection becomes even more important as use of XHLHttpRequest and parsing of XML becomes more prevelant - there are many differences even between versions of the same browser.

comp.lang.javascript FAQ #4.26 OzFred 07:09, 25 October 2005 (UTC)

Using the DOM

From my perspective as a University Javascript tutor, there is little information on this page that is practically relevant for doing DOM scripting. Only the graphic helps somewhat (but could be improved). This page could really use some examples and explanations for how the DOM is accessed from a coder's point of view. I would add some myself if I had more time. — SimonEast 23:13, 13 September 2007 (UTC)

Examples needed

This article could use a textual example of how a sample document (such as the one shown in graphical form) would be represented by the model. Some code or pseudocode showing how the model might be accessed would also be helpful to give a flavor of what the DOM actually is for someone who knows nothing about it. These examples would help improve accessibility of this article to a wider audience. -- Beland (talk) 20:20, 2 January 2008 (UTC)

Need some simple examples, like "here is a nutcracker, see how it cracks a nut", etc. Jidanni (talk) 20:43, 20 January 2009 (UTC)

♥...tEiNkZ..xAh uuLyTiN pOh...♥ —Preceding unsigned comment added by Yamdahc (talk • contribs) 05:42, 8 October 2009 (UTC)

Google Patent: Enhanced document browsing with automatically generated links to relevant information

Hi all, this is miles outside of my own subject knowledge area, but apparantly google have filed a patent to automatically place links on a webpage specific to each user, using the DOM.... thought it might be relevant (but may not be).

• Patent: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=20100153422.PGNR.&OS=DN/20100153422RS=DN/20100153422
• Article: http://www.free-seo-news.com/newsletter432.htm#facts (I know, the link looks a bit sale-sy, but I think their content is normally pretty good

EMCAScript Confusion

I may be wrong, but ECMA International created ECMAScript; W3C simply described an API for interacting with the DOM via ECMAScript along with ECMAScript "types" associated with the DOM. 108.28.51.60 (talk) 06:15, 12 November 2010 (UTC)

I agree, and the article begins, "The Document Object Model (DOM) is a cross-platform and language-independent convention ...". Where in the article are you seeing this confusion? --Nigelj (talk) 17:50, 12 November 2010 (UTC)

Here: "The World Wide Web Consortium (W3C), founded in 1994 to promote open standards for the World Wide Web, brought Netscape Communications and Microsoft together with other companies to develop a standard for browser scripting languages, called "ECMAScript"." The way it's worded it sounds to me like the article is suggesting that W3C created ECMAScript the language. 108.28.51.60 (talk) 02:35, 18 November 2010 (UTC)

Ah, I see. Are you saying that that sentence should end, "...a standard for browser scripting languages, which is now called "ECMAScript""? Or should the surgery go deeper, to completely separate the development of the DOM from that of the language? What do others think? --Nigelj (talk) 08:58, 18 November 2010 (UTC)

Layout Engines

"Web browsers rely on layout engines to parse HTML into a DOM" - this sounds incorrect (or possibly incorrect, depending on browser). Most modern browsers rely on a specific HTML parser to parse HTML into a DOM; the "layout engine" then creates the render tree from the DOM (to style/position elements for on-screen painting), but it doesn't parse the HTML into the DOM (or may not, depending on the browser).