The <model> element

1. Introduction

The HTML model element allows a website to embed interactive 3D models as conveniently as any other visual media. Models are served as a standalone resource. The model element also has support for interaction and animation playback while presented within the page, and supports more spatial experiences, such as the stereoscopic display of 3D content where available.

As model is rendered directly by the user agent, it has the ability to utilize privileged information, such as the user’s head and eye position or the lighting of the user’s environment, without exposing that information to JavaScript. Additionally, the use of accessibility information and controls can be engaged in a privacy-preserving manner.

As model is embedded content, the user agent can present 3D content in a privacy-preserving, interactive, and accessible manner.

2. Out of scope

There are a number of specified non-goals for this initial incubation; some are beyond the long-term scope of this proposal, and others are deferred for the benefit of reaching consensus on an initial specification, which can hopefully serve the needs of users and authors sooner.

2.1. Scene graph inspection and manipulation

While the use cases for inspecting and manipulating the contents of a given model asset are clear, the initial scope of this proposal is intentionally limited to a reduced complexity, hopefully making the initial specification one that has broad consensus amongst the web community.

2.2. Animation mixing and blending

While many popular model formats include the ability to encode, play and mix multiple animations in an animation mixing system, This initial specification considers only a single animation timeline, both for simplicity and for having a minimal viable specification on which the web community can build on.

2.3. Stateful interaction with model contents

While many popular model formats support tapping on a 3D button inside their contents to show or hide additional contents like a title, play an animation or undertake some other stateful action. Because there is no current intention to provide a JavaScript-facing mechanism to be aware of such actions, stateful interactions should be considered out of scope.

2.4. Subresource loading

While many popular model formats support the use of external asset requests for better re-use and consistency, this initial specification will only allow assets that are self-contained.

3. Examples

3.1. Adding a model to a document

<model src="3d-assets/car"></model>

3.2. Enabling orbit stage mode

<model stagemode="orbit">
  <source src="3d-assets/teapot.usdz" type="model/vnd.pixar.usd">
  <source src="3d-assets/teapot.glb" type="model/gltf-binary">
</model>

3.3. Supporting multiple formats

<model>
  <source src="3d-assets/teapot.usdz" type="model/vnd.pixar.usd">
  <source src="3d-assets/teapot.glb" type="model/gltf-binary">
</model>

3.4. Providing fallback content for legacy user agents

<model>
  <source src="3d-assets/teapot.usdz" type="model/vnd.pixar.usd">
  <source src="3d-assets/teapot.glb" type="model/gltf-binary">
  <img src="image-assets/teapot.png">
</model>

3.5. Making model accessible

<model>
  <source src="3d-assets/teapot.usdz" type="model/vnd.usdz+zip">
  <source src="3d-assets/teapot.glb" type="model/gltf-binary">
  <img src="image-assets/teapot.png" alt="A teapot">
</model>

3.6. Providing a loading preview and fallback content

<model src="3d-assets/teapot.usdz" poster="image-assets/teapot-preview.png">
  <picture>
    <source media="(prefers-color-scheme: dark)"
            srcset="image-assets/teapot-dark.avif" type="image/avif">
    <source srcset="image-assets/teapot-light.avif" type="image/avif">
    <img src="image-assets/teapot.png" alt="A ceramic teapot">
  </picture>
</model>

4. The model element

Categories

Flow content.

Phrasing content.

Embedded content.

If the element’s stagemode attribute is set to anything other than none: interactive content.

Palpable content.

Contexts in which this element can be used:

Where embedded content is expected.

Content model:

If the element has a src attribute: transparent, a picture or img, or a media element descendant.

If the element has no src attribute: Zero or more source elements, then transparent, optionally intermixed with script-supporting elements.

Tag omission in text/html:

Neither tag is omissible.

Content Attributes:

Global attributes

autoplay — Start the model’s animation automatically when the resource is loaded

stagemode — Allows the user to interact with the model in a specified mode

crossorigin — Credentials mode for model, environment-map, and poster requests

height — Vertical dimension

loading — Used when determining loading deferral

loop — Whether to loop the media resource

poster — Image preview to show before the model is ready to display

src — Address of the resource

width — Horizontal dimension

DOM Interface

The HTMLModelElement interface provides a means to interface with the embedded resource.

The model element is used for embedding 3D models into a document. Its model-specific APIs, resource processing, and rendering are restricted to secure contexts, as specified in § 17.1 Secure contexts.

Content may be provided inside the model element as fallback content. The element MUST represent this content when model loading is blocked or fails, as specified in § 9.3.2 Poster display. It is also intended for browsers that do not support model. User agents MUST NOT show the fallback content while the model is loading or while available model content is displayed.

4.1. autoplay attribute

The autoplay attribute is a boolean attribute that controls whether the model’s animation starts automatically when a new model resource is loaded. The autoplay IDL attribute MUST reflect the content attribute.

After the initial bounds calculation and fitting for a newly loaded model resource, and before resolving ready, the user agent MUST initialize model animation playback for the element.

After playback has been initialized, adding, removing, or changing autoplay MUST NOT by itself start, pause, or restart the current animation. Its value is used when initializing a subsequently loaded model resource; recreating a renderer for the same resource MUST NOT reapply autoplay in place of the resource’s existing playback state.

Note: Autoplay controls initial animation playback and does not require eager resource loading. A user agent can still defer loading an offscreen model.

4.2. stagemode attribute

4.3. controls attribute

4.4. crossorigin attribute

The crossorigin attribute is a CORS settings attribute. It controls request credentials using HTML’s CORS settings attribute credentials mode, as specified in § 17.2 CORS.

The crossOrigin IDL attribute MUST reflect the crossorigin content attribute, limited to only known values.

4.5. height attribute

The height attribute, if specified, MUST have a value that is a valid non-negative integer. It gives the desired vertical dimension of the model element in CSS pixels. Zero is permitted.

4.6. loading attribute

Some model’s resources can be significant in size. As such, it might be good to support the loading attribute to allow these resources to be lazy-loaded. GitHub issue #44: Lazy loading.

4.7. loop attribute

4.8. poster attribute

The poster attribute gives the URL of an image file that represents the model and is displayed before the model is ready to display. The attribute, if present, MUST contain a valid non-empty URL potentially surrounded by spaces.

Each model element has a poster frame that is an image or null, initially null.

When a model element is created, or its poster attribute is set, changed, or removed, the user agent MUST determine a model poster frame for the element, regardless of whether the poster is currently displayed. A change to the document’s base URL alone MUST NOT restart this algorithm.

Loading or changing a poster image MUST NOT interrupt available model content. The poster’s availability MUST NOT be a condition for resolving ready, and a failure to fetch or decode the poster MUST NOT reject that promise or cause the element to display its fallback content.

The poster IDL attribute MUST reflect the poster content attribute as a URL.

Note: Poster URL parsing, cancellation, and load-event behavior follow the poster-frame retrieval rules for <video> in [HTML]. Request construction follows § 17.2 CORS, and poster display follows § 9.3.2 Poster display. The loading attribute’s lazy-loading behavior remains to be defined in GitHub issue #44.

Like poster, poster accepts a single image URL. Should model loading previews also support alternative formats, resolutions, aspect ratios, or color schemes, or richer placeholders such as another model? A picture in fallback content supports image selection after a model fails, but does not provide a responsive loading poster. See GitHub issue #130: What role, if any, should poster play?.

4.9. src attribute

4.10. width attribute

The width attribute, if specified, MUST have a value that is a valid non-negative integer. It gives the desired horizontal dimension of the model element in CSS pixels. Zero is permitted.

5. The HTMLModelElement interface

[Exposed=Window, SecureContext]
interface HTMLModelElement : HTMLElement {
  [CEReactions, Reflect] attribute boolean autoplay;
  [CEReactions] attribute DOMString? crossOrigin;
  [CEReactions, ReflectURL] attribute USVString poster;

  readonly attribute Promise<HTMLModelElement> ready;
  readonly attribute DOMPointReadOnly boundingBoxCenter;
  readonly attribute DOMPointReadOnly boundingBoxExtents;

  attribute DOMMatrixReadOnly entityTransform;

  attribute USVString environmentMap;
  readonly attribute Promise<undefined> environmentMapReady;

  [Reflect=stagemode] attribute DOMString stageMode;
};

6. source element integration

6.1. The source element’s parent is a model element

The source element behaves differently depending on who the parent is. For instance, when the parent is picture, the srcset attribute comes into to play. We need to look at the attributes of source and figure out what they mean in when used in the context of model. GitHub issue #24: Specify the behavior for when a <source> element’s parent is a <model> element.

7. Interaction

In addition to emitting standard input events, model may interpret input events according to specific stage modes, including none and orbit.

7.1. none

The default value for stageMode. In this this mode, input events do not have any direct action on the behavior of the element.

7.2. orbit

In this mode, input events in a horizontal direction result in a rotation of the model about the Y axis, and events in a vertical direction result in a rotation about the horizontal axis. This is reflected in the model’s entityTransform value.

In this mode, the entityTransform value is read-only.

Setting the mode to orbit results in a change of the position and scale to the orbit fit mode.

glTF is not a run-time format. It does not define what an application should do with a model once it is loaded and rendered. It does provide some capabilities that a run-time engine may use to enhance the user experience. glTF currently does not store any interactivity information. Currently that is solely a run-time determination. The run-time determines what parts (if any) of the model may be active and the behavior based on any trigger. Like Interactivity, animation is not built-into glTF. glTF files may contain animation parameters that specify the type of animation (e.g., morph, skin & bones, etc.) and the associated parameters needed to perform the animation. There is nothing in the glTF specification that defines how one animation interacts with another. For example, a human model may include walk, jump, and drop animations; but it is unlikely that they should all be played at the same time. Any HTML element that wishes to handle animation as stored in a glTF file needs to understand how the content creator intended the animation to play. GitHub issue #2: Dealing with format specific animations and Interaction.

8. Controls

As with other media elements (again #13), having "controls" for media specific things can be extremely helpful for accessibility (and just generally helpful for developers not needing to deal with things like the fullscreen API). It would be nice to consider adding support for controls and then leaving it mostly to the UA as to what those controls are... we could figure out a standard set of things, like video provides. GitHub issue #43: Adding "controls".

9. Rendering

The model SHOULD be rendered according to a realtime, physically-based rendering (PBR) shading model, and lit by an image-based light.

9.1. Environment map

If provided, an environment map MUST be interpreted as an equirectangular environment map. If an environmentMap is not specified, the User Agent MUST provide an appropriate map.

9.2. Model pose

The position, rotation, and scale of a displayed model MUST present its contents according to its entityTransform property, a DOMMatrixReadOnly that can be composed using that object’s existing API.

The point and matrix interfaces and their operations are defined in [GEOMETRY-1].

Each model element has a stored entity transform, initially a DOMMatrixReadOnly representing the identity matrix with is2D set to false.

For the setter steps below, an element’s model renderer is the user agent’s internal instance that manages loading and rendering the element’s model, or retained rendering state used while rendering is suspended. It is null until such an instance is created, and becomes null when that instance and its retained state are discarded. A renderer can exist before ready resolves; its existence does not require the model to be visible.

Updates to the entityTransform SHOULD be reflected on the next rendered frame.

9.2.1. Restrictions on script-assigned transforms

A matrix assigned to entityTransform by script MUST be representable as a composition of scale, rotation, and translation, without shear or perspective. Its scale factors MUST be non-zero and uniform across the X, Y, and Z axes: the scale factors in that decomposition MUST have the same sign and magnitude. All matrix components MUST be finite.

When validating a matrix, the user agent MAY account for floating-point rounding in the scale factors and in reconstructing the matrix from its scale, rotation, and translation. It MUST NOT replace an unsupported matrix with an approximation that discards non-uniform scaling, shear, or perspective.

If the setter throws, the stored entity transform and automatic fitting enabled flag MUST remain unchanged. The model MUST continue to use its previous transform.

These validation requirements apply to script assignments. They do not prevent the user agent’s fitting algorithms from producing a zero scale when an element has a zero-sized viewport, as specified below.

This internal operation does not invoke the entityTransform setter, validate script-assigned transforms, or change the automatic fitting enabled flag. Fitting and user-agent-controlled orbit rotations MUST use this operation to expose their updated transforms. A previously returned DOMMatrixReadOnly remains unchanged when a new transform is stored.

9.2.2. Coordinate spaces and length units

The model APIs distinguish the following coordinate spaces:

model space

The resource’s coordinate space before entityTransform is applied, normalized to a right-handed, Y-up coordinate system. One unit of length in this space represents one meter of the asset’s geometry. Normalization preserves the resource’s origin; fitting does not modify this coordinate space.

element space

The coordinate space of the model element’s content box, as defined in [CSS-BOX-3]. Its origin is the center of the viewport plane, with positive X pointing right, positive Y pointing up, and positive Z pointing toward the viewer. One unit of length in this space is one CSS-derived meter, equal to 100 CSS centimeters. The fixed ratios between absolute length units in [CSS-VALUES-4], 1in = 96px = 2.54cm, give the conversion 1 CSS px = 0.0254 / 96 CSS-derived meters. This specification defines the term "CSS-derived meter"; CSS does not define an m unit.

physical presentation space

The device-dependent space in which the user agent presents the page, including any spatial or stereoscopic presentation. Its mapping from element space may depend on zoom, display characteristics, and the user agent’s presentation policy. The model APIs do not expose this mapping or guarantee a model’s physical size on the device.

The user agent MUST convert the resource’s geometry and internal transform translations to model space using the length units and axis conventions declared by the resource format, including any defaults specified by that format. If the format neither declares nor specifies default length units, one resource length unit MUST be treated as one meter.

The one-meter fallback for formats that neither declare length units nor specify default length units needs further discussion. Is one meter an appropriate default, or should a different fallback be used? See GitHub issue #155.

boundingBoxCenter and boundingBoxExtents MUST report their X, Y, and Z components in meters in model space; the homogeneous W component is dimensionless. These values MUST NOT include automatic fitting, entityTransform, CSS transforms on the element, or the mapping to physical presentation space.

entityTransform MUST map model space to element space. Its translation components are expressed in CSS-derived meters, while scale factors and rotation coefficients are dimensionless. This mapping precedes CSS transforms on the element and the mapping to physical presentation space.

Point transformation uses the transform a point with a matrix algorithm in [GEOMETRY-1]. This specification defines the coordinate spaces and length units used by the model APIs.

For fitting, the user agent MUST convert the content box’s width and height from CSS pixels to CSS-derived meters by multiplying each dimension by 0.0254 / 96. Device pixels MUST NOT be used for this calculation.

Browser zoom in this section refers to page zoom and visual viewport scaling, as distinguished in the Zooming section of [CSSOM-VIEW-1]. Page zoom affects the size of the initial viewport. Visual viewport scaling, exposed by scale, magnifies the page without affecting the initial viewport.

Page zoom and visual viewport scaling MUST NOT change the units defined above or the model-space bounds of a resource. If page zoom changes the layout dimensions used by a fitting algorithm, those dimensions MUST be converted using the same CSS-pixel conversion. This does not change when the fitting algorithms run.

The devicePixelRatio algorithm in [CSSOM-VIEW-1] uses the size of a CSS pixel at the current page zoom, with a visual viewport scale factor of 1.0, divided by the size of a device pixel. Page zoom can therefore change devicePixelRatio; visual viewport scaling is excluded from that calculation. Changes to devicePixelRatio or rasterization resolution MUST NOT change the API units, model-space bounds, or the conversion from CSS pixels to element space.

Note: These distinctions address the default length-unit question raised in GitHub issue #155. A meter of asset geometry and a CSS-derived meter of element space are not guarantees of one physical meter in the device’s presentation. The absolute-unit anchoring rules and reference pixel in [CSS-VALUES-4] explain why CSS physical units need not match physical measurements on a screen. Authors should not multiply element-space translations by devicePixelRatio.

const cssPixelsToMeters = 0.0254 / 96;
const translation = new DOMMatrix().translate(cssPixelsToMeters, 0, 0);
model.entityTransform = translation.multiply(model.entityTransform);

9.2.3. Model bounds and fitting

On the initial load for a model, the user agent MUST run the bounding box calculation algorithm and store the resulting model-space bounds. The stored entity transform MUST be set so that the object is fully in view within the model element’s laid-out content box on the page. Initial fitting uses the model fit algorithm with an identity rotation in none mode, or the orbit fit algorithm in orbit mode.

The fitting algorithms MUST use the width and height of the element’s laid-out content box, converted to CSS-derived meters in element space. These dimensions result from CSS layout, using the used values defined in [CSS-CASCADE-5] and the sizing properties defined in [CSS-SIZING-3]. They are not the numerical values of the width and height attributes. CSS sizing and layout constraints can cause them to differ from the desired dimensions given by those attributes. The bounds remain in model space, before entityTransform is applied. Subsequent fitting updates MUST use the stored bounds of the loaded resource; they MUST NOT repeat the bounding box calculation algorithm or restart or seek the animation.

9.2.4. Automatic fitting after resize

Each model element has an automatic fitting enabled flag, initially true. Beginning to load a new model resource MUST set this flag to true.

The entityTransform setter disables automatic fitting enabled only after a successful script assignment. An internal update made by a fitting algorithm MUST NOT disable automatic fitting.

Entering orbit mode MUST set automatic fitting enabled to true and apply the orbit fit algorithm. Returning from orbit to none MUST preserve the current entityTransform and leave automatic fitting enabled; changing modes back to none does not itself refit the model.

These updates SHOULD be reflected on the next rendered frame. The trigger is a change to the laid-out content-box dimensions, whether caused by width or height attributes, CSS sizing, or another layout change. Changing an attribute without changing those dimensions does not itself trigger a refit.

Note: Given that the entityTransform is determinative of the model’s fit on the page, resetting to the initial pose can be achieved by storing this initial value and re-applying it at any point in the future. In none mode, re-applying that value through script also disables automatic fitting until orbit mode is entered or a new model resource begins loading.

9.2.5. Orbit fit

The orbit fit algorithm is used when the model’s stagemode enters orbit mode and for automatic fitting while that mode is active.

9.3. Embedded content

9.3.1. Replaced-element sizing

For CSS layout, a model element MUST be treated as a replaced element unless it represents fallback content. When it represents fallback content, it MUST be treated as an ordinary element, following HTML’s embedded-content rendering rules for object.

When replaced, its used width and height follow the CSS sizing rules for replaced elements in [CSS2] and [CSS-SIZING-3], with natural dimensions determined below. Its default object size is 300 CSS pixels wide and 150 CSS pixels high, as for video in [HTML]. Object sizing follows CSS Images 3 § 4 Sizing Images and Objects in CSS.

The width and height attributes MUST map to the corresponding CSS dimension properties and to aspect-ratio according to HTML’s dimension-attribute rendering rules for video.

The user agent MUST use determine model natural dimensions when sizing the replaced element. Model geometry, model-space bounds, and entityTransform MUST NOT supply natural CSS dimensions.

Whether a model element is exposing a user interface is not expected to affect the size of the rendering; controls are expected to be overlaid above the page content without causing any layout changes, and may disappear when the user does not need them.

9.3.2. Poster display

For poster display, model content is available when the selected model resource is loaded, processed, and ready to display, the condition used to resolve ready. Beginning to load a new model resource makes the previous resource unavailable for the purposes of these display rules.

A model element MUST represent the content given by the first matching condition below:

1. If model resource loading is permitted is false, one or more model sources were specified but source selection has finished without finding a supported resource, or the selected model resource cannot be loaded or decoded, the element represents its fallback content.

2. Otherwise, if model content is available, the element represents that model content.

3. Otherwise, if its poster frame is not null, the element represents that poster frame.

4. Otherwise, the element represents transparent black with no natural dimensions.

The absence of a model source alone MUST NOT be treated as a load failure for these display rules. A poster can therefore be displayed before a model source is provided.

When the element represents its fallback content, it MUST NOT also display its poster frame. If no fallback content is provided, the element represents nothing. Beginning a new model load MUST re-evaluate these display rules; a failure of a previous load MUST NOT prevent the new load’s poster from displaying.

Pausing, seeking, looping, or resetting a model’s animation MUST NOT, by itself, cause the poster to be displayed again. A paused model MUST continue to display its current pose.

When a model element represents its poster frame, the image is expected to be rendered at the largest size that maintains its aspect ratio without being taller or wider than the model element itself, and is expected to be centered in the model element. The poster MUST NOT affect the model’s bounding box or entityTransform.

Note: The poster is a loading preview, whereas fallback content is an alternative when the model cannot be displayed. A poster failure does not constitute a model failure. Posters are ordinary images; the secure-context restriction on 3D model resources and environment maps does not prevent their retrieval. Their requests remain subject to § 17.2 CORS, § 17.4 Content Security Policy, and the mixed-content checks in [MIX].

10. Events

The environmentMapReady Promise resolves when an environment map resource has been loaded, or is rejected if the resource is unable to be loaded.

The model element emits a ready Promise when the model is processed and ready to display. The Promise is rejected if the model source cannot be loaded.

11. Formats

Need to investigate what formats are suitable for model. We might need some kind of evaluation matrix. Model can support multiple formats out of the box, but it might be good to evaluate what is best of users and developers and why. GitHub issue #18: Which formats?.

12. Overlap with "media elements"

The model element shares a lot of similarities with the audio and video elements, yet it’s distinct in some ways (we need to tease these out). It’s similar in being potentially temporal multimedia content (i.e., it has audio, it potentially animates over time). We need to figure out if model sufficiently different to warrant being its own element class, or if it can reuse much of "media element"'s infrastructure. GitHub issue #13: Is model a "media element"?.

13. HTML Integrations

Additional integrations into HTML:

Need same behavior as audio and video when including into a p element with no end tag. GitHub issue #28: HTML parser integration.

Need to specify that model is an appropriate child of figure. GitHub issue #29: model is an appropriate child of figure.

13.1. Preload link relationship

Need to specify Integration with preload link relationships. GitHub issue #30: Integration with preload.

13.2. Integrations with source element

Some attributes on source are currently restricted to picture. We need to figure out which apply to model.

14. CSS integrations

14.1. Media Playback States (:playing, :paused, :seeking)

If #13 holds, how does the model work with Media Playback States :playing, :paused? GitHub issue #31: CSS integrations: Media Playback States.

14.2. Fullscreen Presentation State: the :fullscreen pseudo-class

15. Fullscreen integration

If #13 holds, how does the model work with Media Playback States :playing, :paused? GitHub issue #31: CSS integrations: Media Playback States.

16. Privacy considerations

We need to investigate what the privacy implications are of each model format we will recommend. The model formats themselves can fetch resources, so we need to put a privacy and security framework around what schemes they can fetch (https only, for instance). We also need to say what all the fetch policies are. Need to investigate if the formats provide any guidance here, or if they leave it up to the implementation. If they do, we need to specify it (i.e., don’t send cookies, don’t leak the referrer, etc.). GitHub issue #36: Formats: privacy considerations.

17. Security considerations

17.1. Secure contexts

For the secure-context checks in this section, model resource loading is permitted for a model element if and only if its node document’s relevant settings object is a secure context. The user agent MUST use the secure context definition in [HTML] to evaluate this condition.

User agents MUST NOT fetch, decode, or render 3D model resources or author-provided environment maps for a model element unless model resource loading is permitted for that element.

Before starting a model or environment-map load for a model element, the user agent MUST check whether model resource loading is permitted for that element. If it is not, the user agent MUST NOT start the load and MUST block model resource loading for the element.

The restriction does not prevent fallback descendants from rendering or loading their own resources under the normal rules for those HTML elements.

The [SecureContext] annotation on HTMLModelElement restricts exposure of the interface and its members according to [WEBIDL]. It does not replace the loading and rendering checks above. In particular, a model created in a secure document MUST NOT continue loading or rendering after being adopted into an insecure document. These checks MUST also be applied before rendering a model.

Requests for model resources and author-provided environment maps MUST follow [FETCH] and be subject to the mixed-content checks in [MIX]. Being in a secure context does not bypass those checks or other applicable resource-loading policies. The secure-context requirement itself is not a scheme whitelist for resource URLs.

Note: Secure contexts normally use HTTPS, but the standard also recognizes potentially trustworthy local origins. For example, http://localhost, http://127.0.0.1, and http://[::1] can qualify without a development certificate. The usual secure-context rules, including ancestor-context checks, still apply. Authors can check isSecureContext rather than inspecting the URL scheme.

17.2. CORS

Model resources, author-provided environment maps, and posters MUST be loaded using Fetch. Each request MUST have mode "cors", client set to the element’s node document’s relevant settings object, credentials mode set to the CORS settings attribute credentials mode of crossorigin, and initiator type "model". This uses Fetch’s CORS protocol; crossorigin controls credentials and does not disable CORS.

Note: This follows the request setup used by HTML module-script fetching and the font-fetching requirements in [CSS-FONTS-4]. Same-origin blob: URLs remain usable, subject to [FETCH] and the document’s CSP.

17.3. Model resource dependencies

As specified in § 2.4 Subresource loading, model resources MUST be self-contained. Parsers and renderers MUST NOT retrieve external dependencies; a model requiring them MUST fail to load. Embedded textures do not cause separate requests and are covered by the model resource’s CSP check.

17.4. Content Security Policy

Model resource requests MUST use destination "model", which this specification adds to the destination type and RequestDestination enumeration in [FETCH]. The Fetch algorithm applies the request client’s CSP as defined by [CSP3]. In CSP’s Get the effective directive for request algorithm, "model" MUST be handled together with "audio", "track", and "video", returning media-src. Environment-map and poster requests MUST use the existing "image" destination and img-src mapping.

17.4.1. Fetch failures

A model or environment-map load that encounters a network error from Fetch MUST reject its own unsettled ready or environmentMapReady promise, respectively, with a TypeError exception. Model failures follow § 9.3.2 Poster display; poster failures follow determine a model poster frame. A failure MUST affect only the load that initiated the request.

17.5. Format concerns

Need to describe that each format will come with its own security considerations (and link to the appropriate security considerations in their respective specs). GitHub issue #17: Format security concerns.

18. Accessibility

We need to figure out how to make model accessible on a number of different fronts: • Visual: describe what is being presented over time. • Interaction: describe what can interacted with (regions, buttons, etc.). • auditory: describe audio and possibly spoke sounds, potentially over time. Usually, this would be provide by the embedded format... however, it appears that both glTF and USDZ are quite limited when it comes to accessibility. As such, it may be that we need to leverage what we can from HTML + ARIA to overcome the shortcomings of these formats. We have quite a bit of precedent (e.g., from the humble, yet limited, alt attribute, to how canvas can be made accessibly, to the potential inclusion of track elements, and so on). GitHub issue #50: Accessibility of model.

We need to define how what the ARIA semantics are and what is exposed (application probably). We need to coordinate with the accessibility folks + get this added to the HTML Accessibility API Mappings. GitHub issue #39: Accessibility: ARIA integration and HTML Accessibility API Mappings.

18.1. Requirements for providing text to act as an alternative for 3D content

18.2. For authors

Note: This section would eventually be moved to [HTML-ARIA].

Rules of ARIA attribute usage by HTML element ([HTML-ARIA])

HTML element

model

Implicit ARIA semantics

TBD

ARIA roles, states and properties which MAY be used

TBD

18.3. For implementers

Note: This section would eventually move to [HTML-AAM-1.0].

model

[wai-aria-1.2]

No corresponding role

MSAA + IAccessible2

Not mapped

UIA

Not mapped

ATK

Not mapped

AX

Not mapped

Comments

19. MIME

We need to check if there are any relevant MIME parameters for model/* content (if any). GitHub issue #37: MIME integration.

19.1. MIME Sniffing

Need to describe how we sniff for MIME types in [MIMESNIFF]. See also IANA "model" types. We might need specific rules for sniffing. GitHub issue #38: Enforce MIME types.