Data object model in html

Содержание

Document Object Model (DOM)
DOM interfaces
Obsolete DOM interfaces
HTML DOM
SVG interfaces
SVG element interfaces
SVG data type interfaces
Static type
Animated type
SMIL-related interfaces
Other SVG interfaces
Specifications
See also
Found a content problem with this page?
MDN
Support
Our communities
Developers
Constructing the Object Model
Summary #
Document Object Model (DOM) #
CSS Object Model (CSSOM) #

Document Object Model (DOM)

The Document Object Model (DOM) connects web pages to scripts or programming languages by representing the structure of a document—such as the HTML representing a web page—in memory. Usually it refers to JavaScript, even though modeling HTML, SVG, or XML documents as objects are not part of the core JavaScript language.

The DOM represents a document with a logical tree. Each branch of the tree ends in a node, and each node contains objects. DOM methods allow programmatic access to the tree. With them, you can change the document’s structure, style, or content.

Nodes can also have event handlers attached to them. Once an event is triggered, the event handlers get executed.

To learn more about what the DOM is and how it represents documents, see our article Introduction to the DOM.

DOM interfaces

Obsolete DOM interfaces

The Document Object Model has been highly simplified. To achieve this, the following interfaces present in the different DOM level 3 or earlier specifications have been removed. It is uncertain whether some may be reintroduced in the future or not, but for the time being they should be considered obsolete and should be avoided:

DOMConfiguration
DOMErrorHandler
DOMImplementationList
DOMImplementationRegistry
DOMImplementationSource
DOMLocator
DOMObject
DOMSettableTokenList
DOMUserData
ElementTraversal
Entity
EntityReference
NameList
Notation
TypeInfo
UserDataHandler

HTML DOM

A document containing HTML is described using the Document interface, which is extended by the HTML specification to include various HTML-specific features. In particular, the Element interface is enhanced to become HTMLElement and various subclasses, each representing one of (or a family of closely related) elements.

The HTML DOM API provides access to various browser features such as tabs and windows, CSS styles and stylesheets, browser history, and so forth. These interfaces are discussed further in the HTML DOM API documentation.

SVG interfaces

SVG element interfaces

SVGAElement
SVGAnimationElement
SVGAnimateElement
SVGAnimateColorElement Deprecated
SVGAnimateMotionElement
SVGAnimateTransformElement
SVGCircleElement
SVGClipPathElement
SVGComponentTransferFunctionElement
SVGCursorElement
SVGDefsElement
SVGDescElement
SVGElement
SVGEllipseElement
SVGFEBlendElement
SVGFEColorMatrixElement
SVGFEComponentTransferElement
SVGFECompositeElement
SVGFEConvolveMatrixElement
SVGFEDiffuseLightingElement
SVGFEDisplacementMapElement
SVGFEDistantLightElement
SVGFEDropShadowElement
SVGFEFloodElement
SVGFEFuncAElement
SVGFEFuncBElement
SVGFEFuncGElement
SVGFEFuncRElement
SVGFEGaussianBlurElement
SVGFEImageElement
SVGFEMergeElement
SVGFEMergeNodeElement
SVGFEMorphologyElement
SVGFEOffsetElement
SVGFEPointLightElement
SVGFESpecularLightingElement
SVGFESpotLightElement
SVGFETileElement
SVGFETurbulenceElement
SVGFilterElement
SVGFilterPrimitiveStandardAttributes
SVGFontElement Deprecated
SVGFontFaceElement Deprecated
SVGFontFaceFormatElement Deprecated
SVGFontFaceNameElement Deprecated
SVGFontFaceSrcElement Deprecated
SVGFontFaceUriElement Deprecated
SVGForeignObjectElement
SVGGElement
SVGGeometryElement
SVGGlyphElement Deprecated
SVGGlyphRefElement Deprecated
SVGGradientElement
SVGGraphicsElement
SVGHatchElement Experimental
SVGHatchpathElement Experimental
SVGHKernElement Deprecated
SVGImageElement
SVGLinearGradientElement
SVGLineElement
SVGMarkerElement Experimental
SVGMaskElement
SVGMetadataElement
SVGMissingGlyphElement Deprecated
SVGMPathElement
SVGPathElement
SVGPatternElement
SVGPolylineElement
SVGPolygonElement
SVGRadialGradientElement
SVGRectElement
SVGScriptElement
SVGSetElement
SVGStopElement
SVGStyleElement
SVGSVGElement
SVGSwitchElement
SVGSymbolElement
SVGTextContentElement
SVGTextElement
SVGTextPathElement
SVGTextPositioningElement
SVGTitleElement
SVGTRefElement Deprecated
SVGTSpanElement
SVGUseElement
SVGViewElement
SVGVKernElement Deprecated

SVG data type interfaces

Here are the DOM APIs for data types used in the definitions of SVG properties and attributes.

Static type

SVGAngle
SVGColor Deprecated
SVGICCColor Deprecated
SVGElementInstance
SVGElementInstanceList
SVGLength
SVGLengthList
SVGNameList
SVGNumber
SVGNumberList
SVGPaint
SVGPathSeg Deprecated
SVGPathSegClosePath Deprecated
SVGPathSegMovetoAbs Deprecated
SVGPathSegMovetoRel Deprecated
SVGPathSegLinetoAbs Deprecated
SVGPathSegLinetoRel Deprecated
SVGPathSegCurvetoCubicAbs Deprecated
SVGPathSegCurvetoCubicRel Deprecated
SVGPathSegCurvetoQuadraticAbs Deprecated
SVGPathSegCurvetoQuadraticRel Deprecated
SVGPathSegArcAbs Deprecated
SVGPathSegArcRel Deprecated
SVGPathSegLinetoHorizontalAbs Deprecated
SVGPathSegLinetoHorizontalRel Deprecated
SVGPathSegLinetoVerticalAbs Deprecated
SVGPathSegLinetoVerticalRel Deprecated
SVGPathSegCurvetoCubicSmoothAbs Deprecated
SVGPathSegCurvetoCubicSmoothRel Deprecated
SVGPathSegCurvetoQuadraticSmoothAbs Deprecated
SVGPathSegCurvetoQuadraticSmoothRel Deprecated
SVGPathSegList Deprecated
SVGPoint Deprecated
SVGPointList Deprecated
SVGPreserveAspectRatio
SVGRect Deprecated
SVGStringList
SVGTransform
SVGTransformList

Читайте также: Есть php нужен хостинг

Animated type

SVGAnimatedAngle
SVGAnimatedBoolean
SVGAnimatedEnumeration
SVGAnimatedInteger
SVGAnimatedLength
SVGAnimatedLengthList
SVGAnimatedNumber
SVGAnimatedNumberList
SVGAnimatedPathData Deprecated
SVGAnimatedPoints
SVGAnimatedPreserveAspectRatio
SVGAnimatedRect
SVGAnimatedString
SVGAnimatedTransformList

Other SVG interfaces

GetSVGDocument
ShadowAnimation
SVGColorProfileRule Deprecated
SVGCSSRule Deprecated
SVGDocument
SVGException Deprecated
SVGFitToViewBox
SVGLocatable Deprecated
SVGRenderingIntent Deprecated
SVGUnitTypes
SVGUseElementShadowRoot
SVGViewSpec Deprecated
SVGZoomEvent Deprecated

Specifications

MDN

Support

Our communities

Developers

Visit Mozilla Corporation’s not-for-profit parent, the Mozilla Foundation.
Portions of this content are ©1998– 2023 by individual mozilla.org contributors. Content available under a Creative Commons license.

Источник

Constructing the Object Model

Before the browser can render the page, it needs to construct the DOM and CSSOM trees. As a result, we need to ensure that we deliver both the HTML and CSS to the browser as quickly as possible.

Summary #

Bytes → characters → tokens → nodes → object model.
HTML markup is transformed into a Document Object Model (DOM); CSS markup is transformed into a CSS Object Model (CSSOM).
DOM and CSSOM are independent data structures.
Chrome DevTools Performance panel allows us to capture and inspect the construction and processing costs of DOM and CSSOM.

Document Object Model (DOM) #

<!DOCTYPE html>
html> 
head> 
meta name="viewport" content="width=device-width,initial-scale=1" /> 
link href="style.css" rel="stylesheet" /> 
title>Critical Path</title> 
</head> 
body> 
p>Hello span>web performance</span> students!</p> 
div>img src="awesome-photo.jpg" /></div> 
</body>
</html>

Let’s start with the simplest possible case: a plain HTML page with some text and a single image. How does the browser process this page?

Conversion: The browser reads the raw bytes of HTML off the disk or network, and translates them to individual characters based on specified encoding of the file (for example, UTF-8).
Tokenizing: The browser converts strings of characters into distinct tokens—as specified by the W3C HTML5 standard for example, «&LThtml>», «&LTbody>»—and other strings within angle brackets. Each token has a special meaning and its own set of rules.
Lexing: The emitted tokens are converted into «objects,» which define their properties and rules.
DOM construction: Finally, because the HTML markup defines relationships between different tags (some tags are contained within other tags) the created objects are linked in a tree data structure that also captures the parent-child relationships defined in the original markup: the HTML object is a parent of the body object, the body is a parent of the paragraph object, and so on.

The final output of this entire process is the Document Object Model (DOM) of our simple page, which the browser uses for all further processing of the page.

Every time the browser processes HTML markup, it goes through all of the steps above: convert bytes to characters, identify tokens, convert tokens to nodes, and build the DOM tree. This entire process can take some time, especially if we have a large amount of HTML to process.

We’re assuming that you have basic familiarity with Chrome DevTools — that is, you know how to capture a network waterfall or record a timeline. If you need a quick refresher, check out the Chrome DevTools documentation; if you’re new to DevTools, check out DevTools for Beginners in our DevTools documentation.

If you open up Chrome DevTools and record a timeline while the page is loaded, you can see the actual time taken to perform this step—in the example above, it took us ~5ms to convert a chunk of HTML into a DOM tree. For a larger page, this process could take significantly longer. When creating smooth animations, this can easily become a bottleneck if the browser has to process large amounts of HTML.

The DOM tree captures the properties and relationships of the document markup, but it doesn’t tell us how the element will look when rendered. That’s the responsibility of the CSSOM.

CSS Object Model (CSSOM) #

While the browser was constructing the DOM of our simple page, it encountered a link tag in the head section of the document referencing an external CSS stylesheet: style.css . Anticipating that it needs this resource to render the page, it immediately dispatches a request for this resource, which comes back with the following content:

body  
font-size: 16px;
>
p  
font-weight: bold;
>
span  
color: red;
>
p span  
display: none;
>
img  
float: right;
>

We could have declared our styles directly within the HTML markup (inline), but keeping our CSS independent of HTML allows us to treat content and design as separate concerns: designers can work on CSS, developers can focus on HTML, and so on.

As with HTML, we need to convert the received CSS rules into something that the browser can understand and work with. Hence, we repeat the HTML process, but for CSS instead of HTML:

The CSS bytes are converted into characters, then tokens, then nodes, and finally they are linked into a tree structure known as the «CSS Object Model» (CSSOM):

Why does the CSSOM have a tree structure? When computing the final set of styles for any object on the page, the browser starts with the most general rule applicable to that node (for example, if it is a child of a body element, then all body styles apply) and then recursively refines the computed styles by applying more specific rules; that is, the rules «cascade down.»

To make it more concrete, consider the CSSOM tree above. Any text contained within the &LTspan> tag that is placed within the body element, has a font size of 16 pixels and has red text—the font-size directive cascades down from the body to the span . However, if a span tag is child of a paragraph ( p ) tag, then its contents are not displayed.

Also, note that the above tree is not the complete CSSOM tree and only shows the styles we decided to override in our stylesheet. Every browser provides a default set of styles also known as «user agent styles»—that’s what we see when we don’t provide any of our own—and our styles simply override these defaults.

To find out how long the CSS processing takes you can record a timeline in DevTools and look for «Recalculate Style» event: unlike DOM parsing, the timeline doesn’t show a separate «Parse CSS» entry, and instead captures parsing and CSSOM tree construction, plus the recursive calculation of computed styles under this one event.

Our trivial stylesheet takes ~0.6ms to process and affects eight elements on the page—not much, but once again, not free. However, where did the eight elements come from? The CSSOM and DOM are independent data structures! Turns out, the browser is hiding an important step. Next, lets talk about the render tree that links the DOM and CSSOM together.