Please tell me where are DOM objects are kept. It seems that some part of browser (rendering engine or maybe browser engine) creating them and keeping them.
For example, if we have a tag in HTML document, then DOM object is created, which inherits properties and methods from objects HTMLInputElement, HTMLElement, Element, Node, EventTarget, Object. It is not clear to me where they come from, seems that not from Javascript engine.
I cannot figure it out. Some people say that DOM-objects are Javascript objects, but not much. Pure JS-objects are created in JS engine.But DOM is written in C++ and allows to use DOM objects just like other JS objects. DOM objects look like other objects from JS language, and work like real JS objects.
How can these DOM-objects let create user-defined properties, that can bee "seen" in JS engine, if DOM-objects "live" not in JS engine?
I am coming to conclusion that DOM-objects are created in browser engine (ex Gecko). Which is written in C++. They inherit from classesNode, Element, HTMLElement
So it seems, that Node and HTMLElement - are host objects. In other words they are composed objects of browser engine Gecko, and not objects of JS engine. Some kind of instances of Gecko built-in classes.
But what the heck is Interface Definition Language?
Please show me where I am wrong in my understanding
Please tell me where are DOM objects are kept.
That's an implementation detail that matters little unless you are writing a browser.
How can these DOM-objects let create user-defined properties, that can bee "seen" in JS engine, if DOM-objects "live" not in JS engine?
The browser provides an API that exposes them to the JS engine.
But what the heck is Interface Definition Language?
A way to describe the API so you know (for example) what methods are available on a type of object.
Related
Here, it reads, "Therefore, this interface can be obtained by using binding-specific casting methods on an instance of the Node interface."
What does it mean that the interface can be "obtained" by "using the binding-specific casting methods?"
What are "binding specific casting methods?"
I understand that the word "binding" here is referring to a language binding. And, that "casting methods" are specific to the binding. But, it still isn't clear to me what the sentence means.
Practically, I would like to create an instance of an Object that inherits from EventTarget.prototype, and call EventTarget.prototype's addEventListener on it.
I understand that that is not possible. It is discussed here. I think the reason it is not possible may be related to this question.
IDL language bindings.
The link in the post is to a DOM2 specification of an "EventTarget" interface, written in IDL ("Interface Definition Language"). As a definition language, IDL describes what must be provided in a an interface written in a real language such as JavaScript, Java, MicoSoft Visual Basic for applications, or C++ for example.
"this interface can be obtained by using binding-specific casting methods on an instance of the Node interface."
is a technical way of saying "use the methods and properties documented for the language you are using, on a DOM node, rather than the exact wording of the specification provided here. The most binding we are most familiar with in web pages is, of course, for JavaScript. "Casting methods" may refer to how the implementation would automatically perform conversions between programming language and the DOM as required - e.g. converting JavaScript numbers to and from integer representations in some DOM attributes.
EventTargetPrototype
In Firefox this in object in the prototype chain of DOM nodes containing addEventListener and associated functions. Again it Firefox you can access it as
Object.getPrototypeOf( Node.prototype))
and then create an object prototyped on it, using
Object.create(Object.getPrototypeOf( Node.prototype))
This didn't work for dispatching events however. It seems additional support ( perhaps the Node interface as well?) is required. Using a HTMLSpanElement for the target "node object" worked in Firefox for dispatching and listening to an event without adding it to the DOM:
let a = document.createElement("SPAN");
a.addEventListener( "custom", function() {console.log("wow");}, false);
a.dispatchEvent( new CustomEvent("custom"));
Would I use this in production code? Definitely not. Except if thousands had tested it before me, in every browser type I might wish to support!
This is something I cannot find an official answer about. For some, DOM objects are JS objects, for others they differ. What is the right answer?
By searching in stackoverflow, you may see controversial opinions.
For example, does the object document.body belongs to DOM API only or may it be considered as part of javascript engine too?
Does Javascript create an internal representation of it or does it just communicates with DOM to access it?
The DOM API is a collection of standards which have implementations in a variety of programming languages.
The DOM available to JavaScript in a browser provides things in the form of JavaScript objects. Large portions of it are written in native code (so are handled by libraries not written in JavaScript but made available through a JavaScript API).
Where JavaScript leaves off and native code begins doesn't really matter, it is an implementation detail and probably varies from browser to browser. The point of having a standard API is that developers using it interact with that API and don't need to worry about how it is implemented under the hood.
Strictly speaking, no. The JavaScript runtime has access to them, and in that capacity they can function as JavaScript objects. But they are defined in a way that is not bound to any particular language, and in most DOM implementations, they're native code. Most DOM implementations take care to make the objects function the same way you'd expect other objects in the chosen language to work, but that's not always the same way that JavaScript objects do: for example, you can't go around adding dynamic properties to objects when you're working in Java.
For most practical purposes, when you're working in the browser or in some other JavaScript runtime, yes. As I stated above, most DOM implementations try to make the DOM objects work the same way as other objects in the language, and for JavaScript, that means making them work like "real" JavaScript objects. Although IE took a while to really get this right (you need IE9+ to take full advantage), these days you can pretty much use DOM objects the same way you'd use any other JavaScript object.
If you inspect deeply the __proto__ of document.body for instance, you would find this :
HTMLBodyElement > HTMLElement > Element > Node > EventTarget > Object
So yes : in the browser's context, DOM objects are JS objects, this is not reciprocal of course.
But DOM API is not exclusive to Javascript, it defines interfaces which can be implemented in any languages, for instance Python has a DOM API too and in this case, DOM objects are Python objects.
The DOM objects are not part of the JavaScript language, they are part of the environment that is provided when JavaScript runs in a browser.
When JavaScript runs in another environment, for example in Node.js, then there is no DOM. Instead there are other objects that make up the environment that the script works with.
The DOM objects are there just for JavaScript so the script works directly with the objects, there is no extra wrapper to make them available to JavaScript.
How can I find all subclasses (both immediate, as well as all descendants) of a given Javascript "class"? Note that Prototype (v1.6.0) supports this with "subclasses", but I am wondering about plain Javascript.
JavaScript (at least ES5 and below) has no concept of classes, it only knows prototypes, which have no idea who used them as "super" or "sub" construction. The Prototype library only knows these relations when you exclusively use its own class model on top of plain JS, simply tracking it as part of its extension API.
Are DOM objects regular Javascript objects? If not, what are they?
Does the DOM objects are reguler Javascript objects? if not, what are they?
No, they're "host objects". They don't necessarily play by all the same rules as native JavaScript objects.
They're in some sense objects, but they're added by the host environment and are not part of the ECMAScript specification.
For example, I don't believe there's anything that requires them to accept expando properties. Or in the case of functions, I don't know that they're required to have an accessible and extendable prototype property.
Also functions may or may not have the typical methods of Function.prototype, like .call() and .apply().
The rules are simply much looser than those of objects defined by the ECMAScript specification, so you can't necessarily rely on the same behavior in all cases.
They are of type HTMLElement
Yes, they are:
> typeof document.body
"object"
> document.body instanceof Object
true
Here is a description of the Documnet Object Model (DOM) from the Mozilla Development Network:
The Document Object Model is an API for HTML and XML documents. It
provides a structural representation of the document, enabling you to
modify its content and visual presentation. Essentially, it connects
web pages to scripts or programming languages.
All of the properties, methods, and events available to the web
developer for manipulating and creating web pages are organized into
objects (e.g., the document object that represents the document
itself, the table object that represents a HTML table elements, and so
forth). Those objects are accessible via scripting languages in most
recent web browsers.
The DOM is most often used in conjunction with JavaScript. That is,
the code is written in JavaScript, but it uses the DOM to access the
web page and its elements. However, the DOM was designed to be
independent of any particular programming language, making the
structural representation of the document available from a single,
consistent API. Though we focus on JavaScript throughout this site,
implementations of the DOM can be built for any language.
The World Wide Web Consortium establishes a standard for the DOM,
called the W3C DOM. It should, now that the most important browsers
correctly implement it, enable powerful cross-browser applications.
The DOM is an API , so a set of predefined "objects" attached to the window "namespace".
It can be HTMLElements but not only and they are not part of the javascript core.
So there is the javascript core and the DOM , and you can have other APIS.
I am excellent in Javascript, but currently started learning ActionScript. Can anyone teach me the difference between JavaScript Object and ActionScript Object ?
I request answer in few lines of description. Explanation with examples would be appreciated.
ActionScript has two different models in fact.
You can create classical ECMA-script objects either using literals or using the new-operator in conjunction with Function objects. Such objects work according to ECMA-standard.
You can create objects by instantiating ActionScript classes much like you would in Java for example. These objects ensure runtime type safety, i.e. if you try to assign a Foo value to a field typed as Bar you will get a runtime exception (or even a compile time exception if the object's type is known at compile time).
It should be noted, that you can compile AS3 with ECMA-script compatibility mode. In that case, AFAIK all objects will act as ECMA-script objects, sacrificing both execution speed and runtime type safety, but giving you flexibility.
Basically, Actionscript is a conventional Object Oriented Language in which it has Classes defining the structure of the objects instantiated.
JavaScript is a completely different flavour; you don't have access to Classes; you can emulate them (and that's a common trend for someone who's coming from a more conventional OOP mindset), but its strength comes exactly from the freedom you have. In a nutshell:
Objects are Functions - Functions are Objects
Objects are created in runtime, and can serve as a base (prototype), for creating other objects which, in its own advantage, can be morphed and override with new properties and methods, without having a strong bound to the strict definition of a class.