OE1-5.2 JavaScript & the Document Object Model

What this is and why it exists

One idea turns a static page into something a program can work with. The browser parses your markup into a tree of objects, and code can read and change that tree.

The second idea is a shift in how programs are written. Instead of running from top to bottom and finishing, the code sits and responds to things that happen.

The vocabulary

• DOM — the document object model. The page represented as a tree of objects.
• Node — one item in that tree, such as an element or a piece of text.
• Selector — a description used to find elements in the tree.
• Type coercion — the language converting a value from one type to another automatically.
• First-class function — a function that can be stored in a variable and passed as a value.
• Regular expression — a pattern describing a set of strings.
• Event — something that happens, such as a click, a key press or a page finishing loading.
• Handler — a function registered to run when a given event occurs.
• Event-driven — a program structured as responses to events rather than a single sequence.

The mental model

Take the language basics quickly, because most of it is shared with any language you know. Two things are genuinely different and both deserve care.

The first is automatic type conversion. The language converts between types on its own when an operation is applied to mismatched values, which is convenient and occasionally produces results nobody expects. Comparing a number to a string of digits, or adding values of different types, has defined behaviour. Read it once rather than discovering it during a bug.

The second is that functions are values. A function can be stored in a variable, passed to another function and returned from one. That single property is what makes the event model below possible. Registering a handler means handing a function to the browser to keep and call later.

Regular expressions are worth what they cost. A pattern describes a set of strings, and the same notation appears in every language you will meet afterwards. They are the standard tool for checking that input has the shape you expect. They also become unreadable quickly, so write them with a comment saying in words what the pattern accepts.

Now the tree. When a page loads, the browser parses the markup into a structure of objects. Each element becomes a node, nesting becomes parent and child relationships, and text becomes nodes too. Your code holds references into that tree and changes it, and the browser re-renders what changed.

That is the bridge from the previous topic to anything interactive, and it explains what scripting a page actually is. You are not editing text. You are editing a data structure that the browser is displaying.

Finding the element you want is the next step, and doing it badly is why so much page code is fragile. Selecting by a stable identifier or a purpose-made class survives changes to the markup. Selecting by position in the tree, or by chains of parent relationships, breaks the first time someone adds a wrapping element. Selection is a coupling between your code and your markup, and loose coupling is better here for the same reason it is everywhere else.

Events are the real content of this topic, because they change the shape of the program. Instead of a sequence that runs and finishes, you register functions and the browser calls them when something happens. Your code is idle most of the time and runs in short bursts, and it has no control over the order those bursts come in.

That is a genuine shift in thinking, and it is the same shift that appears later in any interface or server work.

The events you meet first are the obvious ones: a page finishing loading, a button being pressed, text changing in a field. Form controls raise a point the course should not skip. A password field is an ordinary field that hides its characters on screen. Code can read what is in it, and so can anything else running on that page. Never handle a password in page code beyond passing it over a secured connection, never store it in the page, and never log it. The hiding is for the person behind the reader, not a security property.

Moving elements after the page has loaded closes the topic. The older mechanisms for arranging content are included for completeness, and you will meet them in existing code. The two-dimensional layout system from the previous topic is the modern answer, and reaching for the older ones by choice is not.

What you should now be able to explain or do

Say what the tree is and what scripting a page actually changes. Name the two genuinely different features of the language and why the second enables events. Select elements in a way that survives markup changes, and say why position-based selection is fragile. Describe the event-driven shape and how it differs from a sequential program. State the rule about password fields.

Check yourself