Talk:Document Object Model

message: 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)
thread_title:  VTD-XML is not spam 

message: 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)
thread_title:  Information Not Current 

message: 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)
replies: text: 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)
thread_title:  Article Quality 

message: 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)
thread_title:  W3C Recommendations 

message: 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)
thread_title: Answer

message: 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)
thread_title:  W3C DOM 

message: 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)
thread_title:  More W3C DOM 

message: 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)
thread_title:  Using the DOM 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: I think it's even worse than that. This section implies the W3C was invested in the ECMAScript standard, which (according to Doug Crockford - yuiblog.com/crockford/ - Lecture 1), is entirely untrue. In fact, Crockford claims that the W3C did not standardization of JavaScript by Netscape at all, which led to Netscape's odd choice of ECMA for the JavaScript standardization body. The idea the the W3C (a standards body itself) would coordinate with other entities to have a third party standardize a web technology is absurd on its face. It would be like Toyota bringing together a group of companies to design a car for Honda. -plamoni (talk) 21:14, 21 August 2012 (UTC)
thread_title:  EMCAScript Confusion 

message: "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).  — Preceding unsigned comment added by Spxdcz (talk • contribs) 03:28, 24 February 2011 (UTC)
thread_title:  Layout Engines 

message: funfact: dom literally means stupid in norwegian. ~~  — Preceding unsigned comment added by Divinity76 (talk • contribs) 20:15, 6 November 2011 (UTC)
thread_title:  Dom means Stupid in norwegian. 

message: Should there be a section of the article on the Shadow DOM (and related topics such as the "twilight DOM")?
See http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
Strugee (talk) 01:50, 22 April 2012 (UTC)
thread_title:  Shadow DOM? 

message: So the sentence "The public interface of a DOM is specified in its application programming interface (API)" assumes that there is also a non-public one. Since DOM is an API and and any API is a "public interface" by definition the wording "public interface of a DOM" is misleading. --Smbat.petrosyan (talk) 03:45, 26 June 2012 (UTC)
thread_title:  DOM is API itself according to W3C specification 

message: The article mentions that the Document Object Model (DOM) "treats an HTML, XHTML, or XML document as a tree structure." What about SGML? Doesn't the DOM treats SGML documents? Since both HTML and XML are extended from SGML, and XHTML is extended from XML and HTML, perhaps we should mention SGML in the article and – if it isn't treated by the DOM – explain why it isn't. —Kri (talk) 07:18, 2 July 2018 (UTC)
thread_title:  DOM for SGML?