►
From YouTube: WebPerfWG TPAC 2020 meetings - October 20 - part 1
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
so
hello
welcome
to
second
day
of
the
web
working
group,
tpacks
meeting,
which
is
like
face-to-face
this
year.
As
always,
this
is
the
call
is
being
recorded
and
will
be
posted
online,
and
since
we
have
a
packed
schedule,
we're
gonna
talk
about
pre-rendering.
First,
with
the
jeremy
and
david
leading
the
way
so
jeremy,
do
you
wanna?
Do
you
wanna
present.
B
All
right
is
that
working
other
way,
yeah
so
hi,
I'm
jeremy
from
google,
so
we're
looking
at
bringing
back
pre-rendering,
and
we
think
that
we
can
do
a
better
job
of
pre-rendering
than
we
did
last
time.
We
want
to
build
a
virtual
pre-rendering
that
looks
to
where
the
web
is
going
in
a
number
of
ways.
So
we
think
that
this
is
going
to
require
some
help
from
authors
to
to
integrate
with
to
integrate
with
this
this,
this
new
form
pre-rendering.
B
That
would
help
us
deliver
faster
loading,
basically
to
users,
is
the
main
objective
there.
So
this
sort
of
comes
in
three
parts:
behavior
changes
an
opt-in
to
those
behavior
changes
and
a
trigger
mechanism,
so
behavior
changes
so
we're
talking
about
like
pre-navigation,
fetching
and
rendering,
and
so
we
think
that
in
the
future
that
should
have
well
specified
behavior
and
that
that
means
you
know.
Ideally,
you
know
written
down,
interoperable
and
so
on,
that
integrates
with
other
web
spec
primitives
like
permission
policy
and
so
on
to
limit
nuisance.
B
Behavior,
like
permission,
prompts,
while
pages
are
being
rendered
before
navigation,
and
I
we
think
that
this
pre-navigation
fetching
and
rendering
the
future
should
limit
cross-site
tracking
in
ways
consistent
with
updated
browser,
privacy
models
that
number
of
vendors
are
moving
towards,
and
so
we
propose
to
define
a
behavior
of
pre-navigation
fetch,
that's
uncredentialed
and
the
definition
of
a
new
loading
mode
in
which
a
browsing
context
hosts
a
pre-navigation
document
and
its
behavior
is
modified
consistent
with
the
the
the
goals
mentioned
earlier.
B
Most
notably,
we
think
that
sites
will
not
be
able
to
access
their
unpartitioned
storage
before
navigation,
and
so
this
means
that
the
they
only
get
access
to
the
storage
and
the
credentials
that
they
have
stored
on
that
site
when
navigation
actually
occurs,
which
is
consistent
with
the
way
that
works
on
link,
navigation
or
form
submission.
B
Because
some
of
those
changes,
though,
are
potentially
breaking
they're
radical
that
we
can't
assume
that
all
content
will
work
unmodified.
B
For
instance,
if
you
load
a
site,
that's
signed
in
where
the
user
has
signed
in
and
you
load
it
without
credentials,
the
user
signed
in
state
won't
be
properly
reflected
and
that
breakage
would
be
surprising
to
users,
so
a
site
could
be
prepared
to
upgrade
on
navigation,
and
it
needs
to
declare
that
it's
ready
to
do
that.
If
a
site
is
completely
static,
and
is
you
know
the
same
for
all
users,
this
is
just
simply
marking
it.
Otherwise,
authors
might
need
to
make
some
modifications
before
they
can.
B
They
can
make
this
declaration
since
an
http
response.
Header
is
not
easy
for
all
authors
deployed.
We
propose
also
allowing
this
declaration
to
occur
in
the
html
source
itself-
authors
that
are
not
sure
about
some
sub-components
or
certain
part
labs-
that
they're
loading
can
simply
defer
loading.
Those
until
navigation
occurs,
and
at
least
the
rest
of
our
application
will
have
be
able
to
do
some
of
this
fetching
and
rendering
logic
before
navigation
occurs.
B
The
idea
of
the
response
to
an
uncredentialed
fetch
opting
into
being
used
even
when
credentials
are
ultimately
present
when
navigation
occurs,
has
previously
been
proposed
and
discussed
a
little
bit
as
sp
navigate
and
as
allows
uncredentialed
navigation.
This
is
in
a
similar
sort
of
vein
and
then,
finally,
the
final
piece
of
that
is
on
the
referring
site.
B
It
needs
to
indicate
that
pre-navigation
fetching
is
going
to
be
safe
from
unwanted
side
effects,
so
in
the
same
origin
or
same
site
case
we
might
be
comfortable
sending
credentials
and
so
sending
a
get
request,
potentially
of
side
effects
and
the
site
needs
to
indicate
up
front
that
that's
likely
to
be
safe
before
the
request
is
sent
because
after
the
get
request
is
sent,
those
side
effects,
you
know,
may
have
already
happened,
and
also
this
is
also
giving
the
ua
an
indication
that
the
resource
is
going
to
be
compatible.
B
We
do
you
know
you
can
double
check
with
the
often,
but
it's
if
you
know
you
want
to
have
some
indication
this
is
actually
likely
to
work
and
that
the
user
is
actually
likely
to
go
with
there.
Today
we
have
we've
had
in
the
past
the
link
rail
pre-render,
which
today
for
chrome
triggers
something
we
call
no
state
prefetch
previously,
it
triggered
a
previous
iteration
of
pre-rendering,
and
that
provides
a
very
strong
signal.
B
Implementing
ua
is
typically
like
nearly
always
respect
that
for
a
very
small
number
of
urls,
and
we
think
that
some
sort
of
a
hint
from
the
referring
site
is
necessary.
It
could
be
take
a
shape
similar
to
that
or
it
could
be
a
broader
thing
to
simply
enable
authors
to
give
the
information
that
we
absolutely
need,
which
is
safe,
compatible
and
reasonably
likely
for
a
broader
set
of
urls
on
the
page,
enabling
the
user
agent
to
use
its
its
own
heuristics
to
determine
what
amount
of
work
is
useful
to
do
in
advance.
C
Yeah
and
I'll
just
add
that
you
know
this
is
all
pretty
early.
We've
been
thinking
and
iterating
on
it
for
a
while
with
google
and
both
in
public
and
and
internally.
C
C
So,
if
you
check
out
the
links
that
jeremy
put
on
his
first
slide
there,
you
know
we
have
a
github
repository.
It's
it's
very
work
in
progress,
but
it
has
an
overview
of
the
problem,
space
and
kind
of
the
directions
of
the
the
solutions
we're
thinking
of
so
that's
a
great
place
to
check
out
if
you
want
more
information
or
want
to
engage.
A
And
one
bit
that
I
find
particularly
interesting
here
about
the
upgrade
path
is
that
it
seems
like
something
that
will
encourage
cachable
static
html
that
can
upgrade
itself
into
a
credentialed
user
experience
compared
to
the
current
state
of
things
where
the
html
is
often
dynamic
and
generated
on
the
fly.
A
C
So
since
nobody's
saying
anything
I'll
say
that
maybe
it's
not
that
big
of
a
change
to
the
ecosystem,
most
sites
already
have
a
logged
out
view.
C
So
I
guess
it
depends
on
like
whether
they
lock
their
entire
content
behind
a
login
wall
or
not
like
facebook,
for
example,
would
be
very
different
than
github,
but
like
for
github.
This
would
be
very
easy.
They
just
display
their
logged
out
view.
They'd
have
a
little
bit
of
client-side.js
to
swap
out
some
of
the
elements
to
display
more.
Like
the
logged
in
view,
I
guess
yeah,
for
something
like
facebook.
It
would
be
very
different.
That's.
B
There's
so
there's
there's
some
like
sort
of
like
quickly
written
like
sample
code
snippets,
but
we're
early
guys.
We
don't
have,
like
you,
know,
examples
of
adapting
real
applications
in
that
way.
If
that's,
what
you
mean,
the
exact
shape
that
that
api
takes
depends
a
little
bit
on
how
the
api
that
we
develop
here
evolves
and
also
how
some
adjacent
apis
like
storage
access,
evolve,
because,
ultimately,
the
thing
that
authors,
you
know
want
to
be
able
to
do
here
say
like
when
storage
is
available,
then
load
any
of
this.
B
This
data
that
is
dependent
on
on
the
user's
personalized
state
for
applications
where
the
the
entire
application
is
personalized.
There
might
not
be
a
lot
that
you
can
load
in
advance,
but
for
applications
we're
mostly
static.
You
can
anticipate
that,
like
you
know,
visiting
your
wikipedia
or
whatever
most
the
content
is
going
to
be
the
same
either
way,
and
so
a
smaller
number
of
components
can
just
say:
okay,
if
I
gained
access
to
credential
storage
and
that
I
discovered
in
there
something
that
should
meaningfully
affect
the
way.
B
D
Yeah
you
did,
I
was.
I
was
thinking
that
there'd
probably
be
some
event
fired,
but
would
it
be
a
sort
of
pre-render
to
render
state
event
change,
or
is
it
going
to
be,
like
you
said,
on
storage
availability
and
is
that
broadly
applicable
to
other
cases?
I
guess
there's
flexibility
in
terms
of
where
it
will
go,
but
that
makes
sense.
Yeah.
C
We're
we're
definitely
trying
to
figure
this
out
like
there
do
seem
to
be
apis
for
all
the
individual
changes
like
there
is
a
permissions
api
that
will
tell
you
like.
Oh,
you
know,
you're
going
to
be
auto-denied
while
pre-rendered,
but
now
you're
in
a
state
where
you
can
ask
and
it
might
not
be
denied,
there's
a
storage
access
api
in
at
least
many
browsers.
C
That
tells
you
you
know,
no,
you
don't
have
storage
access
and
then
one
day
it
says:
oh
yeah,
you
do
do
you.
Do
we
just
tell
people
to
like
use
all
these
signals
individually
or
do
we
expose
the
like
pre-rendering
thing
as
a
first
class
you
know,
and
and
even
if
we
do,
should
we
encourage
people
to
use
it
early
days.
E
E
E
Okay,
but
because
the
response.
E
But
if
the
user
does
not
have
locally
stored
credentials,
then
we
could
use
that.
B
I
haven't
thought
through
all
the
details,
but
my
inclination-
maybe
other
people
in
the
room,
have
thoughts,
would
be
that
we
could,
probably
we
probably
couldn't.
We
probably
could
use
that
response
in
some
way.
We
certainly,
I
don't
think
we'd
have
to
re-fetch
it.
If
we
fetched
it,
there
were
no
credentials
and
the
the
cash
nothing
about
the
cash
control
or
anything
prevents
us
from
reusing
it.
I
don't
see
why
we
couldn't.
C
But
it
still
might
not
be
good
to
like
reuse
the
rendering
because
it
was
rendered
with
like
indexeddb
throwing
or
you
know,
all
the
storage
access
api
is
cut
off,
and
so
maybe
it
just
like
is
showing
an
error
screen.
B
Right,
there's
some
thinking
about
whether
we
can
do
a
a
form
of
pre-rendering
with
that's
more
focused
on
either
preserving
existing
behavior
or
cancelling
the
pre-rendering,
and
in
some
cases
we
might
be
able
to
use
the
rendering
in
general.
We
might
not
be
able
to
use
the
rendering,
but
I
think
we
could
probably
always
use
or
usually
use
the
the
response
body,
at
least
for
a
new
rendering.
B
E
B
I
think
so
I
don't
see
a
way
that
for
the
week
that
the
user
agent
can
determine
that
that's
the
case
without
the
site
telling
us
in
general,
okay,
it
would
be
great
if
we
could
right.
It
would
be
great
if
we
can
detect
that
this
site
is
static
and
the
server
wouldn't
have
given
us
a
different
response.
If
we
had
sent
different
request
headers,
but
I'm
not
sure
how
we
can
determine
that
from
the
client
side.
E
G
Yeah,
we
of
course
care
about
the
resources,
but
we
started
to
have
a
better
infrastructure
to
be
able
to,
for
example,
like
a
throttle
or
like
a
freeze
at
some
stage
and
also
like
have
a
better
isolation
mechanism
between
pages.
So
we
feel
that
we
can
probably
do
better
trying
to
keep
watching
resource
consumption
and
that
better
judgement.
G
While
we
are,
of
course,
still
like
exploring
the
space,
but
that's
the
general
answer,
you
probably
want
that
more.
B
You
know
they
should
feel
free
to
not
to
just
prefetch
or
to
do
nothing
if
they
think
that
you
know
this
is
going
to
net
to
grade
user
experience
like
they
use
the
user
agent
should
decide
based
on
you,
know
the
environment
of
the
user's
device,
based
on
the
likelihood
that
the
pre-rendering
is
going
to
be.
You
know,
used
by
the
user
and
and
should
make
it
a
call
about
what
that
is.
We
hope
that
pages
being
able
to
identify
pre-rendering
will
be
able
to
modify
their
behavior
in
such
a
way.
B
F
F
C
Yeah,
I
think
we
cannot
depend
on
sites
coding
around
it.
I
think
it's
it's
a
nice
thing
that
they
could
do
if
they
wanted
to
to.
You
know
be
nicer
to
the
user,
but
I
think
at
least
from
my
impression
having
joined
this
on
it
recently.
The
shift
in
thinking
really
came
on
the
chrome
side
when
we
implemented
bf
cache
right.
Other
browsers
have
had
this
for
a
long
time
and
we,
you
know
we
we
had
like
background
tabs
and
then
we
were
like
well,
you
know
background
tabs.
C
We
decide
is
like
a
good
use
of
the
user's
resource.
Sometimes
why
not
like
things
in
the
past
or
our
thing?
You
know
in
the
bf
cache,
and
this
is
just
kind
of
extending
the
same
principle
like
sometimes
you
can.
You
can
keep
things
around
that
aren't
immediately
visible
to
the
user
and
it
might
improve
user
experience
later
so.
B
I
I
will
say
on
the
on
the
chrome
side
that
we've
been,
you
know,
putting
some
additional
attention
toward
encouraging
authors
to
improve
the
performance
of
their
sites.
If
you
do
with
efforts
like
core
web
vitals,
and
so
I
think
yeah,
I
I
think
that
we,
you
know
you'd
hope
that
authors
would
do
it.
I
agree
that
you
can't
depend
on
authors,
authors
doing
it
certainly
also
sites
and
user
agents
could
choose
to
trigger
peer
rendering
in
cases
where
they
know
that
the
destination
site
has
made
those
changes.
F
Yeah
I
mean
I
don't
want
to
discourage
the
work
because
we
saw
the
first
time
it
launched
the
the
performance
impact
when
it
works
can
be
awesome.
It's
just
I'm
historically
skeptical
about
the
amount
of
adoption
like
if
it
mostly
works
for
lightweight
sites
that
don't
have
much
user
authentication.
F
Those
are
the
least
likely
to
implement
a
client-side
spa
transition
if
you
would
and
the
heavier
sites
that
are
doing
like
ssr,
and
things
like
that
tend
to
want
to
have
as
much
state
as
possible
to
send
down
the
rendered
version
of
the
logged
in
credentials
and
not
do
a
full
client-side
app
if
you
would,
which
is
what
the
rehydration
almost
is
when
you,
when
you
suddenly
get
the
credentials
so
it'll
be
interesting
to
see
where
it
goes.
I
think
it's
just
going
to
be.
D
B
We
we
have,
we
have
started
to
think
about
it,
we're
having
discussions
in
internally
about
it.
There's
there's
some
complexity
to
that
to
that
problem.
I
don't
know
that.
I
have
conclusions
that
I
can
articulate
well
enough
to
share
it
meaningfully
right
now,
dominic.
C
Yeah,
I
mean,
I
think
the
main
thing
I
realized
we
literally
were
discussing
this
yesterday
is
that
pages
do
want
to
know
if
they
pre-rendered
slowly
right.
So
we
still
need
to
give
them
all
the
information
that
we're
giving
them
now,
but
in
terms
of
like
they
also
want
to
know
if
they've
made
the
user
experience
super
fast
right.
So
you
should
get
like
two
statistics
for
load
time.
You
should
get
like
the
traditional
load
time,
which
includes
all
the
time.
C
You
spent
loading
in
the
background
and
you
should
get
what
the
user
actually
experienced,
which
could
be
zero
or
very
close
to
zero,
so
don't
know
how
it's
going
to
manifest
in
the
apis
and
then
core
vitals
and
all
that.
But
I
feel
like
those
are
the
two
pieces
of
information
you
do
need
to
get
out.
D
A
Maybe
that
ties
in
a
bit
to
the
visibility
discussion
that
david
was
planning
to
talk
about,
but
maybe
before
that
just
one
question
to
regarding,
like
to
other
browser
vendors
regarding
the
non-credentialed
aspects
of
pre-rendering.
I
know
that
in
the
past
for
prefetch
we
had
a
bunch
of
discussions
about
ways
to
make
privacy
pre-rendering
prefetch
work,
and
this
is
in
a
way,
an
extension
of
that
any
quick
thoughts
on
the
aspects
of
non-credentialed
non-credentialed
prerender,
coupled
with
the
lack
of
access
to
local
storage.
A
Would
that
be
something
that,
from
your
perspective,
is
implementable,
so
mostly
talking
to
alex
and
benjamin.
E
Or
implementable,
yes,
but
it's
certainly
a
little
strange.
My
initial
thought
would
have
been
to
just
do
the
load
with
the
credentials
and
storage
in
its
own
partition.
C
So
the
partitioned
versus
no
storage
is
an
interesting
question.
We're
you
know
not
we're
not
settled,
but
our
reasoning
for
no
storage
is
that
you
do
eventually
need
to
transition
to
the
first
party
partition
right
like
when
you
activate
and
and
so
then
you
have
this
weird
merging
problem
right,
like
they've
written
some
stuff
into
indexeddb
in
the
partition.
C
E
I
think
there
may
be
a
fundamental
difference
in
how
we're
thinking
about
partitioning,
because
in
our
implementation,.
B
E
B
B
Then,
when
the
user
navigates
to
that,
if
you
don't
ever
execute
a
transition,
the
user
observes
a
state,
that's
not
the
state
that
doesn't
contain
those
credentials
and
then
the
user
doesn't
see
themselves
as
logged
in
so
they're
like
I
clicked
the
link
to
b.com,
I'm
logged
in
on
b
com.
Why
am
I
not
logged
in.
E
Yes,
I
I
believe
the
difference
in
viewpoint
here
is
also
a
difference
in
our
cookie
partitioning
between
chromium
and
webkit
in
webkit.
I
see
no
problem
and
I
see
no
need
for
any
web
page
to
opt
in
to
this.
C
E
C
So
so
that's
the
new
new
ingredient
here
which,
as
jeremy
says,
creates
a
very
unexpected
user
experience
if
you're
like,
if
you're
partitioned
like
you
could
literally
have
two
tabs
next
to
each
other
for
the
same
website,
one
of
which
you're
logged
in
when
you're
not-
and
you
could
just
be
like
why.
Why
am
I
not
logged
in.
E
Yeah,
I
don't
know,
I
don't
know
where
the
difference
is,
but
there's
there's
a
difference
and
we.
C
Wrote
up
our
threat
model,
I
I
I
yeah,
maybe.
B
What
you're
describing
seems
to
me
to
be
inconsistent
with
my
understanding
of
webkit's
itp
policies,
but
it's
possible.
I
don't
understand
them
well
enough.
E
A
B
Because
I
think
like,
if
you
load
it
and
you're
allowed
to
execute,
you
will,
even
if
you
just
do
the
fetch
with
credentials
like,
if
you
do
the
fetch
with
credentials
triggered
by
a.com2b.com,
then
this
basically
allows
you
to
do
the
equivalent
of
sending
a
sub
resource
request
with
credentials
which,
if
you
start
partitioning
storage
like
is
the
exact
thing
that
sword
partitioning
prevents,
which
is
you
know
if
you,
so,
if
you're
in
a
world
where
you
believe
that
third-party
subframes
and
sub-resources
should
be
partitioned,
so
sorry,
shouldn't
yeah
should
be
partitioned,
should
not
be
part
of
the
the
the
first
party
partition
for
that
that
sub
origin.
B
A
Way,
okay
and
so
maybe
the
action
item
would
be
to
like
either
further
discuss
it
in
an
upcoming
working
group
call
or
offline
on
on
github
and
try
to
figure
out
the
source
of
difference.
A
H
H
H
Right
yeah,
so
whenever
you
do
the
cross-origin,
you
do
the
pre-render
in
a
completely
like
brand
new
state,
each
time
and
and
then
that's
why
that
allows
credential
navigations
or
whatever
comes
into
play
yeah.
I
have
to
think
about.
If
there's
some
sort
of
timing
attack
possible
here.
C
There
are
timing
attacks
possible,
which
is
part
of
why
we're
trying
to
cut
off
credentials
right.
So
if
you
have
no
access
to
your
storage,
then
you
can't
say
like
oh
it's
you
know
user
x
and
and
then
use
a
timing
correlation
to
like
communicate
that
for
cross-site
tracking.
C
That's
that's
our
thinking,
but
I
I'm
sure
there
are.
This
is
a
subtle
and
complicated
area,
so
I
do
also
encourage
you
to
find
other
attacks
that
we
haven't
thought
of.
Sorry.
H
Yeah
right
yeah,
I
mean
I
can't
I
can't
reason
through
it
in
my
head
right
now
too
out
in
the
morning,
but
yeah
well,
I'm
sure
I'm
sure
we'll
look
into
that.
F
A
Cool
and
with
that
maybe
david
can
talk
a
bit
about
the
visibility
aspects,
because
I
think
a
lot
of
this
work
is
happening
in
areas
that
this
working
group
decided
that
will
move
more
towards
html.
A
So
this
is
in
a
way
continuation
of
resource
hints
that
we
decided
to
split
up
and
integrate
into
html
directly,
but
the
visibility
aspects
of
pre-rendering
are
things
that
will
still
need
to
take
into
account
with
the
page
visibility.
A
I
Okay,
so
yeah
this,
I
think,
ties
pretty
well
into
what
this
group
has
been
doing.
So
I
know
there
used
to
be
a
pre-render
value
for
visibility
state
in
the
spec,
but
this
was
removed
since
it's
no
longer
implemented
anywhere.
I
I
couldn't
really
find
any
context,
so
I'd
be
happy
to
hear
what
maybe
experiences
were
like
from
back
then
or
if
we
thought
that
was
a
mistake
or
not,
but
as
far
as
I
could
tell,
this
was
mostly
just
a
lack
of
implementation
at
the
time.
So,
as
as
jeremy
mentioned
like
now
that
we
have
these
pre-rendering
browsing
contexts
coming
back,
we
need
some
way
to
signal
to
a
page
that
it's
being
pre-rendered.
I
The
obvious
question
has
often
been
like
is
visibility
hidden
enough,
it
seems
like
when
you're
pre-rendered,
you
can't
actually
see
the
page
so
what's
really
different
there,
and
I
think
that
there
are
some
some
differences
they're,
not
necessarily
very
mainstream
cases,
but
for
things
like
analytics
or
ads,
you
really
do
want
to
know
the
difference
between
just
being
in
a
background,
tab
and
being
pre-rendered.
I
There
are
also
some
other
edge
cases,
so
portals
which
I'll
talk
about
in
a
second.
They
act
like
a
pre-render,
but
they
are,
they
might
be
visible
to
the
user.
So
you
can't
just
do
something
like
avoid
loading,
visible
resources
and
things
like
that.
So
this
is
very
early
and
I
don't
think
that
we
have
any
like
solid,
concrete
proposals
yet,
but
these
are
just
things
that
I'm
looking
into
and
then
kind
of
trying
to
piece
together.
I
G
I
At
what
existing
pages
do
here
so
because
of
the
legacy,
there
is
a
lot
of
existing
usages
where
they
actually
look
at
pre-rendering
state.
So
this
would
be
nice
since
a
lot
of
things
like
ads
and
analytics
are
already
looking
at
it.
It
would
just
work
out
of
the
box.
I
Does
this
make
sense
on
visibility
state,
I'm
curious
what
other
people's
thoughts
are
here
again
like?
What?
What
does
it
mean
for
a
document.hidden
and
and
like
visibility,
might
not
necessarily
describe
this
well
enough,
since
in
some
cases
we
we
can't
actually
say
for
sure
whether
or
not
you're
visible
or
not
like
in
a
portal.
I
I
The
other
major
difference
at
least
currently
are
thinking
is
that
a
portal
might
a
page
might
be
able
to
be
put
back
into
a
portal,
which
is
also
something
that's
very
different
from
pre-rendering
of
old,
where
you
assume
that
you
start
off
pre-rendering,
and
then
you
become
visible
here.
We
can
actually
go
from
visible
to
being
in
a
portal,
so
I'm
not
sure
if
necessarily
pre-rendering
as
a
state
here
makes
sense,
but
yeah
that's
kind
of
like
a
a
whirlwind
of
questions
rather
than
actual
answers
or
anything.
J
Hey
this
portal
idea
might
get
us
out
of
some
of
the
current
jams
we
have
with
visibility
and
app
launchers,
so
that
idea
sounds
really
intriguing
to
me.
I
would
like
to
learn
more
about
it.
I
Sure
so
go
ahead.
C
I'll
just
I'll
just
say,
we
have
a
pretty
in-depth
explainer
on
portals
and
we
are
currently
in
the
process
of
rebasing
it.
On
top
of
the
pre-rendering
explainers,
as
I
said
like
we
started
with
portals,
and
then
we
realized
that
this
was
all
much
more
general.
So
keep
keep
that
transitional
state
in
mind.
Like
I
don't
know,
yeah.
I
Yeah,
a
portal
kind
of
looks
and
feels
like
an
iframe
that
it's
it
starts
off
as
like
an
embedded,
an
embedding
on
a
page,
but
really
it's
completely
isolated
from
the
page,
and
it's
maybe
more
like
a
a
link,
basically
where
you
can
just
see
the
pre,
the
preview
of
of
the
navigation.
J
Oh
look:
we've
had
some
discussions
over
the
last
month
about
is,
is
the
browser?
J
Is
this
state
visible
or
isn't
hidden
from
that
app
launcher
perspective
when
you're
no
longer
in
the
browser
per
se,
but
you
are
seeing
things
that
have
been
rendered
in
a
browser
so
like
from
just
from
the
glance
one
coffee
in
on
a
tuesday.
It
feels
like
that
problem
at
least
has
a
framework
for
being
explained
in
what
you're
talking
about,
which
is
encouraging.
D
Benjamin
I
was
going
to
mention
the
same
thing.
I
think
you
mean
app
switcher,
like
the
os
level,
app
switcher,
okay,
yeah,
because
there
are
app
launchers
that
might
be
relevant
because
it's
the
initial
load
or
something
like
that.
So
I
can
imagine
having
like
a
type
of
app
launcher
interface,
that
also
does
uses
portals.
But
the
the
case
we
were
talking
about
specific
to
visibility
is
if
you
launch
the
os
level
app
switcher
on
mobile.
D
There
are
cases
where
the
tab
contents
act,
kind
of
hidden
but
also
kind
of
visible,
and
so
it
could.
It
could
be
a
tertiary
state,
and
so,
if
we're
gonna
rip
off
the
band-aid
of
moving
from
a
boolean,
all
of
a
sudden,
a
a
bunch
of
opportunities
arise,
and
so
we
weren't
really
sure
how
to
handle
this.
A
D
A
It
so
the
similarities
there,
with
the
with
the
state
of
portals,
is
that
the
content
is
viewable
but
is
not
fully
like
it's
not
the
top-level
document.
So
it's.
If
we
had
some
sort
of
a
preview
state,
it
would
probably
fit
with
both.
I
Yeah,
I
think
the
key
distinction
here
is:
it's
not
really
interactive.
I
think
same
thing
in
the
app
switcher
as
in
a
portal,
you
can't
interact
with
the
content
you're,
basically
just
seeing
a
preview,
so
that's
actually
yeah.
That
seems
like
a
very
similar
use
case
to
me.
D
J
Yeah,
but
for
compat,
I
think
the
idea
of
having
a
new
visibility
state
portal
that
we
can
define
a
little
bit
more
clearly.
I
think
that
will
probably
be
a
smoother
path
forward.
A
State
it's
a
page
visibility,
so
not
document.visibility,
but
the
the
page
visibility
api,
which
is
a
separate
thing.
Let
me
find
a
link.
K
So
I
have
one
question,
though:
isn't
the
visibility
state
determined
on
the
page
level
right
now
so
like
say,
if
you
have
an
iframe,
that's
not
within
the
viewport,
it
can
still
be
considered
visible.
So
how
is
portal
different
in
that
case?
C
Weird
to
think
of,
like
portals
people's
intuition,
often
think
of
portals
as
iframes,
but
they
share
very
little
with
them.
I
think
it's
better
to
think
of
them
as
like
pop-up
windows
that
just
happen
to
be
overlaid
on
the
page,
so
they
should
have
a
completely
separate
visibility
state
from
their
embedder
document.
A
Yeah
one
thing
here
where
I'm
so
it
seems
like
we
have
multiple
states
that
have
some
overlap
like
the
the
venn
diagram
is
a
bit
weird
because
we
could
have
so
for
pre-render.
We
could
have
hidden
content,
but
we
also
need
to
know
that
it's
pre-rendered
in
order
to
not
do
various
things
in
a
way
it's
both
hidden
and
non-interactive,
where
you
could
think
of
one
as
a
subset
of
the
other.
But
here
we
need.
A
D
D
Is
it
enough
to
think
of
visible
and
hidden
in
all
of
these
cases,
especially
since
portals
has
both
the
hidden
and
the
visible,
or
rather
pre-render
has
built
the
visible
case
in
portals
and
the
hidden
case
in
just
pre-render.
D
So
should
there
be
like
a
visibility
type
as
to
where
it's
being
displayed,
and
so
you
know,
the
app
switcher
would
be
an
example
of
visible,
but
a
different
type
of
embedding
and
so
on.
I
don't
know.
C
Yeah,
I
feel
like
there's
gonna,
be
like
a
you,
could
imagine
a
bunch
of
different
boolean
switches
right
like
apps,
which
are
no.
You
know
preview
portal,
no
pre-render,
no
hit.
You
know
background
tab.
No,
we
could
make
a
matrix
of
all
those
and
like
look
at
all
the
two
to
the
end
states
and
see
how
many
of
them
actually
occur
in
practice
and
that
could
guide
us
towards
whether
we
want
like
a
series
of
orthogonal,
booleans
or
a
bigger
noom
or.
B
I
Yeah,
the
other
interesting
thing
is:
what
would
you
consider
the
visibility
state
for
a
portal
on
a
page
in
that
case,
because
if
it's
visible,
like
you,
want
it
to
be
visible
in
the
sense
of
it's,
it's
drawing
content
and
you
want
it
to
be
ready.
But
if
you
have
a
portal
in
a
background
tab
somewhere,
you
don't
want
that
to
be
doing
lots
of
work
and
sucking
up
resources,
but
we
also
don't
want
to
have
it
be
tied
to
the
top
pages
visibility,
because
that's
also
a
timing
like
communication
channel.
A
I
K
C
In
particular,
iframes
will
get
their
storage
partitioned,
whereas
portals
will
eventually
not
get
their
storage
partitioned
right
when
you,
when
you
activate
them.
K
A
K
Yeah,
so
I
mean
there's
like
two
general
use
cases.
It's
like
one
is
know
whether
you
want
to
execute
some
amount
of
work,
but
then
there's
the
other
use
case,
which
is
tracking
performance
in
particular
of
paint
metrics.
So
I
think
just
keeping
those
in
mind.
I
think
we
want
to
try
to
satisfy
both
of
them
and
whatever
state
we
decide
to
give
to
the
portal,
presumably
like
ideally,
we'd,
want
the
portal
to
count
as
having
paint
metrics
when
it's
still
a
portal.
C
I
I
mean,
I
think,
to
some
extent
it
might
be
better
to
think
of
it
as
always,
backgrounded
right
like
it,
it's
okay,
if
your
preview
doesn't
have
animations.
You
know
this
is
really
just
like
an
extra
preview
on
top
of
pre-rendering
and
you
would
never
tell
the
pre-rendered
page
like
you're.
C
J
So
you
have
this
static
pre-render
and
if
it's
of
like
a
page
a
and
what
happens
after
it's
pre-rendered
page,
a
changes
is
that
pre-render
also
updated.
B
B
You
know
user
agent,
you
could
imagine
choosing
to
do
that
at
a
lower
rate
or
something
if
you
thought
that
that
was
the
right
thing
to
do.
But,
like
you,
you
know
because,
like
the
you
know,
the
first
frame
you
get
might
not
be.
The
final
frame
right.
You
do
want
to
like
show
the
page
completing
loading
as
it
completes
loading.
B
Yeah
I
mean
so
things
you
want,
you
probably
don't
want.
You
know
background
play
or
like
the
video
going
or
whatever,
when
it's
like
time.
You
can't
really
see
it,
but
you
do
want.
You
don't
want
the
page
to
like
not
show
up
at
all
right.
I
I
would
imagine
that
most
pages,
probably
don't
like
block
like
dom
attachment
and
like
style
on,
like
page
visibility,
but
it's
sort
of
a
question
of
what
exactly
do.
People
use
page
visibility
for.
C
And
and
to
be
clear,
you
do
have
to
opt
in
so
this
is
all
like.
You
will
have
done
a
cursory
audit,
at
least
to
say
like
when
I'm
portaled,
you
know,
do
I
behave
reasonably
and
if,
if
you
have
blocked
all
of
your
dom
rendering
behind
is
not
visible,
then
your
audit
will
say:
oh
oops.
I
need
to
fix
that
first,
first
yeah,
but.
A
But
one
conflicting
requirement
with
the
what
we
talked
earlier
about
like
the
preview
state,
is
that
for
the
tab,
switcher
case
and
the
app
switcher
case,
we
do
want
animations
and
video
and
everything
to
continue
to
play.
A
That
is
something
that
web
pages
currently
do
and
browsers
support
them.
So.
J
C
Yeah
that
is
really
interesting.
I
mean
we've
been
thinking
of
these
pre-rendering
things
on
the
html
spec
levels
browsing
contexts.
So
I
guess
what
I'm
I
think
app
switcher
things
are
probably
still
browsing
contexts
right
if
they
can
display
animations
and
stuff,
at
least
in
some
level.
I
think.
C
But
then
there
is
a
question
you
know
you
have
says:
maybe
there's
a
conflict
largely
because
the
privacy
reasons
we
just
don't
want
the
portals
to
know
if
they're
set
to
be
doing
animations
and
stuff,
so
maybe
maybe
app
switchers
and
portals
can't
be
unified
in
exactly
that
way.
Maybe
they
can
like.
You
know
this
is
all
just
you
know
what
we've
been
talking
about
for
15
minutes
we
haven't,
but
that's
my
initial
impression.
A
Yeah,
but
your
concept
of
taking
a
large
white
board
and
doing
a
table
with
all
the
different
states
and
seeing
where
everything
fits
sounds
like
the
right
next
step
to
to
figure
out.
What's
here
can
be
coalesced
versus
be
provided
as
an
orthogonal.
D
D
Since
folks
are
quiet
on
the
previous
topic
of
pre-render,
you
asked
for
feedback
from
apple
and
mozilla.
I
didn't,
I
don't
know
if
benjamin
had
a
chance.
I
don't
know
if
you
had
anything
to
say.
I
was
curious.
J
J
Can
you
start
start
this
work
with
pre-rendering
on
the
most
simple
like
it's
okay
for
me,
if
you,
you
restrict
the
domain
to
something
that
you
feel
is
insignificant,
like
even
just
static
sites,
just
to
see
kind
of
the
mechanism
how
it
works
and
how
it's
clear
I
feel
like
that
would
probably
be
helpful
for
me.
I,
the
local
storage
thing
is
like
I
don't.
I
don't
know
how
you're
gonna
get
around
that.
So
that's
why
I
thought,
like
start
with
something
really
simple,
would
be
my
advice.
E
J
Cool,
do
you
know
if
the
previous,
the
previous
work
in
this
area?
Do
you
know
what
types
of
sites
got
the
most
benefit
like.
B
G
Sorry,
what
are
you
asking
about
when
it
was
a
beneficial
in
a
previous
attempt?
What
was
that
right,
I
think
yeah
previously,
we
didn't
have
like
a
stronger
opt-in
model
or
like
any
limitations,
so
if
it
hit,
it
was
basically
very
fast,
so
that
like
hitting
or
not,
was
more
important
and
also
like
how
it
impacts
like
a
resource
usage
on
the
current
page
was
also
kind
of
like
impacted,
but
the
basically
it
was
a
yeah
hits
or
not
was
the
most
important
part.
B
Yeah,
I
think
the
question
was
more
like
which
sites
tended
to
pre-render
well
and
which
sites
tended
to
not.
Is
that.
G
G
A
Yeah,
I
also
think
that
there
are
fundamentally
different
issues
between
credentialed
content,
pre-rendering
and
non-credentialed
content.
Pre-Rendering
and
the
issues
here
would
be
you
know,
of
the
type
of
a
get
request
that
logs
off
the
user
or
whatnot,
where
for
non-credentialed
pre-rendering,
you
would
have
issues
of
content
that
the
user
expected
to
be
pre-rendered
to
be
credentialed,
but
then
it
ended
up
not
being
credentialed
and
the
site.
A
You
know
opted
into
saying
that
it
should
work
with
that
some
sort
of
an
upgrade
mode,
but
haven't
done
the
work
to
actually
do
that.
That
would
so.
I
think
that
the
issues
would
be
fundamentally
different
between
credential
and
non-credentialed.
A
A
Because
is
safari
doing
pre-rendering,
because
I
think
it
used
to
do
that
like
url
bar
sort
of
pre-rendering.
At
some
point
and.
H
C
C
The
other
thing
we
noticed,
I
think
I
think
this
got
fixed
but
like
if
you
type
some
things
in
the
url
bar,
your
computer
will
start
speaking
to
you
because
the
speech
synthesis
api
was
not
disabled,
while
pre-rendering
one
of
the
things
we're
hoping
to
do
with
this
effort
is
produce
a
specification
for
these
pre-rendering
browsing
contexts,
which
is
really
exhaustive
and
says,
like
okay,
shut
down
all
these
apis
and
that
could
be
useful
even
for
browser-initiated
pre-rendering.
You
know
not
really
part
of
the
web
platform,
so
it's
certainly
not
mandatory.
H
C
Totally
agreed:
there's
these
pre-rendering
browsing
contexts
as
we
currently
written
them
up,
come
in
two
variants:
there's
the
same
origin
version
and
the
cross-origin
version,
and
the
cross-origin
version
does
all
the
the
privacy
protection
credentials
stuff,
but
the
same
origin
version
does
all
the
user,
annoyance
prevention,
which
might
be
useful
even
for
the
browser
initiated
case,
because.
B
H
Right,
yes,
but
I
think
I
mean
it's
obviously
useful,
although
to
be
fair,
I
think
I
don't
know,
don't
all
browser
now
the
sellout
or
label
audio
in
the
first
place
right,
so
so
that
that
problem,
you
know,
is
not
really
there,
but
I'm
sure
some.
There
are
some
educators
where
something
you
know,
I'm
sure
there's
some
apis.
G
B
B
A
So
with
that
we're
at
time
for
this
discussion
any
last
points
someone
wants
to
raise
or
critical
questions,
because,
if
not,
I
think
we
can
go
on
a
five-minute
break
instead
of
instead
of
yesterday's
ten
minute
ten
minute
break,
I
chose
to
split
the
break
into
two
five
minute
breaks
that
seem
more
useful
to
this
format.