Simply put, are document.URL and location.href considered part of the DOM (Document Object Model)?
The "DOM" (Document Object Model) is the name for the entire standardised in-browser API - not just the part that's concerned with the actual HTML document (i.e. [window.]document) - it also includes the window, navigator, and location objects.
Granted, many parts of what's available to you in JavaScript are not part of the DOM, namely JavaScript's built-in library, such as String, Array, parseInt, and so on - and given that people generally learn both JavaScript and the DOM at the same time it's often very hard to tell them apart.
There are also pseudo-standard components that are not officially part of the DOM (until recently, or post-facto or defacto standardisation), such as XMLHttpRequest (originally a Windows/IE-only COM component exposed through Microsoft's proprietary ActiveXObject JScript API).
...but the DOM is not always available in JavaScript, you can use JavaScript as a shell-scripting language (e.g. Windows Script Host), or in server roles (Node.js) - there's no document and navigator element there, for example (though strictly speaking, there are "server-side DOMs" used for generating markup dynamically).
And conversely, you can have the DOM without JavaScript: the DOM is simply an API specification, there are implementations for Java, .NET, and others. The DOM was originally designed for both Tcl and JavaScript, for example.
Related
JavaScript lets you add arbitrary properties and methods to any object, including DOM nodes. Assuming the property was well namespaced (something like _myLib_propertyName) so that it would be unlikely to create a conflict, are there any good reasons not to stash data in DOM nodes?
Are there any good use cases for doing so?
I imagine doing this frequently could contribute to a sloppy coding style or code that is confusing or counter-intuitive, but it seems like there would also be times when tucking "custom" properties into DOM nodes would be an effective and expedient technique.
No, it is usually a bad idea to store your own properties on DOM nodes.
DOM nodes are host objects and host objects can do what they like. Specifically, there is no requirement in the ECMAScript spec for host objects to allow this kind of extension, so browsers are not obliged to allow it. In particular, new browsers may choose not to, and existing code relying on it will break.
Not all host objects in existing browsers allow it. For example, text nodes and all ActiveX objects (such as XMLHttpRequest and XMLDOM objects, used for parsing XML) in IE do not, and failure behaviour varies from throwing errors to silent failure.
In IE, the ability to add properties can be switched off for a whole document, including all nodes within the document, with the line document.expando = false;. Thus if any of the code in your page includes this line, all code relying on adding properties to DOM nodes will fail.
I think more than anything, the best reason not to store data in the DOM is because the DOM is meant to represent content structure and styling for an HTML page. While you could surely add data to the nodes in a well-namespaced manner as to avoid conflicts, you're introducing data state into the visual representation.
I'm trying to find an example for or against storing data in the DOM, and scratching my head to find a convincing case. In the past, I've found that the separation of the data state from the visual state has saved headache during re-designs of sites I've worked on.
If you look at HTML 5 there is the data attribute for fields that will allow you to store information for the field.
Don't be surprised to run into trouble with IE 6 & 7. They are very inconsistent with setAttribute vs set as a property.
And if you're not careful you could set circular references and give yourself a memory leak.
http://www.ibm.com/developerworks/web/library/wa-memleak/
I always set node properties as a last resort, and when I do I'm extra careful with my code and test more heavily than usual.
For what it's worth, the D3.js library makes extensive use of custom properties on DOM nodes. In particular for the following packages that introduce interaction behaviors:
https://github.com/d3/d3-zoom - the __zoom property
https://github.com/d3/d3-brush - the __brush property
D3 also provides a mechanism for putting your own custom properties on DOM elements called d3.local. The point of that utility is to generate property names that are guaranteed not to conflict with the DOM API.
The primary risk I can see associated with custom properties on DOM nodes is accidentally picking a name that already has some meaning in the DOM API. If you use d3.local or maybe prefix everything with __, that should avoid conflicts.
I am not aware about the relationship between scripting language and Document Object Model as exactly
All we know that DOM is an API for HTML and XML document to manipulate as objects generated by document structure tree , so API has propriety and method which we can use them to control changes in a document but if we say that we will find finally there is no any intervention for scripting language like JavaScript
for example in case we type this line in our HTML document :
document.getElementById("demo").innerHTML = "Hello World!";
we will find just DOM API ( method and propriety ) , no any trace for JavaScript
what is relationship between DOM and JavaScript , why always appear together while I am not feel trace of JavaScript , if scripting take place in HTML document all I find API DOM tool ( method and propriety ) , I could not able to touch JavaScript working in our HTML document
Despite the fact that this post is currently at -3 points and poorly phrased, I think I can suss out the question the poster is asking and will try to answer it. Hopefully the community won't punish me for answering on a negatively scored question.
Yes, you clearly have some confusion around the definition and relationship between what constitutes the JavaScript language and what constitutes the DOM API.
JavaScript is a programming language. It has functions, inheritance, variables, operations, etc etc.
function addTwo(num) {
return num + 2;
}
var eight = addTwo(6);
console.log(eight); // logs 8
It has some cool features that some other languages don't, like functions as first-class citizens. We won't cover that here.
While JavaScript can run in a few different environments, it was originally written for the purpose of scripting in web browsers. It is the only scripting language that the browser can execute (with probably a few exceptions not important here). The DOM (Document-Object Model) is the interface by which JavaScript can interact with the document and nodes being shown in the web page. It allows you to get elements on the page, manipulate them, create them, delete them, etc. When you are interacting with the DOM, you are doing so in JavaScript. It is simply an API available to JavaScript for manipulating the document, not a separate language unto itself.
Hopefully this clears things up for you. Also note that JavaScript is not relegated to the browser-- the most common other environment for JavaScript is NodeJS, which allows for all sorts of fun stuff like tooling or writing your backend code with JavaScript.
This page from the Mozilla Developer Network characterizes the distinction elegantly:
...it's written in JavaScript, but it uses the DOM to access the document and its elements. The DOM is not a programming language, but without it, the JavaScript language wouldn't have any model or notion of web pages, HTML documents, XML documents, and their component parts (e.g. elements).
(Also, the world is probably not as 100% black and white as I have spelled it out here. There are probably edge cases in which other languages can be made to run in a browser, or perhaps there is some way to interact in the DOM with Web Assembly, which is relatively new to the scene. I'm just spelling out here the simplest case that probably covers the vast majority of scenarios existing today. However, this page from MDN does give an example of interacting with the DOM using Python.)
I've been writing Javascript for years, but just now realized I don't entirely understand how these "HTML-y" methods actually interact with the DOM.
My assumption is that when HTML is interpreted into the DOM, the browser keeps references as to which HTML element became which DOM node.
So for .getElementById when you select an element, the browser returns the relevant node by reference. Why not just do .getNodeById then and be more correct?
My assumption is that .innerHTML is interpreted by the browser into the DOM at runtime. However, in older browsers like IE7, .innerHTML cannot be used to create table nodes. This suggests to me that it was originally intended just to modify the text properties of existing nodes, but then it seems strange that it exists at all, and we don't just use .innerText.
I guess I'm just confused by some Javascript history.
Well, the thing is, things like .innerHTML and .getElementById aren't really JavaScript objects at all. They're what the language specification calls "Host Objects" - it's a form of FFI. What happens when you call .getElementById in most browsers is that the string is marshalled from a JS string to a DOM string and then passed to C++ code.
In fact, they're allowed to have pretty much whatever semantics they please - the language makes no guarantees about how they act (this is also true for other DOM objects like timers and XHR).
well if you really want to know about the internals and want to digg into the deep rabbit hole of rendering engines i'd give you a start by pointing you to certain source files of chromium:
http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Element.cpp
you could find stuff like innerHTML and how it actually works in it. (around line 2425)
.getElementById() will just resolve to a document element that matches the specified id and will return a reference to it.
its some kind of identifier with prototyped methods, getters and setters to interact with that element. as soon as you interact with methods like innerHTML etc. you will simply tell the engine to execute that action on the element that is referenced inside the element reference.
just digg around inside the source code. you might get a good insight:
http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/
this is maybe a stupid question, but when I search for an answer I get jQuery results that talk about object arrays. I'm not there yet and want to understand how javascript itself is interacting with the DOM.
The DOM is an object tree created and used to render HTML if I'm not mistaken? And javascript has objects of the same name. For example: window, document, and elements with id... Are these the same objects?
I've read that javascript is part of HTML5, is this because the javascript objects are in fact the DOM objects and that the javascript language has been built up around the DOM? If so, how could it ever be possible to use javascript without the DOM? - For example, how could you ever make a desktop app? I use a program called brackets which is coded in javascript.
I think MDN has a great definition:
The Document Object Model (DOM) is an API for manipulating HTML and XML documents. It provides a structural representation of the document, enabling you to modify its content and visual presentation by using a scripting language such as JavaScript.
So the DOM is the specification of an API which can be used to select, manipulate and create new elements in a webpage, via an API.
That API is made visible (or exposed) to us, JavaScript developers, by allowing us to access JavaScript objects which implement particular parts of the DOM API.
The window element is one of those; as MDN says
The window object implements the Window interface, which in turn inherits from the AbstractView interface.
window is the JavaScript object window.
... it implements the DOM Window interface
... which, behind the scenes (we don't really care about this) inherits the AbstractView interface.
However, as well as implementing the DOM Window interface, window also exposes several JavaScript types and functions; which are not part of the Window interface, but exist on the window object.
All the types; window.String, window.Object, window.Array.
Math
...
As you specifically mentioned document; document is part of DOM Window interface, which you can see listed here.
In short, anything which involves selecting, manipulating and creating HTML elements will usually be part of the DOM.
HTML5 is the latest HTML standard which add new HTML elements such as <audio> and <video> tags. The DOM API has been updated to allow those new elements to be controlled by the API.
In turn, the JavaScript objects which implement those API's have to be updated.
JavaScript is a programming language. The DOM can be thought of as a framework or library which lets you control HTML from JavaScript.
JavaScript can be used completely standalone, without this library; which is exactly what happens in environments such as NodeJS and Brackets.
Take it this way:
You need an environment and a program.
The environment is the browser
The program has :
an interface( web page aka document)
code (javascript)
So you end up with 3 object models
DOM document object model
BOM browser object model
JOM javascript object model
The following graph may help:
http://javascript.info/tutorial/browser-environment
I know a bit of Javascript and have recently started trying to tie it into HTML with the code academy course. in the following code:
function sayHello(name){
document.getElementById("result").innerHTML = 'Hello ' + name + '!';
}
The "document" in the above code is the DOM?
That would mean that getElements is a property (function) of document, and that innerHTML is a function of the getElements function.... right?
If I am seeing this correctly, how is it possible that DOM objects have javascript properties/functions?
Is document the DOM
Short answer
Yes, in the sense that it is the root of it.
Slightly longer answer
The Document Object Model (DOM) is what the browser exposes to the JavaScript runtime to allow JavaScript code to manipulate the page (its nodes and associated metadata). document is one part of the DOM.
How can the DOM have JavaScript properties
Short answer
They don't.
Slightly longer answer
The DOM is not actually managed in JavaScript (yet). It is typically managed by a separate engine altogether, written in a lower-level language like C++ or Rust (in the case of Mozilla's Servo project). The JavaScript runtime is also written in a lower-level language (again, C++ is most likely) and certain attributes of the DOM are exposed to the JavaScript runtime as if they were native JavaScript objects. The fact that they are not makes all kinds of interesting things possible ... and generally make it so that these DOM objects do not always behave as you would expect "real" JavaScript objects to behave (for example typeof querySelectorAll in IE 8 returns "object", not "function" as one would reasonably expect).
the Document Object Model is a model for interacting with HTML. They do not have "javascript properties" or "functions", javascript functions are executed on HTML elements which are found through the DOM.
getElementbyID
is a function in javascript, which retrieves a HTML element based on the DOM. Below is what the DOM looks like, and is how javascript will execute the aforementioned function.
http://www.w3schools.com/js/js_htmldom.asp
Close. document is the root element in the DOM, or Document Object Model. The DOM is the in-memory representation of the current document.
Calling document.getElementById() returns an HTML element, which has the property innerHTML. Writing to innerHTML tells the browser to render the string as that element's children.
DOM objects do not have javascript-dependent properties or attributes. Javascript is just one way of accessing DOM attributes.
DOM can be thought as an Interface (provide by layout engine like Gecko in Google Chrome and Firefox ) between the HTML and Any_Other_language
{like JavaScript} that want to use the html.
Say Tomorrow If a new language is born ( something similar to javaScript but a new language that has it's engine implemented in the browser like JavaScript has V8 engine in Google Chrome ) that want to play around with HTML, then just to access the HTML they don't have to write some hefty low level code( inside the engine for this language ) instead they can use DOM_Interface ( inside the browser ) to access and this makes it easy for them to concentrate on their logic.
DOM is Document Object Model ie your whole document is the hierarchy of objects with Window being the parent of all.
It provides a structured representation of the document (a tree) and it defines a way that the structure can be accessed from programs so that they can change the document structure, style and content.