Talk:Document Object Model

This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing Mid‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing Mid This article has been rated as Mid-importance on the project's importance scale.

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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?

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

that would define original interpretation of what u searching and would help users to d copies. you cand do that in foirums but i order to read it u must do screen captures.

can someone guide next an wp editor proceed & upload printscreens?paul80

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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) — Preceding unsigned comment added by 167.80.246.204 (talk) [reply]

"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)[reply]

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

Hello, I thought I'd come here to ask permission to add a clarifying section before "History" explaining what "the DOM" usually refers to. I literally spent years not knowing what people were talking about when they kept referring to "the DOM," mainly because every time I came here I found plenty more talk about this "DOM" but no explanation of what it is.

So I'd like to add a straightforward explanation, but I'd also like feedback about what it should say. I now have a good conception of what the DOM is, but I'd rather be corrected here, now, than on the actual article, later. Please let me know if you think it needs to be more accurate or precise, but hopefully we can keep it simple and straightforward:

The DOM is a representation of the tree of elements in a page. These elements are what HTML tags are marking in an HTML document. When a web browser reads the markup (HTML, XHTML, etc) in a webpage, it builds a DOM for the page, usually in memory, from its tag structure. As an example of how the DOM is distinct from the HTML it is based on, the elements of a DOM may not correspond one-to-one to the tags in a page. This is due to irregularities such as invalid HTML and omitted optional tags. In the former case, web browsers attempt to build a DOM out of ambiguous markup. In the latter case, a browser will still add elements to the DOM which were not represented by tags. The DOM that the browser constructs is what it then uses to render the page for display to the user.

Another factor distinguishing the DOM of a webpage from its markup is the effect of client-side scripting (usually JavaScript). The initial DOM constructed from the markup can serve as the target of scripts. The elements of the DOM are what JavaScript manipulates. After each manipulation, the DOM has been further altered from its initial representation of the markup. At each step, the page is re-rendered to the user.

Another language that targets the DOM is Cascading Style Sheets or CSS. CSS can change the display of a webpage by naming elements in its DOM and specifying how they are rendered.

--Qwerty0 (talk) 09:31, 8 December 2011 (UTC)[reply]

Oh, forgot to mention: There's a good explanation of the intricacies of HTML, browser parsing, DOM's, tags, and elements in this video (the real DOM talk starts at 8:39). It includes great things like this explanation of the difference between HTML tags and DOM elements. I'm aiming to have something in this article equally clarifying.

--Qwerty0 (talk) 09:54, 8 December 2011 (UTC)[reply]

That looks like a very good idea to me. Your explanation is good, but I thought of a few things that I would change as I read it. rather than mess with your original, I'll copy it below and mark my suggested changes in bold. Lastly, of course, references would make this much better. are there any books or authoritative webpages that give this level of explanation that you know of? WP:V says that "any material challenged or likely to be challenged must be attributed to a reliable, published source using an inline citation". I don't have any challenge, and I doubt that anyone else would, but good references are much better than none. Also, I find that comparing article text with a good reference often improves it by suggesting better words or phrases in crucial places.

The DOM is a representation of the tree of elements in a page. These elements are what the HTML tags represent in an HTML document. When a web browser reads the markup (HTML, XHTML, etc) in a webpage it builds an object model of the document, a DOM for the page, usually in memory from its tag structure. As an example of how the DOM is distinct from the HTML it is based on, the elements of a DOM may not correspond one-to-one to the tags in a page. This may be due to irregularities such as invalid HTML and omitted optional tags. In the former case, web browsers attempt to build a DOM out of ambiguous markup. In the latter case, a browser may add elements to the DOM which were not represented by tags. The DOM that the browser constructs is what it then uses to render the page for display to the user.

The DOM of a webpage needs to be distinguished from its markup because of client-side scripting (usually JavaScript). The initial DOM constructed from the markup can serve as the target of scripts. The elements of the DOM can be manipulated by JavaScript. After each manipulation, the DOM has been further altered from its initial representation of the markup. At each step, the page is re-rendered to the user.

The DOM is also accessed by Cascading Style Sheets or CSS. CSS can change the display of a webpage by addressing elements in its DOM and altering how they are rendered.

--Nigelj (talk) 12:39, 8 December 2011 (UTC)[reply]

Awesome, thanks for the feedback! Yeah, sorry, I should've mentioned that I was intentionally leaving out the citations; just trying to get the wording right. I'm still working on that part. I don't have extremely official sources yet, but most of what I said is contained in the talk I mentioned above (by a member of Google Developer Relations), and this article (on a Google-produced site about HTML5).

As for the edits, they mostly sound good, though there are a few places where I'd ask for rewording:

• "..elements are what the HTML tags represent.." I'd actually prefer the original phrasing of "..elements are what HTML tags are marking..". To me, at least, it's a little more straightforward. Plus, I think the former is a bit less accurate. I know you didn't mean this, but I think your version is too easy to mistake for "the tags are the elements" rather than "the tags mark where to make a DOM element and what information to add to it." Of course, according to the very explanation I'm taking this from, I should get punched in the face for correcting someone on this minutiae.
• "..in a webpage it builds an object model of the document, a DOM for the page, usually in memory from its tag structure." Could I rearrange this to keep it less unwieldy? Perhaps "..in a webpage it builds a DOM for the page in memory from its tag structure: an object model of the document." in fact, I didn't know about the idea of generic object models. I think this could be worth expanding in a later section.
• "The DOM of a webpage needs to be distinguished from its markup because of client-side scripting.." What I was trying to get at was that the effect of Javascript altering the DOM is another reason the DOM ends up usually being different from the plain HTML. But I don't think I phrased it well. How about "The DOM of a webpage is often distanced further from its markup by the effect of client-side scripting.."?

--Qwerty0 (talk) 08:06, 11 December 2011 (UTC)[reply]

Woh. This is going to be hard. Especially if there's just the two of us. I've just had a read through the talk sections above, and a look at the article. There's a lot to be done here, and I can't find any decent references for the level of detail that's needed. I found this, http://www.w3.org/TR/DOM-Level-2-Core/introduction.html, and some other less useful stuff.

I think there are many levels to get in order.

• The DOM defines an Interface (computing), through which Client-side scripting can access and manipulate HTML and XML documents
• In an HTML DOM, the document is represented as a Tree (data structure) comprising the HTML elements, HTML attributes, text and other aspects of the HTML text document
• Although the DOM defines an object model of the document, there is no requirement that the DOM implementation (in the web browser or wherever) uses this object model to represent the document, just that it fulfils the interface as if it did.
• If scripts alter or manipulate the DOM 'objects' via the provided interface, then a web browser should alter the displayed representation appropriately.
• DOM Level 3 provides for XML DOM structures to be serialised back into markup text. There are many reasons and ways that the output document may differ from original markup:[1]
  • The DOM may have been manipulated by scripting since it was loaded
  • The serialisation mode may have been set to alter XML entitys
  • the serialisation mode may alter whitespace, namespaces, etc

I had some of that wrong in my version above, but I think it's better here. I left most of the links un-piped for now. Once we (and whoever else may show up to help) agree what the points are, we can re-write the prose, I hope. --Nigelj (talk) 17:47, 30 December 2011 (UTC)[reply]

Yeah, it seems like a somewhat neglected article. But I do agree, it's a quite important and often-referenced concept. Which is what got me interested in at least an introductory explanation. Unfortunately I don't have time to devote to a full fix-up. I think the details you outlined are very good to note lower down in the article. At the moment it doesn't even have a section on those topics.

But if you're alright with my latest revision of the introductory section, I'll go ahead and add it once I've found some references? The w3c document you linked might be useful for some of it, but unfortunately until HTML5 the specification didn't even address the inner workings I refer to.

--Qwerty0 (talk) 06:01, 31 December 2011 (UTC)[reply]

I've just found this again, having forgotten it for a few months. I see neither of us actually did much in the end at the time. I've just reverted an edit by TheBoothy (talk · contribs). I'll explain why in steps as it's all pretty relevant to what we were saying above.

• 'Web browsers usually use an internal model similar to the DOM' - there is no reason why they have to, internally, as long as they fulfil the DOM's interface when scripts make calls on it.
• '...and to inspect or modify a Web page using JavaScript code' Browsers don't 'inspect or modify' a Web page using JavaScript. The JavaScript is external to the browser, written by a web developer as part of some webpage, and it may (depending on the developer's intentions) inspect (or query, or read, or search) or modify (or alter, or add to, or delete part of) the page's DOM.
• When we say 'JavaScript sees...', that isn't sloppy English for 'JavaScript inspects...'. The script 'sees' the page via its interface (computing); that is good technical grammar, whether it is querying the page structure, or altering it. It is not, per se an inspector of things.

I hope this will be clearer when somebody has a good go at writing a proper clear explanation. --Nigelj (talk) 00:15, 18 March 2012 (UTC)[reply]

I just watched this video, linked by Qwerty0 (talk · contribs) above. In that the speaker is pretty definite that the DOM is the data structure produced by the browser's parser. He's talking about HTML5, and there are now reference implementations of the perfect parser getting released, open source. These are written in Python, Java etc and are pretty certainly object oriented in their implementations. So what is the point in me trying to maintain some subtle distinction in my first bullet point just above, and the third bullet in my list above that one. So, I re-read this DOM Level 2 spec. In that the authors are pretty clear that the parser may not even be written in an OO language (guess, e.g. C), and so there is no way it can create the objects specified by the DOM spec: "The structure of SGML documents has traditionally been represented by an abstract data model, not by an object model." Therefore there is no necessary link between the internal data structure and the DOM, only a requirement to behave properly to incoming, valid, DOM-based, OO, script code: "The Document Object Model is not a set of data structures; it is an object model that specifies interfaces." Now, this article is about DOMs in general, not just the HTML5 DOM, so we need to maintain the distinctions required by other DOM specs, I think, at least until they are deprecated, or have really fallen out of use just about everywhere. That said, with free open-source, perfect, HTML5 parsers available, no one but an idiot would write their own - especially in a non-OO language - these days (and have to simulate all that OO DOM stuff from some other data structure). So, maybe there is no need to harp on about the older distinctions. Comments welcome. --Nigelj (talk) 01:28, 18 March 2012 (UTC)[reply]

Right now, the opening paragraph of the article is pretty much junk. One should never, ever load up an introduction with technical jiberish and word after word of linked explanations. That just turns off the reader. Please put something like Qwerty0's simple explanation in place of it. It just makes more sense. - KitchM (talk) 18:51, 15 April 2014 (UTC)[reply]

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)[reply]

Cite error: There are <ref> tags on this page without content in them (see the help page).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)[reply]

you could say DOM Level 0 coprises part of html4 that way users would use _full html_ in version4, and even more programmers would migrate tro hyml4 and html5 — Preceding unsigned comment added by 188.25.110.232 (talk) 02:42, 30 October 2012 (UTC)[reply]

why not?

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)[reply]