The
<model>
element
allows
embedding
3D
graphical
content
inline
within
an
[
HTML
]
document
to
be
managed
declaratively,
and
rendered
directly
by
the
user
agent.
The
HTMLModelElement
interface
then
provides
a
simple
API
for
controlling
the
presentation,
animation,
interaction,
fetching,
and
UI
affordances
of
a
<model>
.
Status
of
This
Document
This
is
a
preview
Do
not
attempt
to
implement
this
version
of
the
specification.
Do
not
reference
this
version
as
authoritative
in
any
way.
Instead,
see
https://immersive-web.github.io/model-element/
for
the
Editor's
draft.
GitHub
Issues
are
preferred
for
discussion
of
this
specification.
1.
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.
1.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.
1.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.
1.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.
Examples
2.1
Loading
and
parsing
A
model
element
whose
source
path
resolves
to
a
valid
resource
dispatch
a
load
event
upon
the
successful
fetching
and
presentation
of
the
resource
data.
If
the
asset
fails
to
load,
for
instance
due
to
an
invalid
URL,
a
failure
to
fetch,
or
a
failure
in
the
source
format's
parsing
process,
the
user
agent
dispatches
an
error
event.
2.2
Processing
model
contents
A
3D
asset
file
contains
positional
data
for
the
surfaces
and
objects
within
it.
Following
the
successful
processing
of
a
model
resource,
the
Model
's
Bounding
box
information
is
conveyed
in
the
boundingBoxCenter
attribute
and
the
boundingBoxExtent
attribute,
both
presented
as
three-
dimensional
DOMPointReadOnly
objects.
If
a
model
does
not
contain
a
valid
resource,
the
attributes
referring
to
the
extent
and
center
of
the
bounding
box
are
null.
Figure
1
Visual
aid
demonstrating
the
center
and
extent
of
an
object's
bounding
box
Note
2.3
Adding
a
model
to
a
document
2.2
2.4
Enabling
interactivity
Issue
20
:
Add
example
showing
enabling
interactivity
Add
an
example
that
shows
how
to
enabling
interactivity.
2.5
Programmatic
view
control
2.3
2.6
Supporting
multiple
formats
Issue
21
:
Add
example
showing
how
to
support
multiple
formats
Having
an
example
that
shows
how
to
support
multiple
formats
via
<source>
would
be
great.
2.4
2.7
Providing
fallback
content
for
legacy
user
agents
Issue
22
:
Add
example
for
providing
fallback
content
for
legacy
user
agents
It
would
be
great
to
show
how
one
can
provide
fallback
content
for
user
agents
that
don't
support
model.
This
could
include
showing
a
<video>
or
<picture>
instead.
2.8
Providing
an
image-based
light
(IBL)
2.5
2.9
Making
model
accessible
Issue
23
:
Add
example
for
making
model
accessible
It
would
be
great
to
have
some
examples
that
shows
how
to
maximize
the
accessibility
of
<model>
.
The
HTMLModelElement
interface
provides
a
means
to
interface
with
the
embedded
resource.
The
model
element
is
used
for
embedding
3D
models
into
a
document.
Content
may
be
provided
inside
the
model
element.
User
agents
should
not
show
this
content
to
the
user;
it
is
intended
for
web
browsers
which
do
not
support
model
,
to
be
shown
as
fallback
content
.
HTML
defines
an
algorithm
to
determine
the
[=poster
frame=],
but
it's
<video>
specific.
Should
we
accommodate
it
support
<model>
or
specify
our
own?
We
also
need
to
consider
what
happens
if
the
animation
resets
and
the
model
is
paused:
does
the
poster
show
again?
(i.e.,
do
we
follow
video's
behavior?)
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.
3.7
loop
attribute
3.8
muted
attribute
3.9
poster
attribute
The
poster
attribute
gives
the
URL
of
an
image
file
that
the
user
agent
can
show
while
3D
content
is
unavailable.
The
attribute,
if
present,
must
contain
a
valid
non-empty
URL
potentially
surrounded
by
spaces
.
As
the
model
can
be
interactive,
it's
foreseeable
that
users
might
place/rotate
a
model
in
such
a
way
that
they
are
unsure
which
direction
the
model
is
facing.
It
might
be
nice
to
provide
some
way
of
resetting
the
camera
to
its
initial
position.
This
is
a
"nice
to
have"
(i.e.,
probably
not
critical)
because
a
developer
could
take
a
snapshot
of
the
camera's
position
when
the
model
loads.
However,
that's
kinda
annoying
because
then
they
need
to
keep
their
own
accounting
of
the
starting
position
of
each
model.
5.
source
element
integration
5.1
The
source
element's
parent
is
a
model
element
Issue
24
:
Specify
the
behavior
for
when
a
<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>
.
6.
Interaction
Issue
2
:
Dealing
with
format
specific
animations
and
Interaction
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.
When
exiting
an
AR
experience
it's
sometimes
useful
to
pass
data
from
the
model
out
back
to
the
page.
On
iOS
[1],
for
instance,
a
"message"
event
is
sent:
Which
then
allows
a
web
page
to
over
and
perform
some
action
through
the
web
page.
In
the
case
above,
it
triggers
Apple
Pay
through
(presumedly)
the
Payment
Request
API.
Obviously,
the
"message"
with
the
custom
.data
"_apple_ar_quicklook_button_tapped..."
is
not
something
we
would
want
to
standardize,
but
it
might
be
good
to
consider
some
kind
of
user
activation
action
resulting
form
the
format
itself
causing
the
scene
to
exit
with
some
action.
The
.data
could
be
an
IDL
object
(or
something
better)
that
could
be
used
to
handle
the
action
(e.g.,
buy
a
thing).
The
proposal
introduces
an
interactive
attribute,
which
would
allow
a
user
to
interact
with
the
model.
We
need
to
specify
what
that
means
to
some
degree,
or
at
least
some
expectations.
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.
8.
Rendering
Issue
1
:
Consistent
presentation/rendering
of
model
resources
I
agree
that
it
is
very
good
to
make
it
easy
for
people
to
display
3D
content
in
a
web
page.
I
completely
disagree
with
the
methods
and
processes
described
in
this
proposal
to
make
it
an
HTML
element.
HTML
elements
need
to
be
fully
defined
so
that
they
can
be
similarly
implemented
across
browsers
and
reflect
what
people
would
see
in
applications
outside
of
browsers.
The
process
of
rendering
a
high-quality
model
requires
proper
handling
and
rendering
of
the
model's
geometry,
appearance,
animation,
and
interaction.
My
knowledge
is
in
glTF
(and
glTF
binary)
so
these
comments
may
or
may
not
reflect
on
the
capabilities
of
USDZ.
I
will
address
the
topics
as
separate
issues:
Appearance
and
Animation
/
interactivity;
with
respect
to
3D
models
in
glTF
format.
Static
geometry
is
pretty
straight-forward
and
not
subject
to
much
interpretation.
The
really
difficult
part
is
appearance.
The
document
states
that
"it
is
impractical
to
define
a
pixel
accurate
rendering..."
for
models.
However,
this
is
really
important.
Khronos
has
done
extensive
work
in
the
3D
Commerce
Working
Group
towards
pixel
accurate
rendering
across
multiple
3D
viewers
(
https://www.khronos.org/3dcommerce/certification/
).
The
accuracy
was
demanded
by
retailers
so
their
products
would
appear
visually
identical
across
different
web
sites.
There
were
so
many
factors
that
mattered
in
producing
acceptable
renderings
that
include
lighting,
rendering
calculations
(including
equation
approximations),
conversion
from
GPU
to
display,
and
tone
mapping.
The
component
that
caused
the
most
issues
and
difficulties
is
lighting.
A
model
built
for
physically-based
rendering
looks
best
in
a
complex
lighting
environment.
This
is
usually
done
with
image
based
lighting,
but
punctual
plus
area
lights
will
also
work.
The
statement
that
"A
future
version
...
will
describe
the
lighting
model
and
environment
....
Both
items
will
require
community
collaboration
and
some
consensus."
makes
the
process
sound
much
easier
that
Khronos
found
it
to
be.
Some
issues
that
came
from
the
Certification
work.
Note
that
the
Certification
program
did
not
solve
all
of
these
in
the
initial
release.
Is
lighting
done
as
an
8-bit
RGB
or
16-bit
HDR
image
Is
lighting
done
with
many
point
and
area
lights?
How
does
the
content
creator
provide
for
different
lighting?
How
does
the
user
adjust
the
lighting
to
match
a
particular
environment?
What
background
is
used
for
the
model
display?
How
is
the
(floating-point)
rendering
converted
to
an
8-bit
RGB
display?
How
is
the
rendering
adjusted
depending
on
user
environment?
How
is
the
rendering
adjusted
depending
on
device
(hardware,
OS,
browser)
How
is
time-dependent
display
degradation
handled?
It
may
be
possible
to
construct
an
initial
release
without
resolving
all
of
these
items.
Issue
5
:
How
would
the
model
display
on
curved
screens?
The
Oculus
browser
is
displayed
on
a
curved
surface.
How
we
envision
the
display
of
multiple
models?
Would
we
allow
them
to
bump
into
each
other
or
would
there
be
clipping?
There
are
cases
where
it
may
not
be
desirable
to
have
a
shadow
being
cast,
because
the
shadow
can
be
larger
than
the
viewport
in
which
an
object
is
being
show.
Also,
as
the
"camera"
rotates,
the
shadow
can
end
up
looking
weird
and
exposing
the
boundary
of
the
<model>
element.
For
example:
It
might
be
good
to
disable
the
shadow
entirely?
Or
some
other
means
for
developers
to
express
where
the
light
source
should
be
to
cast
the
shadow
where
they
might
want.
In
order
for
models
to
be
rendered
appropriately
within
the
context
of
web
document,
it
might
be
useful
to
give
developers
some
means
of
controlling
the
IBL.
For
example,
it
might
not
make
sense
to
use
sunny
environment
light
for
models
sitting
on
a
predominately
dark
document
(and
vice
versa).
There
may
be
some
overlap
here
with
light/dark
mode
in
CSS...
but
not
sure.
As
the
model
can
be
interactive,
it's
foreseeable
that
users
might
place/rotate
a
model
in
such
a
way
that
they
are
unsure
which
direction
the
model
is
facing.
It
might
be
nice
to
provide
some
way
of
resetting
the
camera
to
its
initial
position.
This
is
a
"nice
to
have"
(i.e.,
probably
not
critical)
because
a
developer
could
take
a
snapshot
of
the
camera's
position
when
the
model
loads.
However,
that's
kinda
annoying
because
then
they
need
to
keep
their
own
accounting
of
the
starting
position
of
each
model.
Issue
41
:
Camera
controls
and
requestAnimationFrame()
The
proposal
includes
the
ability
to
change
the
orientation/camera's
view
of
the
model.
However,
it's
unclear
how
that
will
interact
with
requestAnimationFrame()
.
That
is,
do
we
leave
it
to
developers
to
control
how
those
changes
are
interpolated?
or
do
we
just
leave
it
to
the
user
agent
to
perform
the
change
in
position.
There
are
naturally
pro's
and
cons
to
each
approach.
Like,
controlling
the
speed
of
the
translation/transition,
and
the
smoothness
curve
of
the
animation.
Or.
what
if
the
developer
wants
to
just
flip
the
object
without
any
animation?
What's
the
default
CSS
style
for
a
model
element?
Should
it
have
a
border
around
it?
what
about
background
color?
etc.
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.
When
a
model
element
represents
a
poster
frame,
the
poster
frame
is
expected
to
be
rendered
at
the
largest
size
that
maintains
the
aspect
ratio
of
that
poster
frame
without
being
taller
or
wider
than
the
model
element
itself,
and
is
expected
to
be
centered
in
the
model
element.
Like
other
media
and
resources,
model
could
emit
events.
An
obvious
one
being
a
network
error
if
a
resource
can't
load.
We
should
figure
out
what
these
events
might
be,
and
if
model
is
a
media
element
(
#13
),
then
we
should
see
what
applies
in
general
for
media
elements.
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.
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.
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.).
Need
to
clarify
that
3D
resources
can
fetch
resources,
and
as
such
need
to
be
subject
the
document's
CSP
(probably
"media-src").
However,
we
need
to
clarify
what
this
means
in
relation
to,
say,
"img-src",
for
example...
as
models
can
load
png/jpg
textures.
Need
to
describe
that
each
format
will
come
with
its
own
security
considerations
(and
link
to
the
appropriate
security
considerations
in
their
respective
specs).
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).
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.
18.1
Requirements
for
providing
text
to
act
as
an
alternative
for
3D
content
18.2
For
authors
Note
Rules
of
ARIA
attribute
usage
by
HTML
element
([
HTML-ARIA
])
HTML
element
Implicit
ARIA
semantics
ARIA
roles,
states
and
properties
which
MAY
be
used
Need
to
describe
how
we
sniff
for
MIME
types
in
[MIMESNIFF].
See
also
IANA
"
model
"
types.
We
might
need
specific
rules
for
sniffing.
20.
Conformance
As
well
as
sections
marked
as
non-normative,
all
authoring
guidelines,
diagrams,
examples,
and
notes
in
this
specification
are
non-normative.
Everything
else
in
this
specification
is
normative.
The
key
word
MAY
in
this
document
is
to
be
interpreted
as
described
in
BCP
14
[
RFC2119
]
[
RFC8174
]
when,
and
only
when,
they
appear
in
all
capitals,
as
shown
here.
21.
Issue
summary
Issue
20
:
Add
example
showing
enabling
interactivity
Issue
21
:
Add
example
showing
how
to
support
multiple
formats
Issue
22
:
Add
example
for
providing
fallback
content
for
legacy
user
agents
Issue
23
:
Add
example
for
making
model
accessible
