This
specification
defines
a
JSON-based
file
format
that
provides
developers
with
a
centralized
place
to
put
metadata
associated
with
a
web
application.
This
metadata
includes,
but
is
not
limited
to,
the
web
application's
name,
links
to
icons,
as
well
as
the
preferred
URL
to
open
when
a
user
launches
the
web
application.
The
manifest
also
allows
developers
to
declare
a
default
screen
orientation
for
their
web
application,
as
well
as
providing
the
ability
to
set
the
display
mode
for
the
application
(e.g.,
in
fullscreen).
Additionally,
the
manifest
allows
a
developer
to
"scope"
a
web
application
to
a
URL.
This
restricts
the
URLs
to
which
the
manifest
is
applied
and
provides
a
means
to
"deep
link"
into
a
web
application
from
other
applications.
Using
this
metadata,
user
agents
can
provide
developers
with
means
to
create
user
experiences
that
are
more
comparable
to
that
of
a
native
application.
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://w3c.github.io/manifest/
for
the
Editor's
draft.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
standards
and
drafts
index
at
https://www.w3.org/TR/.
Publication
as
an
Editor's
Draft
does
not
imply
endorsement
by
W3C
and
its
Members.
This
is
a
draft
document
and
may
be
updated,
replaced,
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
The
example
also
shows
how
to
use
the
link
type
"manifest"
and
how
to
use
other
meta
and
link
elements
to
give
the
web
application
a
fallback
name
and
set
of
icons.
This
section
illustrates
how
to
declare
multiple
icons
using
the
icons
member
to
declare
a
set
of
icons
for
a
web
application.
In
the
following
example,
the
developer
has
made
the
following
choices
about
the
icons
associated
with
the
web
application:
The
developer
has
included
two
icons
at
the
same
size,
but
in
two
different
formats.
One
is
explicitly
marked
as
WebP
through
the
type
member.
If
the
user
agent
doesn't
support
WebP,
it
can
fall
back
to
the
second
icon
of
the
same
size.
The
MIME
type
of
this
icon
can
then
be
either
determined
via
a
HTTP
header,
or
can
be
sniffed
by
the
user
agent
once
the
first
few
bytes
of
the
icon
are
received.
The
developer
specifies
various
sizes
for
the
pixel-based
icon
formats
(e.g.,
a
PNG
file).
These
sizes
serve
as
hints
for
the
user
agent
to
determine
a
suitable
icon
to
use
in
a
particular
context
(e.g.,
on
the
home
screen
of
a
device).
The
developer
has
also
included
an
ICO
file
(e.g.,
hd_hi.ico),
which
includes
a
range
of
raster
icons
individually
tailored
for
particular
display
sizes.
For
example,
it's
often
not
suitable
to
simply
downscale
a
256x256
image
to
display
in
a
16x16
context,
as
the
image
will
lose
significant
detail.
Instead,
an
entirely
different
image
specifically
tailored
for
a
16x16
pixel
context
will
often
be
used.
Additionally,
they
added
an
SVG
icon
that
can
be
resized
dynamically
to
fit
any
icon
size
needed,
but
the
tradeoff
being
that
it
can
become
unsuitable
in
some
context
(e.g.,
it
becomes
too
small
and
blurry).
The
list
of
icons
is
provided
to
the
user
agent,
which
will
choose
the
most
suitable
icons
for
different
contexts
and
placements.
In
the
following
example,
the
developer
has
included
two
shortcuts.
Assuming
the
manifest's
URL
is
https://example.com/manifest.webmanifest
:
The
first
shortcut
would
be
displayed
with
the
text
"Play
Later".
If
the
operating
system
supports
icons
for
context
menu
items
and
it
also
supports
SVG
images
for
that
purpose,
the
user
agent
would
present
https://example.com/icons/play-later.svg
next
to
the
text.
When
launched,
the
user
agent
would
instantiate
a
new
top-level
browsing
context
and
navigate
to
https://example.com/play-later
.
The
second
shortcut
would
be
displayed
with
the
text
"Subscriptions".
When
launched,
the
user
agent
would
instantiate
a
new
top-level
browsing
context
and
navigate
to
https://example.com/subscriptions?sort=desc
.
{"shortcuts":[{"name":"Play Later","description":"View the list of podcasts you saved for later","url":"/play-later","icons":[{"src":"/icons/play-later.svg","type":"image/svg+xml"}]},{"name":"Subscriptions","description":"View the list of podcasts you listen to","url":"/subscriptions?sort=desc"}]
}
1.1.5
Understanding
"scope"
This
section
is
non-normative.
The
scope
member
tells
the
browser
which
documents
are
part
of
a
web
application,
and
which
are
not
-
and
hence,
to
which
set
of
web
pages
the
manifest
is
"
applied
"
when
the
user
navigates
around
a
web
site.
For
example,
{"scope":
"/"}
means
that
the
manifest
applies
to
every
document
in
an
origin.
On
the
other
hand,
{"scope":
"/racer/"}
means
that
only
documents
within
the
path
"/racer/"
are
within
scope
:
so
"/racer/race1.html",
"/racer/race2.html",
etc.
would
all
be
within
scope
,
but
"/elsewhere/"
and
anything
at
the
root
"/"
would
be
"out
of
scope"
and
the
manifest
wouldn't
apply
to
documents
in
those
paths.
Only
one
scope
path
is
supported.
See
5.
Navigation
scope
for
the
technical
details.
Applying
a
manifest
means
that
any
members
that
affect
presentation
found
in
the
manifest
will
come
into
effect,
such
as
display
"fullscreen",
or
applying
a
particular
screen
orientation.
As
long
as
the
application
is
navigated
to
URLs
that
are
within
scope
,
the
browser
will
continue
to
apply
the
manifest.
However,
navigating
the
web
applications
"out
of
scope"
will
cause
the
manifest
to
no
longer
be
applied,
and
the
browser
will
apply
its
own
defaults.
This
will
cause,
for
example,
the
application
to
no
longer
be
displayed
in
fullscreen,
and
instead
be
displayed
as
a
regular
web
page
in
a
browser
tab.
It's
left
up
to
implementers
to
decide
how
to
deal
with
web
pages
being
navigated
in
and
out
of
scope.
See
1.16.5
Applying
the
manifest
for
the
technical
details.
Finally,
as
it's
possible
that
a
user
can
install
a
web
application
from
any
document
within
an
origin,
it's
good
practice
to
always
declare
a
scope
member
in
a
manifest.
If
the
scope
member
is
missing
from
the
manifest,
then
the
path
of
the
start_url
member
is
used
as
a
fallback.
And
if
the
start_url
member
is
also
missing,
then
the
document
URL
from
which
the
web
application
is
installed
gets
used
as
the
scope.
To
avoid
any
unexpected
navigation
behavior,
authors
should
always
include
a
scope
member
preferably
set
to
"/"
.
The
text-directions
are
the
following,
implying
that
the
value
of
the
localizable
members
is
by
default:
"
ltr
"
Left-to-right
text.
"
rtl
"
Right-to-left
text.
"
auto
"
(default)
Text
direction
is
unknown.
The
user
agent
should
use
heuristics
to
estimate
the
display
of
the
text,
for
example
the
first-strong
algorithm
as
described
in
[
UAX9
].
The
manifest's
lang
member
is
a
string
in
the
form
of
a
language
tag
that
specifies
the
language
for
the
values
of
the
manifest's
localizable
members
.
If
the
lang
member
is
not
specified,
the
language
is
treated
as
unknown.
Note
Specifying
the
language
improves
the
user
experience
by
helping
user
agents
select
the
most
appropriate
processing
or
resources,
such
as
fonts,
styling,
hyphenation,
or
text-to-speech
voices
for
accessibility.
A
language
tag
is
a
string
that
matches
the
production
of
a
well-formed
Language-Tag
defined
in
[
BCP47
].
Note
Language
tags
are
case-insensitive.
Examples
of
language
tags
include
'
fr
'
(French),
'
en-AU
'
(English
as
spoken
in
Australia),
or
'
zh-Hans-CN
'
(Chinese
as
written
in
the
Simplified
Han
script
as
spoken
in
China).
The
manifest's
name
member
is
a
string
that
represents
the
name
of
the
web
application
as
it
is
usually
displayed
to
the
user
(e.g.,
amongst
a
list
of
other
applications,
or
as
a
label
for
an
icon).
The
manifest's
short_name
member
is
a
string
that
represents
a
short
version
of
the
name
of
the
web
application.
It
is
intended
to
be
used
where
there
is
insufficient
space
to
display
the
full
name
of
the
web
application.
If
manifest
["start_url"]
is
not
within
scope
of
scope
,
return.
Otherwise,
set
manifest
["scope"]
to
scope
.
1.7
icons
member
The
manifest's
icons
member
are
images
that
serve
as
iconic
representations
of
the
web
application
in
various
contexts.
For
example,
they
can
be
used
to
represent
the
web
application
amongst
a
list
of
other
applications,
or
to
integrate
the
web
application
with
an
OS
's
task
switcher
and/or
system
preferences.
The
manifest's
orientation
member
is
a
string
that
serves
as
the
default
screen
orientation
for
all
top-level
browsing
contexts
of
the
web
application.
The
possible
values
are
those
of
the
OrientationLockType
enum,
which
in
this
specification
are
referred
to
as
the
orientation
values
(i.e.,
"any",
"natural",
"landscape",
"portrait",
"portrait-primary",
"portrait-secondary",
"landscape-primary",
or
"landscape-secondary").
Certain
UI/UX
concerns
and/or
platform
conventions
will
mean
that
some
screen
orientations
and
cannot
be
used
together
.
Which
orientations
and
display
modes
cannot
be
used
together
is
left
to
the
discretion
of
implementers.
For
example,
for
some
user
agents,
it
might
not
make
sense
to
change
the
default
screen
orientation
of
an
application
while
in
browser
display
mode
.
Set
manifest
["orientation"]
to
json
["orientation"].
1.10
start_url
member
The
manifest's
start_url
member
is
a
string
that
represents
the
start
URL
,
which
is
URL
that
the
developer
would
prefer
the
user
agent
load
when
the
user
launches
the
web
application
(e.g.,
when
the
user
clicks
on
the
icon
of
the
web
application
from
a
device's
application
menu
or
homescreen).
The
start_url
member
is
purely
advisory,
and
a
user
agent
MAY
ignore
it
or
provide
the
end-user
the
choice
not
to
make
use
of
it.
A
user
agent
MAY
also
allow
the
end-user
to
modify
the
URL
when,
for
instance,
a
bookmark
for
the
web
application
is
being
created
or
any
time
thereafter.
It's
conceivable
that
the
start_url
could
be
crafted
to
indicate
that
the
application
was
launched
from
outside
the
browser
(e.g.,
"start_url":
"index.html?launcher=homescreen"
).
This
can
be
useful
for
analytics
and
possibly
other
customizations.
However,
it
is
also
conceivable
that
developers
could
encode
strings
into
the
start_url
that
uniquely
identify
the
user
(e.g.,
a
server-assigned
identifier,
such
as
"?user=123"
,
"/user/123/"
,
or
"https://user123.foo.bar"
).
This
is
fingerprinting/privacy
sensitive
information
that
the
user
might
not
be
aware
of.
Note
:
Don't
add
identifiers
to
start
URLs
It
is
bad
practice
for
a
developer
to
use
the
start
URL
to
include
information
that
uniquely
identifies
a
user,
as
it
would
represent
a
fingerprint
that
is
not
cleared
when
the
user
clears
site
data.
However,
nothing
in
this
specification
can
practically
prevent
developers
from
doing
this.
Given
the
above,
it
is
RECOMMENDED
that,
upon
installation,
or
any
time
thereafter,
a
user
agent
allows
the
user
to
inspect
and,
if
necessary,
modify
the
start
URL
of
an
application.
A
user
agent
MAY
offer
other
protections
against
this
form
of
fingerprinting.
For
example,
if
a
user
clears
data
from
an
origin,
the
user
agent
MAY
offer
to
uninstall
applications
that
are
within
scope
of
that
origin,
thus
removing
the
potential
fingerprint
from
the
application's
start
URL.
1.11
id
member
The
manifest's
id
member
is
a
string
that
represents
the
identity
for
the
application.
The
identity
takes
the
form
of
a
URL,
which
is
same
origin
as
the
start
URL
.
The
identity
is
used
by
user
agents
to
uniquely
identify
the
application
universally.
When
the
user
agent
sees
a
manifest
with
an
identity
that
does
not
correspond
to
an
already-installed
application,
it
SHOULD
treat
that
manifest
as
a
description
of
a
distinct
application,
even
if
it
is
served
from
the
same
URL
as
that
of
another
application.
When
the
user
agent
sees
a
manifest
where
manifest
["id"]
is
equal
(with
exclude
fragments
OPTIONALLY
set
to
true)
to
the
identity
of
an
already-installed
application,
it
SHOULD
be
used
as
a
signal
that
this
manifest
is
a
replacement
for
the
already-installed
application's
manifest,
and
not
a
distinct
application,
even
if
it
is
served
from
a
different
URL
than
the
one
seen
previously.
Note
:
Excluding
fragments
is
best
practice
Note
The
identity
can
be
used
by
a
service
that
collects
lists
of
web
applications
to
uniquely
identify
applications.
Note
The
identity
is
processed
like
a
URL
but
it
doesn't
point
to
a
resource
that
can
be
navigated
to,
so
it's
not
required
to
be
within
scope
.
The
manifest's
background_color
member
describes
the
expected
background
color
of
the
web
application.
It
repeats
what
is
already
available
in
the
application
stylesheet
but
can
be
used
by
the
user
agent
to
draw
the
background
color
of
a
web
application
for
which
the
manifest
is
known
before
the
files
are
actually
available,
whether
they
are
fetched
from
the
network
or
retrieved
from
disk.
The
background_color
member
is
only
meant
to
improve
the
user
experience
while
a
web
application
is
loading
and
MUST
NOT
be
used
by
the
user
agent
as
the
background
color
when
the
web
application's
stylesheet
is
available.
A
user
agent
SHOULD
expose
shortcuts
via
interactions
that
are
consistent
with
exposure
of
an
application
icon's
context
menu
in
the
host
operating
system
(e.g.,
right
click,
long
press).
A
user
agent
SHOULD
render
the
shortcuts
in
the
same
order
as
they
are
provided
in
the
manifest.
A
user
agent
SHOULD
represent
the
shortcuts
in
a
manner
consistent
with
exposure
of
an
application
icon's
context
menu
in
the
host
operating
system.
A
user
agent
MAY
truncate
the
list
of
shortcuts
presented
in
order
to
remain
consistent
with
the
conventions
or
limitations
of
the
host
operating
system.
1.15
*_localized
members
A
localizable
member
is
a
manifest
member
that
can
be
localized.
Each
localizable
member
of
the
manifest
has
a
corresponding
*_localized
member,
where
*
represents
the
member
name.
A
user
agent
MUST
support
the
link
type
"manifest"
and
the
associated
steps
for
how
to
fetch
and
process
the
linked
resource.
1.16.1
Processing
the
manifest
When
instructed
to
ignore
,
the
user
agent
MUST
act
as
if
whatever
manifest,
member,
or
value
caused
the
condition
is
absent.
The
following
algorithm
provides
an
processing
extension-point
:
other
specifications
that
add
new
members
to
the
manifest
are
encouraged
to
hook
themselves
into
this
specification
at
this
point
in
the
algorithm.
They
SHOULD
NOT
modify
the
existing
values
already
in
the
manifest
object.
The
steps
for
processing
a
manifest
are
given
by
the
following
algorithm.
The
algorithm
takes
a
URL
document
URL
,
a
URL
manifest
URL
,
and
a
byte
sequence
bodyBytes
.
Only
sRGB
colors,
and
colors
the
user
agent
can
convert
to
sRGB
without
any
outside
knowledge
(e.g.,
"AliceBlue"
),
are
supported.
For
example,
lab(…)
or
color(display-p3,
…)
can
be
converted
to
sRGB
without
outside
knowledge,
but
color(--custom-profile,
…)
would
require
finding
a
matching
"@color-profile"
rule
which
cannot
be
specified
in
the
manifest.
The
processing
a
manifest
steps
are
invoked
by
[
HTML
]'s
processing
steps
for
the
link
element,
but
MAY
also
be
invoked
by
the
user
agent
to
process
a
manifest
without
an
associated
document
.
In
this
case,
to
match
the
guarantees
made
by
the
corresponding
steps
in
[
HTML
],
the
user
agent
SHOULD
ensure
that
at
least
at
some
point
in
the
past:
As
specified
for
manifest
link
relation,
the
manifest
is
fetched
and
processed
on
every
page
load.
When
the
processing
a
manifest
is
successful,
user
agents
MAY
apply
updated
manifest
to
any
current
and
future
application
contexts
associated
with
the
application.
For
the
purpose
of
updating,
the
following
member
are
security-sensitive
members
,
as
they
are
presented
during
installation
and
on
launch
surfaces:
short_name
and
localized
representations
in
short_name_localized
,
icons
and
localized
representations
in
icons_localized
,
name
and
localized
representations
in
name_localized
.
Instead,
user
agents
SHOULD
present
changes
to
security-sensitive
members
with
appropriate
management
options,
so
the
user
can
make
an
informed
decision
about
updating
the
web
application.
The
user
agent
MAY
automatically
apply
the
changes
if
the
update
does
not
contain
changes
to
security-sensitive
members
.
If
a
user
changes
localization
settings,
the
user
agent
MAY
automatically
adjust
the
security-sensitive
members
visible
on
launch
surfaces
to
their
localized
representations
specified
in
the
*_localized
members.
These
changes
SHOULD
be
presented
to
users
the
next
time
they
open
the
web
application.
Note
:
A
user
agent
will
not
apply
a
partial
update
2.
Manifest
image
resources
Each
manifest
image
resource
is
an
image
resource
that
is
conceptually
part
of
a
web
application,
suitable
to
use
.
The
context
in
various
contexts
depending
on
which
an
manifest
image
resource
is
presented
is
determnined
by
the
semantics
of
the
associated
manifest
member
that
is
using
the
object
(e.g.,
an
icon
that
icons
member
is
part
of
an
generally
used
to
represent
the
application
menu,
etc.).
icon).
User
agents
MAY
modify
the
images
associated
with
an
a
manifest
image
resource
to
better
match
the
platform’s
platform's
visual
style
before
displaying
it
to
the
user,
for
example
by
rounding
the
corners
or
painting
it
in
a
specific
color.
It
is
recommended
that
developers
prepare
their
image
resources
for
such
scenarios
to
avoid
losing
important
information
through,
e.g.,
change
of
color
or
clipped
corners.
When
a
manifest
image
resource
is
used
as
an
icon
,
a
developer
can
hint
that
the
image
is
intended
to
serve
some
special
purpose
in
the
context
of
the
host
OS
(i.e.,
for
better
integration).
User
agents
SHOULD
NOT
use
an
icon
other
than
for
its
stated
icon
purpose
.
Note
For
example,
an
icon
with
purpose
"
monochrome
"
could
be
used
as
a
badge
or
pinned
icon
with
a
solid
fill,
visually
distinct
from
an
application's
full
color
launch
icon.
The
user
agent
uses
the
value
of
the
purpose
member
as
a
hint
to
determine
where
and
how
an
purpose
is
displayed.
Unless
declared
otherwise
by
the
developer,
a
user
agent
can
use
an
icon
for
any
purpose
.
The
icon
purposes
are
as
follows:
monochrome
A
user
agent
can
present
this
icon
where
a
monochrome
icon
with
a
solid
fill
is
needed.
The
color
information
in
the
icon
is
discarded
and
only
the
alpha
data
is
used.
The
icon
can
then
be
used
by
the
user
agent
like
a
mask
over
any
solid
fill.
maskable
The
image
is
designed
with
icon
masks
and
safe
zone
in
mind,
such
that
any
part
of
the
image
that
is
outside
the
safe
zone
can
safely
be
ignored
and
masked
away
by
the
user
agent.
any
(default)
The
user
agent
is
free
to
display
the
icon
where
no
purpose
is
required.
For
example,
a
manifest
image
resource
with
a
"any"
purpose
wouldn't
be
used
in
a
context
where
"
monochrome
"
is
required.
If
an
icon
contains
multiple
purposes,
it
could
be
used
for
any
of
those
purposes.
If
none
of
the
stated
purposes
are
recognized,
the
icon
is
totally
ignored.
For
example,
if
an
icon
has
purpose
"monochrome
fizzbuzz"
,
then
it
could
be
used
as
a
monochrome
icon,
as
"monochrome"
is
a
valid
purpose.
However,
if
an
icon
just
has
the
purpose
"fizzbuzz"
,
then
it
will
be
ignored.
To
determine
the
purpose
of
an
image
,
given
ordered
map
json
:
If
json
["purpose"]
doesn't
exist
or
if
json
["purpose"]
is
not
a
string
:
2.2
Content
security
policy
The
security
policy
that
governs
whether
a
user
agent
can
fetch
an
icon
image
is
governed
by
the
img-src
directive
[
CSP3
]
associated
with
the
manifest's
owner
Document
.
Example
11
:
Content
security
policy
of
icons
For
example,
given
the
following
img-src
directive
in
the
Content-Security-Policy
HTTP
header
of
the
manifest's
owner
Document
:
OK
text/html
img-src icons.example.com
<
link
rel
=
"manifest"
href
=
"manifest.webmanifest"
>
And
given
the
following
manifest.webmanifest
:
}
The
fetching
of
icon
resources
from
icons.example.com/lowres
would
succeed,
while
fetching
from
other.com/hi-res
would
fail.
2.3
2.2
Icon
masks
and
safe
zone
Some
platforms
have
their
own
preferred
icon
shape,
but
as
web
applications
should
work
across
multiple
platforms,
it
is
possible
to
indicate
that
an
icon
can
have
a
user-agent-specified
mask
applied
by
adding
the
maskable
purpose.
This
allows
the
platform
to
ensure
that
the
icon
looks
well
integrated
with
the
platform,
and
even
apply
different
masks
and
background
colors
in
different
places
throughout
the
platform.
The
safe
zone
is
the
area
within
a
maskable
icon
which
is
guaranteed
to
always
be
visible,
regardless
of
user
agent
preferences.
It
is
defined
as
a
circle
with
center
point
in
the
center
of
the
icon
and
with
a
radius
of
2/5
(40%)
of
the
icon
size,
which
means
the
smaller
of
the
icon
width
and
height,
in
case
the
icon
is
not
square.
Note
Designers
of
maskable
icons
will
want
to
make
sure
that
all
important
parts
are
within
the
safe
zone
.
Figure
1
The
safe
zone
is
a
centrally
positioned
circle,
with
radius
2/5
(40%)
of
the
minimum
of
the
icon's
width
and
height.
All
pixels
in
this
zone
are
guaranteed
to
be
seen
in
all
masks.
Pixels
outside
the
safe
zone
are
not
guaranteed
to
(but
can)
be
visible
depending
on
the
applied
mask.
The
user
agent
MAY
apply
a
mask
of
any
size,
making
any
pixels
that
are
more
than
2/5ths
of
the
image
size
(minimum
of
width
and
height
if
non-square)
away
from
the
center
(the
safe
zone
)
transparent.
The
user
agent
MUST
NOT
make
any
pixel
within
the
safe
zone
transparent.
The
user
agent
MAY
enlarge
the
icon
by
adding
additional
padding.
If
the
icon
contains
transparent
pixels,
the
user
agent
MUST
composite
the
icon
onto
a
solid
fill
(e.g.,
white)
of
the
user
agent's
choice.
Note
It
is
suggested
that
designers
avoid
using
transparent
pixels
in
maskable
icons.
2.3.1
2.2.1
Examples
of
masks
Note
By
staying
inside
the
safe
zone
,
most
icons
will
have
around
10%
padding
on
the
top,
bottom,
right
and
left
with
no
content
or
non-essential
content,
such
as
an
icon
background.
It
is
suggested
that
developers
check
their
icon
when
all
but
the
safe
zone
is
masked
out.
2.3.1.1
2.2.1.1
Icons
with
"maskable"
purpose
Figure
2
Image
The
base
image
with
transparent
background
Figure
3
Safe
zone
Circle
with
radius
2/5
(40%)
of
the
icon
size
Some
platforms
enforce
that
icons
be
displayed
with
a
solid
fill
such
as
a
single
color,
where
only
the
transparency
of
the
icon
can
be
declared
in
a
manifest
.
As
web
applications
need
to
work
across
multiple
platforms,
it
is
possible
to
indicate
that
an
icon
can
have
an
user-agent-specified
color
applied
by
adding
the
monochrome
purpose.
This
allows
the
platform
to
ensure
that
the
icon
looks
well
integrated
with
the
platform,
and
even
apply
different
colors
and
padding
in
different
places
throughout
the
platform.
When
presenting
a
monochrome
icon,
the
user
agent
MUST
NOT
independently
display
the
red
component,
green
component,
or
blue
component
of
a
pixel.
The
user
agent
SHOULD
display
each
pixel
with
its
original
alpha
value,
but
with
a
red,
green,
and
blue
value
of
the
user
agent's
choosing.
It
is
RECOMMENDED
that
the
user
agent
use
the
same
color
value
for
all
pixels.
Note
Designers
of
monochrome
icons
could
set
all
pixels
to
black
and
only
use
transparency
to
create
a
silhouette
of
their
icon.
The
user
agent
MAY
enlarge
the
icon
by
adding
additional
padding.
The
user
agent
MAY
add
a
background
of
any
color
behind
transparent
pixels,
and
SHOULD
ensure
that
the
background
has
sufficient
contrast
with
the
icon.
2.4.1
2.3.1
Example
usage
of
monochrome
icons
2.4.1.1
2.3.1.1
Usage
examples
Figure
9
Image
The
base
image
with
no
color.
Figure
10
Gradient
fill
The
image
filled
in
with
a
gradient.
Figure
11
Solid
color
fill
with
padding
Filled
in
with
the
theme
color
from
the
manifest.
A
user
agent
can
use
these
members
to
assemble
a
context
menu
to
be
displayed
by
the
operating
system
when
a
user
engages
with
the
web
app's
icon.
When
the
user
invokes
a
shortcut
from
the
operating
system
menu,
the
user
agent
SHOULD
run
launching
a
shortcut
.
3.1
name
member
The
shortcut
item's
name
member
is
a
string
that
represents
the
name
of
the
shortcut
as
it
is
usually
displayed
to
the
user
in
a
context
menu.
The
shortcut
item's
short_name
member
is
a
string
that
represents
a
short
version
of
the
name
of
the
shortcut.
It
is
intended
to
be
used
where
there
is
insufficient
space
to
display
the
full
name
of
the
shortcut.
The
shortcut
item's
description
member
is
a
string
that
allows
the
developer
to
describe
the
purpose
of
the
shortcut.
User
agents
MAY
expose
this
information
to
assistive
technology.
A
user
agent
can
provide
a
way
for
the
end-user
to
install
a
web
application
on
the
end-user's
device,
allowing
the
user
to
instantiate
a
new
top-level
browsing
context
with
the
manifest's
members
applied
.
Once
a
web
application
is
installed
it
is
known
as
a
installed
web
application
:
That
is,
the
manifest's
members,
or
their
defaults,
are
applied
to
the
top-level
browsing
context
of
the
web
application.
This
distinguishes
an
installed
web
application
from
a
traditional
bookmark,
as
opening
a
web
page
from
a
traditional
bookmark
will
not
have
the
manifest's
properties
applied
to
it.
Note
For
example,
on
user
agents
that
support
installation,
a
web
application
could
be
presented
and
launched
in
a
way
that,
to
the
end-user,
is
indistinguishable
from
native
applications:
such
as
appearing
as
a
labeled
icon
on
the
home
screen,
launcher,
or
start
menu.
When
launching
a
web
application
,
the
manifest
is
applied
by
the
user
agent
to
the
top-level
browsing
context
prior
to
the
start
URL
being
loaded.
This
gives
the
user
agent
an
opportunity
to
apply
the
relevant
values
of
the
manifest,
possibly
changing
the
display
mode
and
screen
orientation
of
the
web
application.
Alternatively,
and
again
as
an
example,
the
user
agent
could
install
the
web
application
into
a
list
of
bookmarks
within
the
user
agent
itself.
4.1
Application's
name
The
application's
name
is
derived
from
either
the
name
member
or
short_name
member.
The
user
agent
SHOULD
first
resolve
the
localized
values
from
their
corresponding
*_localized
members.
When
either
the
name
member
or
the
short_name
member
is
missing,
empty,
or
the
wrong
type,
a
user
agent
MAY
use
the
name
member
as
a
fallback
for
the
short_name
member
or
short_name
member
as
the
fallback
for
the
name
member.
If
the
name
and
short_name
members
are
missing,
empty,
or
the
wrong
type,
a
user
agent
MAY
fallback
to
the
Document
to
find
suitable
replacements
for
missing
manifest
members
(e.g.,
using
application-name
in
place
of
name
or
short_name
).
Alternatively,
the
user
agent
SHOULD
assign
a
default
name
(e.g.,
"Untitled")
that
follows
platform
conventions.
Alternatively,
a
user
agent
MAY
allow
the
end-user
to
input
some
text
that
can
serve
as
the
application's
name
.
When
both
the
name
and
short_name
members
are
present,
it
is
left
up
to
implementations
to
decide
which
member
is
best
suited
for
the
space
available
(e.g.,
the
short_name
member
might
be
better
suited
for
the
space
available
underneath
an
icon).
This
would
typically
take
place
when
the
user
selects
an
installed
web
app
from
an
app
launching
UI
surface
e.g.,
a
home
screen,
launcher
or
start
menu.
target
URL
,
if
given,
MUST
be
within
scope
of
manifest
.
Other
specifications
MAY
replace
this
algorithm's
steps
with
their
own
steps.
This
replacement
will
take
effect
for
all
invocations
of
launch
a
web
application
.
Note
This
algorithm
is
replaceable
to
allow
an
experimental
launch_handler
manifest
field
to
configure
the
behavior
of
all
web
application
launches.
The
replacement
algorithm
invokes
create
a
new
application
context
by
default
but
under
certain
conditions
behaves
differently.
It
is
RECOMMENDED
that
UI
that
affords
the
end
user
the
ability
to
install
a
web
application
also
allows
inspecting
the
icon,
name,
start
URL
,
origin,
etc.
pertaining
to
a
web
application.
This
is
to
give
an
end-user
an
opportunity
to
make
a
conscious
decision
to
approve,
and
possibly
modify,
the
information
pertaining
to
the
web
application
before
installing
it.
This
also
gives
the
end-user
an
opportunity
to
discern
if
the
web
application
is
spoofing
another
web
application,
by,
for
example,
using
an
unexpected
icon
or
name.
It
is
RECOMMENDED
that
user
agents
prevent
other
applications
from
determining
which
applications
are
installed
on
the
system
(e.g.,
via
a
timing
attack
on
the
user
agent's
cache).
This
could
be
done
by,
for
example,
invalidating
from
the
user
agent's
cache
the
resources
linked
to
from
the
manifest
(for
example,
icons)
after
a
web
application
is
installed
-
or
by
using
an
entirely
different
cache
from
that
used
for
regular
web
browsing.
It
is
RECOMMENDED
that
at
the
time
of
removal,
the
user
agent
also
present
the
user
with
an
opportunity
to
revoke
other
persistent
data
and
settings
associated
with
the
application,
such
as
permissions
and
persistent
storage.
If
the
scope
member
is
not
present
in
the
manifest,
it
defaults
to
the
parent
path
of
the
start_url
member.
For
example,
if
start_url
is
/pages/welcome.html
,
and
scope
is
missing,
the
navigation
scope
will
be
/pages/
on
the
same
origin.
If
start_url
is
/pages/
(the
trailing
slash
is
important!),
the
navigation
scope
will
be
/pages/
.
Developers
should
take
care,
if
they
rely
on
the
default
behavior,
that
all
of
the
application's
page
URLs
begin
with
the
parent
path
of
the
start
URL.
To
be
safe,
explicitly
specify
scope
.
A
URL
target
is
said
to
be
within
scope
of
URL
scope
if
the
following
algorithm
returns
true
:
If
target
and
scope
are
not
same
origin
,
return
false
.
Let
scopePath
be
the
concatenation
of
scopes
's
path
using
U+002F
(/)
as
the
separator.
Let
targetPath
be
the
concatenation
of
target
's
path
using
U+002F
(/)
as
the
separator.
Return
a
boolean
indicating
whether
targetPath
starts
with
scopePath
.
The
above
recommendation
(to
show
some
UI
when
the
application
context
is
navigated
to
an
out-of-scope
URL
)
is
for
security
reasons.
It
ensures
that
users
are
always
aware
of
which
origin
they
are
interacting
with.
Despite
this,
there
is
still
a
potential
spoofing
risk,
if
an
installed
app
pretends
to
navigate
to
an
out-of-scope
site
on
another
origin
.
The
site
shows
a
fake
version
of
the
user
agent's
prominent
out-of-scope
UI,
indicating
to
the
user
that
it
is
on
another
origin.
However,
in
reality,
the
user
has
never
navigated
away
from
the
installed
app's
origin,
and
the
user
agent
is
not
showing
any
out-of-scope
UI.
User
agents
could
try
to
show
the
out-of-scope
UI
in
a
way
that
cannot
be
spoofed
by
the
installed
app.
However,
due
to
the
nature
of
the
user
agent's
UI
being
minimal
or
non-existent
for
installed
apps,
this
may
not
be
possible.
An
application
context
can
be
instantiated
through
a
deep
link
,
in
which
case,
the
manifest
is
applied
and
the
deep
link
is
loaded
within
the
context
of
a
web
application.
Note
6.
Display
modes
A
display
mode
represents
how
the
web
application
is
being
presented
within
the
context
of
an
OS
(e.g.,
in
fullscreen,
etc.).
Display
modes
correspond
to
user
interface
(UI)
metaphors
and
functionality
in
use
on
a
given
platform.
The
UI
conventions
of
the
display
modes
are
purely
advisory
and
implementers
are
free
to
interpret
them
how
they
best
see
fit.
Opens
the
web
application
with
browser
UI
elements
hidden
and
takes
up
the
entirety
of
the
available
display
area.
standalone
Opens
the
web
application
to
look
and
feel
like
a
standalone
native
application.
This
can
include
the
application
having
a
different
window,
its
own
icon
in
the
application
launcher,
etc.
In
this
mode,
the
user
agent
will
exclude
standard
browser
UI
elements
such
as
an
URL
bar,
but
can
include
other
system
UI
elements
such
as
a
status
bar
and/or
system
back
button.
minimal-ui
This
mode
is
similar
to
standalone
,
but
provides
the
end-user
with
some
means
to
access
a
minimal
set
of
UI
elements
for
controlling
navigation
(i.e.,
back,
forward,
reload,
and
perhaps
some
way
of
viewing
the
document's
address).
A
user
agent
can
include
other
platform
specific
UI
elements,
such
as
"share"
and
"print"
buttons
or
whatever
is
customary
on
the
platform
and
user
agent.
browser
(default)
Opens
the
web
application
using
the
platform-specific
convention
for
opening
hyperlinks
in
the
user
agent
(e.g.,
in
a
browser
tab
or
a
new
window).
The
steps
for
determining
the
web
app's
chosen
display
mode
is
given
by
the
following
algorithm.
The
algorithm
takes
a
processed
manifest
manifest
and
returns
a
display
mode
.
processing
extension-point
:
process
any
proprietary
and/or
other
supported
display
modes
at
this
point
in
the
algorithm.
If
the
user
agent
supports
manifest
["display"],
then
return
manifest
["display"].
If
the
user
agent
supports
the
fallback_mode
,
then
return
fallback_mode
.
Note
The
above
loop
is
guaranteed
to
return
a
value
before
the
assertion,
due
to
the
fact
that
browser
is
in
every
mode's
fallback
chain
,
and
the
requirement
that
all
user
agents
support
the
browser
display
mode
.
A
user
agent
will
expose
the
actual
display
mode
being
applied
—
not
necessarily
the
one
declared
in
the
manifest
—
via
the
display-mode
media
feature,
accessible
through
CSS
or
JavaScript.
Note
that
this
media
feature
will
also
reflect
other
display
modes
for
a
web
page
when
a
manifest
is
not
being
applied.
For
example,
if
the
end-user
puts
the
page
into
fullscreen,
then
the
user
agent
would
reflect
this
change
to
CSS
and
scripts
via
the
display-mode
media
feature.
7.
Privacy
and
security
considerations
This
specification
does
not
directly
deal
with
high-value
data.
However,
installed
web
applications
and
their
data
could
be
seen
as
"high
value"
(particularly
from
a
privacy
perspective).
As
the
manifest
format
is
JSON
and
will
be
encoded
using
[
UNICODE
],
the
security
considerations
described
in
[
JSON
]
and
[
UNICODE-SECURITY
]
apply.
In
addition,
because
there
is
no
way
to
prevent
developers
from
including
custom/unrestrained
data
in
a
manifest
,
implementors
need
to
impose
their
own
implementation-specific
limits
on
the
values
of
otherwise
unconstrained
member
types,
e.g.
to
prevent
denial
of
service
attacks,
to
guard
against
running
out
of
memory,
or
to
work
around
platform-specific
limitations.
Web
applications
will
generally
contain
ECMAScript,
HTML,
CSS
files,
and
other
media,
which
are
executed
in
a
sand-boxed
environment.
As
such,
implementors
need
to
be
aware
of
the
security
implications
for
the
types
they
support.
Specifically,
implementors
need
to
consider
the
security
implications
outlined
in
at
least
the
following
specifications:
[
CSS-MIME
],
[
ECMAScript-MIME
],
[
HTML
].
As
web
applications
can
contain
content
that
is
able
to
simultaneously
interact
with
the
local
device
and
a
remote
host,
implementors
need
to
consider
the
privacy
implications
resulting
from
exposing
private
information
to
a
remote
host.
Mitigation
and
in-depth
defensive
measures
are
an
implementation
responsibility
and
not
prescribed
by
this
specification.
However,
in
designing
these
measures,
implementors
are
advised
to
enable
user
awareness
of
information
sharing,
and
to
provide
easy
access
to
interfaces
that
enable
revocation
of
permissions.
As
this
specification
allows
for
the
declaration
of
URLs
within
certain
members
of
a
manifest,
implementors
need
to
consider
the
security
considerations
discussed
in
the
[
URL
]
specification.
Implementations
intending
to
display
IRIs
and
IDNA
addresses
found
in
the
manifest
are
strongly
encouraged
to
follow
the
security
advice
given
in
[
UNICODE-SECURITY
].
Developers
need
to
be
aware
of
the
security
considerations
discussed
throughout
the
[
CSP3
]
specification,
particularly
in
relation
to
making
data:
a
valid
source
for
the
purpose
of
inlining
a
manifest.
Doing
so
can
enable
XSS
attacks
by
allowing
a
manifest
to
be
included
directly
in
the
document
itself;
this
is
best
avoided
completely.
It
is
RECOMMENDED
that
UI
that
affords
the
end
user
the
ability
to
install
a
web
application
also
allows
inspecting
the
icon,
name,
start
URL
,
origin,
etc.
pertaining
to
a
web
application.
This
is
to
give
an
end-user
an
opportunity
to
make
a
conscious
decision
to
approve,
and
possibly
modify,
the
information
pertaining
to
the
web
application
before
installing
it.
This
also
gives
the
end-user
an
opportunity
to
discern
if
the
web
application
is
spoofing
another
web
application,
by,
for
example,
using
an
unexpected
icon
or
name.
It
is
RECOMMENDED
that
user
agents
prevent
other
applications
from
determining
which
applications
are
installed
on
the
system
(e.g.,
via
a
timing
attack
on
the
user
agent's
cache).
This
could
be
done
by,
for
example,
invalidating
from
the
user
agent's
cache
the
resources
linked
to
from
the
manifest
(for
example,
icons)
after
a
web
application
is
installed
-
or
by
using
an
entirely
different
cache
from
that
used
for
regular
web
browsing.
It's
conceivable
that
a
shortcut
url
could
be
crafted
to
indicate
that
the
application
was
launched
from
outside
the
browser
(e.g.,
"url":
"/task/?from=homescreen"
).
It
is
also
conceivable
that
developers
could
encode
strings
into
the
url
that
uniquely
identify
the
user
(e.g.,
a
server
assigned
UUID
).
This
is
fingerprinting/privacy
sensitive
information
that
the
user
might
not
be
aware
of.
When
the
web
application
is
running,
it
is
RECOMMENDED
that
the
user
agent
provides
the
end-user
a
means
to
access
common
information
about
the
web
application,
such
as
the
origin,
start
and/or
current
URL,
granted
permissions,
and
associated
icon.
How
such
information
is
exposed
to
end-users
is
left
up
to
implementers.
Additionally,
when
applying
a
manifest
that
sets
the
display
mode
to
anything
except
"
browser
",
it
is
RECOMMENDED
that
the
user
agent
clearly
indicate
to
the
end-user
that
their
are
leaving
the
normal
browsing
context
of
a
web
browser.
Ideally,
launching
or
switching
to
a
web
application
is
performed
in
a
manner
that
is
consistent
with
launching
or
switching
to
other
applications
in
the
host
platform.
For
example,
a
long
and
obvious
animated
transition,
or
speaking
the
text
"Launching
application
X".
The
display
member
allows
an
origin
some
measure
of
control
over
a
user
agent’s
native
UI.
After
taking
over
the
full
screen,
it
could
attempt
to
mimic
the
user
interface
of
another
application.
This
is
also
facilitated
by
the
'display-mode'
media
feature
[
MEDIAQUERIES-5
],
through
which
a
script
can
know
the
display
mode
of
a
web
application.
A.
IANA
considerations
The
mime
type
application/manifest+json
is
the
application
manifest
media
type
.
Both
the
mime
type
and
the
.webmanifest
file
extension
are
registered
with
the
Internet
Assigned
Numbers
Authority
(
IANA
).
A.1
Media
type
registration
If
the
protocol
over
which
the
manifest
is
transferred
supports
the
[
MIME-TYPES
]
specification
(e.g.
HTTP),
it
is
RECOMMENDED
that
the
manifest
be
labeled
with
the
application
manifest
media
type
.
Type
name:
application
Subtype
name:
manifest+json
Required
parameters:
N/A
Optional
parameters:
N/A
Encoding
considerations:
Same
as
for
application/json
([
RFC7159
]
section
8.1)
See
link
type
"manifest"
for
details
about
how
a
web
manifest
is
fetched
processed
.
B.
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
words
MAY
,
MUST
,
MUST
NOT
,
OPTIONAL
,
RECOMMENDED
,
SHOULD
,
and
SHOULD
NOT
in
this
document
are
to
be
interpreted
as
described
in
BCP
14
[
RFC2119
]
[
RFC8174
]
when,
and
only
when,
they
appear
in
all
capitals,
as
shown
here.
There
is
only
one
class
of
product
that
can
claim
conformance
to
this
specification:
a
user
agent
.
Note
Although
this
specification
is
primarily
targeted
at
web
browsers,
it
is
feasible
that
other
software
could
also
implement
this
specification
in
a
conforming
manner.
For
instance,
search
engines,
or
crawlers,
could
find
and
process
manifests
to
build
up
catalogs
of
sites
that
potentially
work
as
installable
web
applications.
B.1
Extensibility
This
section
is
non-normative.
This
specification
is
designed
to
be
extensible.
Other
specifications
are
encouraged
to
define
new
members
for
the
manifest.
However,
in
doing
so,
please
follow
the
conventions
used
in
this
specification.
In
particular,
use
the
processing
extension-point
to
hook
into
the
steps
for
processing
a
manifest
.
Also,
be
sure
to
specify
the
steps
for
processing
your
particular
member
in
the
manner
set
forth
in
this
specification.
This
will
help
keep
this
part
of
the
platform
consistent.
To
allow
the
community
to
easily
find
extensions,
please
add
your
extensions
to
the
Extensions
Registry
.
When
specifying
a
new
member,
don't
override
or
monkey
patch
anything
defined
in
this
specification.
Also,
don't
assume
your
member
will
be
processed
before
or
after
any
other
member.
Keep
your
new
member,
and
its
processing,
atomic
and
self
contained.
Note
also
that
implementations
are
free
to
ignore
any
member
they
do
not
recognize
or
support.
If
editors
are
writing
a
specification
and
temporarily
want
to
patch
this
specification
to
help
implementations
along,
file
a
bug
so
the
community
is
informed
of
what
editors
are
trying
to
do.
B.1.1
Proprietary
manifest
members
This
section
is
non-normative.
Although
proprietary
extensions
are
undesirable,
they
can't
realistically
be
avoided.
If
a
user
agent
chooses
to
interpret
a
member
in
the
manifest
JSON
that
is
not
specified
in
this
document,
it
can
do
so,
but
with
care.
We
encourage
implementors
adding
proprietary
extensions
to
consider
whether
they
could
become
a
standard
(i.e.
if
it
would
make
sense
for
a
second
user
agent
on
a
different
platform
to
make
use
of
that
member,
even
if
no
other
user
agent
has
expressed
interest
right
now).
If
so,
we
ask
authors
to
design
the
API
in
a
vendor-neutral
way,
and
propose
it
as
a
standard.
If
the
new
member
is
truly
proprietary
(i.e.
will
only
ever
make
sense
in
the
context
of
a
proprietary
ecosystem),
use
this
process,
and
prefix
it
with
the
short
name
of
that
proprietary
ecosystem
to
avoid
name
collisions.
Do
not
use
vendor
prefixes
that
are
intended
for
later
removal
once
they
become
standard
(those
tend
to
stick
around
forever).
Only
use
prefixes
that
will
make
sense
now
and
into
the
future.
We
encourage
implementors
to
add
proprietary
extensions
to
our
Extensions
Registry
.
This
allows
the
community
to
track
what
extensions
vendors
and/or
the
web
community
have
defined
and
documented.
Periodically,
we
will
consider
those
extensions
for
standardization.
The
following
is
an
example
of
three
hypothetical
proprietary
extensions.
In
this
example,
we
have
deliberately
chosen
(made-up)
names
of
things
that
could
be
external
sites
or
services,
not
names
of
browsers
or
browser
vendors.
These
are
not
vendor
prefixes
belonging
to
the
browser
that
invented
them;
they
are
prefixes
of
proprietary
services.
C.
Application
Information
This
section
is
non-normative.
Several
members
of
the
Web
Application
Manifest
provide
additional
metadata
related
to
how
the
web
application
may
be
presented
in
the
context
of
a
digital
storefront,
installation
dialog,
or
other
surfaces
where
the
web
application
may
be
marketed
or
distributed.
In
an
effort
to
support
these
use
cases
better,
the
following
members
have
been
moved
into
Web
App
Manifest
-
Application
Information
:
categories
description
iarc_rating_id
screenshots
D.
Relationship
to
HTML's
link
and
meta
elements
This
section
is
non-normative.
An
extensive
discussion
of
why
we
chose
to
use
JSON
instead
of
HTML
meta
/
link
tags
for
this
specification
is
available
on
GitHub
and
on
the
www-tag
list.
Below
is
a
short
summary
of
the
key
points
raised
in
those
discussions.
The
document
format
defined
in
this
specification
provides
a
unified
means
of
encapsulating
metadata
about
a
Web
application
in
a
way
that
we
hope
will
avoid
existing
pitfalls
with
both
proprietary
and
[
HTML
]'s
meta
/
link
tags.
Those
pitfalls
include:
Developers
have
to
duplicate
the
icons
and
application
name
in
each
page
of
a
web
site,
leading
to
significant
redundancy
across
pages.
This
is
compounded
if
that
information
never
gets
used
by
the
user
agent
(e.g.,
the
user
never
bookmarks
the
web
application).
Spreading
metadata
across
multiple
documents
can
cause
data
to
fall
out
of
sync.
If
the
metadata
for
a
web
application
lives
in
a
HTML
document,
that
significantly
increases
the
cost
to
user
agents
(and
users)
of
checking
for
updates
to
the
metadata
of
a
site.
Since
the
HTML
file
is
likely
to
change
often,
it
means
that
a
user
agent
will
often
have
to
download
the
whole
HTML
file
in
order
to
check
if
any
of
the
relevant
meta
tags
have
changed.
If
this
resource
contains
inlined
resources
like
JavaScript,
images,
or
stylesheets,
this
could
be
a
non-trivial
download.
Although
it
would
be
unrealistic
to
think
that
this
specification
won't
bring
its
own
set
of
problems,
externalizing
this
data
in
the
form
of
a
manifest
solves
the
problems
described
above.
These
problems
are
solved
by:
Making
the
manifest
externally
linkable:
External
manifest
files
can
be
cached
as
external
resources,
saving
both
bytes
and
redundancy
in
the
markup.
Flexible
value
types:
unlike
HTML
attributes,
members
of
the
manifest
can
represent
data
using
complex
types,
such
as
objects
and
arrays,
rather
than
just
strings.
This
solves
the
problem
of
the
awkward
and
highly
inconsistent
formats
the
values
of
proprietary
meta
tags
are
currently
using,
especially
when
a
tag's
value
contains
several
sub-values.
In
addition,
standardizing
the
functionality
currently
provided
by
the
various
meta
tag-based
solutions
within
the
manifest
solves
the
problem
of
having
tproprietary
and
standard
[
HTML
]
tags
that
all
achieve
the
same
thing.
Of
course,
this
hinges
on
the
standard
actually
getting
implemented
by
browsers
and
those
browsers
getting
widely
deployed
to
users:
if
this
happens,
the
Web
community
might
be
able
to
retire
many
of
the
proprietary
meta
tags
plaguing
the
Web
at
the
time
of
writing.
More
information
about
the
proprietary
tags
can
be
found
in
the
Use
Cases
and
Requirements
for
Installable
Web
Apps
.
Lastly,
this
specification
does
not
make
the
standardized
solutions
found
in
[
HTML
]
redundant.
When
members
like
the
name
or
icons
is
missing
from
the
manifest,
user
agents
can
search
in
a
manifest's
owner
[
HTML
]
document
for
things
like
icons
and
the
application
name
(or
a
user
agent
might
even
fallback
to
proprietary
tags/metadata,
if
they
are
present
in
a
document).
This
can
include,
for
instance,
asking
the
end-user
what
their
preferred
language
is
and
dynamically
adding
or
replacing
the
manifest
link
relationship
to
the
document
based
on
that
language
preference
(e.g.,
using
a
URL
like
"manifest.php?lang=fr").
Using
content-negotiation,
or
geotargeting,
etc.
on
the
server:
The
server
that
hosts
the
web
application
could
attempt
to
predetermine
the
end-user's
language
by
using
geotargeting
or
by
using
content
negotiation
(e.g.,
using
an
HTTP
"
Accept-Language
"
header
[
RFC9110
],
or
even
a
custom
HTTP
header).
Given
the
options
above,
developers
need
to
be
mindful
of
the
end-user's
privacy
with
respect
to
their
preferred
language:
When
the
end-user
has
explicitly
indicated
their
language
preference
to
a
web
application
(i.e.,
when
not
just
using
the
user-agent
default
language
settings),
sending
the
end-user's
preferred
language
in
the
clear
over
the
wire
is
generally
not
OK.
Doing
so
would
reveal
personal
information
about
an
end-user.
As
such,
developers
are
encouraged
to
use
[
TLS
]
to
reduce
the
chances
of
pervasive
monitoring
of
their
Web
applications
[
RFC7258
].
This
document
reuses
text
from
the
[
HTML
]
specification,
as
permitted
by
the
license
of
that
specification.
Dave
Raggett
and
Dominique
Hazael-Massieux
contributed
to
this
specification
via
the
HTML5Apps
project.
Claudio
Gomboli
for
icon
example
images.
Indiana
University
Bloomington
security
researchers
have
contributed
to
this
specification
by
reporting
potential
risks
related
to
out-of-scope
navigation.
