►
From YouTube: WebPerfWG call - October 8th 2020
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
as
always,
this
call
is
being
recorded
and
will
be
posted
online
and
now
to
your
host
nick.
B
Thank
you
so
two
weeks
from
now
is
tpack,
so,
just
as
a
note,
we
will
not
be
having
a
regularly
scheduled
call
to
thursdays
from
now
we'll
be
doing
tpac
this
week.
The
next
call
will
be
two
weeks
after
that
november
5th
at
10
a.m.
B
It
would
also
be
very
helpful
if,
for
anybody
that
knows
that
they're
going
if
they
could
add
themselves
to
the
attendees
list,
just
so
we
know
who
will
be
there.
We
do
have
a
decently
sized
discussion
proposals
section
right
now.
If
there
are
other
things
that
people
want
to
talk
about.
Please
add
topics
there
a
potential
amount
of
time
you
think
it
may
take,
and
then
I
think
yoga
and
I
will
try
to
pick
out
and
put
things
into
different
blocks
of
time
shortly.
B
Yes,
and
also
is
there
any
scheduling
requirements
for
any
of
those?
Please
let
us
know,
maybe
in
a
comment
there,
as
well
of
when
you
could
or
could
not
join.
If,
if
that's
something.
A
One
small
comment
about
that.
So,
first
of
all,
even
though
tpack
is
virtual,
we
still
have
to
register.
So
please
do
it's
free.
If
you
are
not
a
working
group
member
or
know
someone
who
should
be
there
and
is
not
a
working
group
member,
let
us
know
and
we
can
help
them
join
either
as
a
like,
probably
as
a
guest,
but
they
can
still
participate
in
the
discussion
and
similarly
for
the
similarly
for
the
discussion
ideas.
A
So
it's
the
the
title
says
proposals,
but
even
if
you
have
use
cases
or
other
interesting
thing
that,
like
things
that
you
think
would
be
interesting
for
the
group
to
talk
about
in
order
for
us
to
understand
what
proposals
we
need
to
come
up
with
to
solve
some
use
cases
that
we're
not
currently
covering
feel
free
to
add
that
to
the
list.
B
I
would
also
say
too
it's
if
there's
things
that
we
as
working
group
have
tackled
partially
in
the
past,
but
maybe
have
not
made
progress
on,
and
if
there
are
things
that
are
very
important
to
people
that
you
would
like
to
see
if
we
can
continue
moving
forward
in
some
way
or
another,
it's
also
a
good
opportunity
to
just
kind
of
have
your
voice
heard
so
for
anybody.
That
would
like,
please
add
your
ideas
to
the
list.
B
Anything
else
we
need
to,
and
obviously
so
in
two
weeks
from
now.
This
is
our
group's
tpack,
with
it
being
virtual
this
year,
different
groups
are
doing
them
different
weeks
and
then
there
are
still
some
breakout
sessions
on
the
official
week.
Correct
yes,
yeah,
but
in
two
weeks
from
now
we'll
be
when
we
will
be
trying
to
meet
as
a
group
collectively
anything
else
for
tpec
related
okay.
B
Today
we
have
three
potential
topics
to
talk
about,
and
certainly,
if
there's
anything
else,
I
think
the
first
one
that
we
can
jump
into
is
a
hr
time
issue.
There's
a
pull
request:
number
93
yo!
If
you
don't
wanna,
if
you
don't
mind
talking
about
it,
I
can
pick
up
the
subscribing
sure
so.
A
Basically,
the
subject
at
hand
is
alleviating
some
of
the
restrictions
for,
or
maybe
the
other
way
around.
So
right
now
the
spec
says
that
the
timestamp
resolution
should
be
at
minimum
five
microseconds,
but
not
less
than
that.
In
practice,
many
user
agents
have
significantly
coarsened
the
resolution
as
a
result
of
spectre
and
and
meltdown,
and
we
would
like
to
enable
like
we
would
like
the
spec
to
enable
different
values
of
resolution
for
for
different
scenarios.
A
In
regard
to
that,
because
as
a
response
to
spectre
and
meltdown,
we
now
have
the
concept
of
isolated
contexts
where
we
have
some
contexts
that
cannot
load
any
sub-resource
that
isn't
amenable
to
be
embedded
in
other
contexts
and
therefore,
we
can
presume
doesn't
contain
any
secrets
which,
theoretically,
not
theoretically,
which
enables
us
to
enable
various
powerful
features
such
as
shared
array,
buffers
and
javascript
self
profiling,
as
well
as
memory
measurement,
and
as
part
of
that,
we
want
to
make
sure
that
we
have
a
split
in
the
spec
that
says
that
it's
okay
for
the
timestamp
to
be
of
higher
resolution.
A
So
going
back
to
the
original
five
microseconds
in
isolated
contexts,
while
being
coarser
than
that
in
the
non-isolated
contacts,
contexts
which
is
most
of
the
web
today,
and
so
this
is
what
this
pr
is
about.
And
essentially
the
bit
that
I
wanted
to
discuss
is
the
value
for
the
non-isolated
contexts,
because
right
now,
different
browsers
do
different
things
and
I
don't
expect
all
browsers
to
align.
A
What
I'm
hoping
to
get
here
is
to
align
on
a
minimum
that
all
browsers
can
agree.
Is
you
know
a
a
minimum?
That
is
that
we
shouldn't
go
below
when
in
non-isolated
contexts.
C
Yo,
so
the
current
minimum
suggested
is
five
microseconds,
and
it's
that
when
stated
that
was
for
any
type
of
context,
it
wasn't
thinking
about
isolated
or
not.
So
perhaps
we
need
a
separate
rule
for
isolated
context,
but
you're
you're
saying
in
practice
it's
already
coarser
than
five.
So
should
we
change
the
non-isolated
guidelines
or
should
we
leave
it
at
five.
A
So
what
I'm
suggesting
is
that
we
move
the
non-isolated
guideline
to
be
higher
than
five
so
right
now
in
chrome
or
chromium,
I'm
not
sure,
if
other
and
better,
like
what
other
vendors
are
doing.
A
But
in
chrome
at
least
it's
limited
to
five
microseconds
in
architectures
that
enable
site
isolation
and
clamped
to
100
microseconds
in
environments
that
don't
enable
site
isolation
and,
in
my
view,
reasonable
values
would
be
to
keep
it
in
five
microseconds
for
isolated
contexts,
regardless
of
architecture
and
then
bump
it
to
100
microseconds
in
ice
in
non-isolated
contexts,
regardless
of
architecture
where
other
browsers
are
also
in
liberty
to
keep
higher
values
than
that.
But
yeah,
I'm
hoping
we
can
agree
on
that.
Being
a
minimum.
A
And
do
you
know
if
this
is
something
you
will
consider
like
right
now?
If
I'm,
if
I'm,
if
I
remember
correctly,
firefox
is
clamped
to
one
millisecond,
is
that
something
you
will
consider
lowering
in
non-isolated
context
or
not
really.
D
I
think
if
you
go
to
that
pr
and
it
gave
pretty
good
status
on
firefox
there's,
you
know,
there's
cross-origin,
there's
normal
and
there's
reduced
fingerprinting
kind
of
schema
that
we
want
to
support
so
we're
definitely
in
favor
of
the
idea
of
establishing
a
floor
with
a
minimum
and
not
establishing
a
specific
amount
or
a
top
level.
So
as
long
as
we
do
that.
E
E
A
A
I
guess
I'm.
I
guess
the
question
is:
will
you
be
interested
in
providing
more
like
finer
granularity
in
non-isolated
contexts
than
100
no
microbes.
E
E
Yeah
my
initial
implementation
gave
like
nanosecond
granularity,
and
that
was
a
very
bad
mistake
that
we
do
not
intend
to
redo.
So
I.
B
A
Yeah,
I
agree
that,
regardless
of
site,
isolation
and
process,
isolation
and
isolating
contacts
lower
resolution
than
five
microseconds
doesn't
like
none
of
these
resolve
the
spy
in
the
sandbox
vulnerabilities
that
led
to
the
five
microsecond
clamp.
So
I
agree
that
this
should
be
the
minimum,
also
in
isolated
context.
F
A
A
Microseconds,
which,
in
my
view,
provide
enough
granularity
for
most
of
the
sub-millisecond
use
cases,
while
not
providing
yeah
well
well,
enabling
enough
mitigation
for
like
against
the
specter-like
attacks.
C
A
The
processing
model
is
like
it
doesn't
include.
The
word
must
but
yeah.
It
basically
says
that
like
provides
those
like
the
minimum
values
and
then
implementations
can
add
implementation
defined
values
that
are
higher
than
that.
So
it's
effectively
a
must
yeah
and.
F
Yeah
and
to
be
clear,
the
current
state
is
that
five
is
the
threshold
for
any
case,
so
this
is
just
making
the
timer
more
strict
in
the
sense
that
for
non-isolated
contexts
we
are
increasing.
The
value
is
that
right.
A
A
A
So
there's
still
some
work
there,
but
essentially
we
have
like
for
this
issue
and
others
so
that
they
will
be
linkable
and
because
l2
is
already
in
rec.
We
we.
We
kicked
off
this,
like
as
an
editor
draft
for
l3
and
we're
hoping
to
turn
that
into
a
living
standard.
With
the
with
the
new
process,
a
new.
A
A
Okay,
so
so
there
are
a
couple
more
issues
but
yeah,
but
they're,
mostly
around
better
integration
with
other
specs.
A
lot
of
other
specs
were
referring
to
hr
time,
but
we're
doing
that
in
a
non
not
very
methodical
way.
So
we
we
need
to
enable
the
dom
spec
to
provided
access
to
raw
timestamps.
B
All
right,
thank
you,
everyone,
if
there's
nothing
else
for
hr
time.
We
can
move
on
to
the
next
issue.
B
This
one
is
around
visibility,
changing
sorry,
the
visibility
change
event
and
hidden-
and
I
know
michael
you
had
looked
at
a
little
bit
of
this
during
the
hackathon
a
couple
days
ago.
Was
there?
Do
you
want
to
do
follow
up
here?
Is
there
stuff
that
you
want
to
talk
about
today?.
C
I
could
quickly
so
philip
walton
originally
filed
this
issue
to
say
that
there
are
inconsistencies
between
browsers
and
platforms,
and
so
first
thing
that
spurred
activity
here
again
is
that
for
safari
somebody
submitted
a
patch
to
actually
fire
visibility,
change
events
on
navigations
on
safari,
which
is
great
because
they
were
the
biggest
outlier
and
I
double
checked.
C
The
current
status
under
chrome
and
mozilla
and
sort
of
phillips
original
table
for
about
a
year
ago
could
do
with
updating,
because
I
think
a
lot
of
browsers
are
doing
the
right
thing
so
for
chrome
on
desktop,
closing
a
tab,
closing
the
browser,
wouldn't
fire
visibility,
change
that
now
does
fire
correctly
and
then
chrome
mobile.
When
you
kill
android
or
kill
chrome
through
the
app
switcher,
it
previously
wasn't
firing,
and
I
think
I
have
a
strong
suspicion
that
visibility
change
is
being
fired,
except
that
the
way
we're
testing
for
it
isn't
working
like.
C
C
The
remaining
the
remaining
difference
on
safari
is
that
when
you
launch
the
tab
switcher
within
the
browser
or
the
app
switcher
within
the
platform,
it
will
not
fire
visibility
change
event,
and
it
could
be
that
this
is
just
a
simple
fix
that
they
will
appreciate,
but
I
think
there's
a
razuki
pointed
out
that
at
least
on
safari
video
will
continue
playing,
even
though
the
page
is
not
interactive
and
it's
kind
of
in
this
hybrid
state.
The
other
browsers
will
take
a
screenshot
and
and
pause
the
page
contents.
C
Okay,
I
I
thought
I
tested
it,
it
might
depend
on
the
type
of
video
or
what
the
page
does,
because
I
also
did
some
amount
of
testing
here
and
it
paused,
certainly
for
like
animations.
Maybe
video
specifically
has
some
sort
of
like
html5
video
might
have
some
specific
hole
punching
technique
either
way.
I
think
that
some
sites
might
use
the
hidden.
The
visibility
change
hidden
signal
to
perhaps
disable
animations
or
video
or
whatever,
and
so
this
is
not
an
entirely
visible
state,
but
firing
hidden
might
cause
behavior.
C
That
will
so
so
the
proposal
by
ryosuke
was
that
maybe
we
need
some
sort
of
third
non-interactive
type
mode,
so
I
think
that
they
are
perhaps
willing
to
fire
a
visibility,
change
event,
but
not
willing
to
change
too
hidden,
and
so
you
know
it
isn't
quite
visible,
but
it
isn't
quite
hidden
and
that
would
they
are
like
more
likely,
I
think,
to
keep
it
visible
in
order
to
not
break
page
previews
and
stuff,
like
that,
that's
my
read
on
the
situation.
C
Send
beacons
to
analytics
data
etc,
because
your
like
visible
interactive
session
is
now
over
and
it
might
get
unloaded
soon,
but
it's
not
quite
hidden,
so
you
shouldn't
disable
animations
or
just
pause
video
or
like
certain
certain
applications.
Don't
actually
support
background
play
or
are
they
for
resource
reasons?.
C
Yeah,
I'm
not.
This
is
just
the
state
of
the
bug
and
and
what
the
proposal
was.
I
don't.
Actually
it's
not
very
well
specter.
F
The
other
thing
is:
if
we
just
fired
it,
when
you
close
the
tab
from
the
app
switcher
after
you
like,
is
that.
C
From
the
tab
switcher,
it
wouldn't
be
a
problem,
because
the
browser
itself
still
has
it's
still
in
the
foreground,
and
so
it's
could
still
give
time
to
the
tab
contents,
and
this
is
how
desktop
browsers
do
it.
I
think
the
problem
is
that
when
you
launch
the
app
switcher
in
the
platform
and
then
swipe
away,
it's
unclear
whether
you'll
have
time
during
the
unload.
C
So
today,
on
android
in
both
firefox
and
chrome,
and
I
haven't
tested
chrome
on
ios
or
safari
on
ios,
but
when
you
launch
the
app
switcher
it
immediately
fires
visibility
change
to
hidden
because
you
might
swipe
away
and
kill
the
application.
And
then
you
might
not
have
time
to
fire
that
event.
At
that
point,
so
you're
sort
of
does
that
make
sense.
C
C
So
maybe
the
easiest
solution
to
this
problem
would
be
on
os
level
browser
killing.
C
F
F
G
There's
probably
also
cases
where
developers
are
not
checking
for
hidden
but
they're
checking
for
not
visible,
and
it
sounds
like
michael.
That's,
the
recommendation
you're
making
that
if
we
introduce
a
third
state,
the
recommendation
would
be
when
the
visibility
state
is
not
visible,
then
send
your
beacons,
rather
than
checking
explicitly
to
see
if
it's
hidden.
C
Exactly
and-
and
I
believe
this-
the
objection
from
webkits
sorry
folks
is
that
they
they
have
no
state
to
change
to,
and
they
don't
want
to
change
to
hidden.
G
Right
so
I
I
don't,
I
don't
describe
that
in
principle,
but
I
think
it's
important
to
bring
up
a
concern
that
I
believe
this
is
a
guess
based
on
intuition
that
if
you
look
at
most
of
the
code
on
the
web,
it's
not
saying
visibility.
State
is
not
equal
to
visible.
It's
saying
visibility
equals
hidden,
is
that's
the
condition,
and
so
all
of
those
pages
would
still
not
get
the
behavior
that
safari
wants.
A
Yeah,
it
seems
like
we
will
have
a
compatibility
issue
here,
regardless
of
if
we
go
with
the
third
state,
then
those
that
are
checking
for
not
hidden
for
or
not
visible,
for
example,
to
stop
video
will
still
stop
video
still
cause
of
breakage
that
you
know
undesired
breakage
by
by
the
tab,
switcher
and
the
other
way
around.
A
The
folks
that
are
looking
for
hidden
in
order
to
send
the
beacon
will
no
longer
like
they
will
no
longer
beacon
their
data
when
the
tabs
like
when
tab
switcher
is,
in
effect,
so.
C
But
the
other
browsers
could
just
not
use
this
non-interactive
state
for
for
a
long
while,
like
I
don't
know
that
we
need
needed
and
then
safari
in
cases
where
it
was
always
visible,
because
the
event
wasn't
fired
at
all
now
they
would
at
least
fire
an
event
with
a
new
state
which
you
know
sometimes
maybe
the
condition
is
not
checked
correctly
and
therefore
a
beacon
is
still
not
signed,
but
at
least
you
have
the
option
to
and
for
those
that
are
currently
written
to
say,
not
visible,
which
probably
is
the
you
know.
C
I
know
there
hasn't
been
a
tri-state,
but
the
whole
point
of
this
type
thing
is
that
a
long
time
ago
there
was
a
tri-state
right.
That
was,
I
think,
attempted
to
be
introduced
and
then
reverted
back
so
yeah.
We
could
look
at
the
data
and
I
still
don't
know
if
this
is
the
right
solution.
But
I
think
this
is
a
now
we
all
get
the
summary
I
get.
I
guess.
F
C
Yeah
so
I'll
just
say
that
on
android,
even
so,
I
think
the
problem
is
that
we
need
to
figure
out
what
we
can
get
away
with
on
ios,
and
I
haven't
even
looked
at
chrome
for
ios
how
it
does
it,
but
even
on
android,
both
firefox
and
chrome,
I
believe,
send
visibility
change
the
moment
you
launch
app
switcher,
but
if
you
kill
the
browser
fast
enough,
it
might
still
not
get
delivered
so
already.
There
is
it's
not
guaranteed
to
be
thing,
even
though
we're
doing
it
eagerly.
C
I
know
philip
reported
that
mozilla
always
gets
it
right,
but
I
found
cases
where
I
did
it
fast
enough,
where
even
in
firefox
it
wasn't
being
delivered.
So
I
I
know
we
can't.
We
can't
change
to
that
strategy
and
hope
to
be
as
effective.
C
And
I
don't
remember
the
state
on
safari,
but
there's
also
like
unload
events
and
some
of
those
are
being
dispatched
correctly
on
safari
in
some
of
these
cases
and
so
like
wherever
they
are
being
dispatched.
We
should
first
fire
visibility
change
to
hidden.
I
don't
know
philip.
If
you
remember
the
current
status
there.
G
I
don't
remember
off
my
head,
but
I
would
guess
so:
it's
related
to
bf
cache
where
safari
wouldn't
fire
unload.
If
the
page
was
eligible
for
bf
cache
and
that's,
I
think,
being
that's
the
same
direction.
That
chrome
is
going
as
well
and
it's
bf
cache
implementation.
D
Hey,
can
we
just
outline
the
acceptable
solution?
Space
for
ios
here
with
some
input
from
apple?
Is
a
tri-state
even
acceptable?
Do
we
need
at
exit
like
what
can
we
just
get
some
guidance
here.
E
I
haven't
been
following
this
as
closely
as
ryosuke
has
so
I
think,
I'm
unfortunately
the
wrong
person
to
answer
that.
I
I
personally
don't
think
a
tri-state
is
a
great.
B
E
But
I
don't
have
a
strong
opposition
if
there's
a
strong
consensus
for
it.
C
I
don't
I
wasn't
really
around
and
I
don't
recall,
but
when
I
read
it,
I
think
that
the
third
state
in
the
past
was
about
pre-loading
or
pre-rendering
and
not
about
this
non-interactive
type
mode,
and
then
I
think
it
was
put
in
or
it
was
suggested
to
be
put
in
sort
of
in
anticipation
of
use.
Where
never
actually
does
anybody
else
have
more
context.
A
Yeah
so
free
rendering
was
the
third
state
and
it
was
used
for
a
while
when
browsers
were
pre-rendering
content,
which
is
mostly
chrome
on
desktop
and
then
chrome
on,
desktop,
stopped,
pre-rendering
content
content
and
instead
move
to
use
the
link,
rel
prerender
hint
as
a
hint
to
prefetch
the
sub-resources,
but
not
actually
run
the
page,
and
then
the
third
state
became
irrelevant
and
I
believe,
removed
from
the
spec
one
complication
to
that
is
that
now
there
are
folks
in
chrome,
talking
about
reviving
pre-rendering
in
a
more
resource
like
in
more
resource-bound
and
privacy-preserving
way,
because
pre-rendering
had
a
couple
of
issues
both
with
the
consumed
resources,
as
well
as
with
the
fact
that
it
exposes
the
user's
ip
to
websites
that
the
user
hasn't
necessarily
navigated
to
just
yet.
A
So
now
there
are
conversations
about
re-enabling
pre-rendering,
which
may
or
may
not
revive
that
pre-rendered
state,
and
we
will
probably
need
to
discuss
that
as
well.
But
that's
potential
like
it's
a
separate
discussion.
A
And
yeah,
I'm
hoping
that
the
folks
that
are
talking
about
prerendering
would
hop
over
to
tpack
to
present
and
we
can
discuss
it.
Then.
G
A
Yeah,
assuming
that
sites
actually
take
all
those
states
into
account
and
yeah,
and
we
need
to
maybe
gather
some
data
on
that
front,
to
see
if
moving
from
an
effective
to
state
to
something
else,
is
web
compatible.
C
I
mean
it's
not
easy
to
know
from
context
what
you're
expecting
I
guess.
What
you'd
actually
want
to
do
is
look
for
how
many
not
equals
comparisons
versus
equals
comparisons.
There
are
right,
yeah
and
then,
based
on
the
context,
are
you
actually
interested
in
all
of
the
inverse
of
this
one
or
are
you
looking
for
just
the
opposite?
If
that
makes
sense,
that's
fair.
A
A
They
don't
they're,
not
semantically
different,
and
what
we
actually
need
is
for
people
to
do
it.
If
else-
and
you
know
do
something
when
visible
do
something
else
when
hidden
and
then
leave
the
different
tri-states,
but
no,
but
even
that
will
not
necessarily
work
because,
for
example
like
we
want
some
some
states
for
hidden
and
like
hidden
and
preview
or
non-interactive
or
whatever,
we
may
call
that
a
state
share
a
bunch
of
characteristics
that
we
want
to
maintain
and
visible
and
pre-rendered
also
potentially
share
a
bunch
of
characteristics
that
we
want
to
maintain.
A
B
A
B
A
A
On
the
one
hand,
it
would
be
interesting
to
see
like
if
some
videos
are
currently
stopping
when
going
into
the
app
switcher
tab
switcher
while
others
are
continuing.
Maybe
we
already
have
this
compatibility
problem
with
hidden,
maybe
we're
already
hitting
that
in
the
wild,
without
knowing
so.
C
C
A
Yeah,
so
I
think
we
need
to
investigate
that
part
more
and
collect
data
on
usage,
see
if
this
is
already
breakage
happening
in
the
wild
and
if
so-
and
we
haven't
noticed
this
so
far-
maybe
it's
reasonable
breakage
and
we
can,
you
know,
try
to
communicate
to
developers
of
you
know
a
better
path,
but
I
think
we
need
to
do
more
research
here.
D
Thanks,
michael
and
you
up
for
this,
this
I
felt
like
this
was
a
useful
discussion.
I
didn't
really
understand
the
pre-render
backstory
here
and
that
that
was
useful.
I
would
certainly
be
interested
in
hearing
more
about
that
at
tpec.
B
B
Okay,
the
last
one
was
something
that
I
found
recently
when
looking
into
cumulative
layout
shift
and
layout
instability.
So
this
is
layout
instability,
issue,
number
80.
B
So
if,
if
you
are
interested
in
measuring
cumulative
layout
shift,
you
certainly
could
have
content
within
iframes
on
the
page
that
you
care
about
and
that
content
could
be
shifting
and
you
know,
would
would
affect
the
you
know.
Visual
user
experience
the
spec
today
the
layout
and
stability
spec
today
proposes
that
iframes
should
contribute
to
their
parents
layout
cumulatively
outshift
score
as
far
as
the
proportion
of
the
size
of
that
iframe
within
the
viewport,
which
seems
logical.
B
In
practice,
one
of
the
concerns
I
have
is
actually
how
to
measure
this
consistently
through
rum
through
javascript.
So
today,
as
far
as
I
could
tell,
both
synthetic
tools
and
rum
do
not
account
for
iframes
at
all
in
their
layout
shift
scores.
So
in,
for
example,
lighthouse.
The
cls
score
today
is
not
affected
by
layout
shifts
for
my
frames,
even
though
the
like
diagnosis
below
may
tell
you
about
shifts
that
are
coming
from
those
iframes.
B
This
is
similar
to
a
problem
that
we
encounter
with
other
things
that
happen
in
iframes,
so
resources
that
are
fetched
from
iframes
long
tasks
that
happen
in
iframes,
etc,
where
in
order
to
actually
get
all
of
these
style
events
from
the
iframe
you
need
to.
You
need
to
try
to
do
things
and
in
some
ways
it's
almost
impossible,
so,
for
example,
for
cumulative
layout
shift.
B
It's
also
imperfect,
because
iframes
are
transient,
they
could
be
created
dynamically
or
get
deleted,
and
so
you
wouldn't
always
necessarily
be
able
to
get
the
full
picture
of
every
iframe
that
contributed
to
it.
On
top
of
that,
there
are
cross-origin
iframes
and
you
can't
actually
crawl
into
crossover
knife
frames
at
all.
B
So
I
guess
my
goal
as
a
synthetic
rom
provider
that
wants
to
help
measure
cumulative
layout
shift
is
to
be
consistent-ish
in
what
we
report
our
scores
to
what
other
tools
may
be
reporting
it.
So
synthetic
tools
may
be
reporting,
and
my
fear
is
that
if
we
can't
easily
measure
layout
shifts
from
iframes,
we
could
the
scores
and
what
we're
measuring
could
diverge
a
bit.
B
The
we
have
a
couple
kind
of
related
proposals
for
other
things
in
the
past.
That
may
help
here
so
there's
a
concept
of
a
bubbles
flag
for
performance
observer,
which
you
could
potentially
register
on
the
top
level
iframe
and
get
notifications
for
whatever
you
register
for
for
all
child
and
grandchild,
etc.
B
Iframes
on
your
page,
with
just
one
po
registered,
obviously
there's
probably
some
security
concerns
around
that
it
works
the
best
for
just
same
origin.
B
You
know,
I
guess
that's
kind
of
the
just
the
problem
statement
and
some
potential
solutions,
neither
of
those
two
solutions,
the
bubbles
and
opting
in
of
crossover
knife
frames.
We've
talked
about
them
in
the
past.
I
think
we
talked
about
one
of
them
last
tpack
and
possibly
the
other
one
see
back
before.
B
I
don't
think
they've
been
super
controversial.
I
think
I
think,
there's
just
been
not
as
much
clear
use
cases
besides
potentially
bubbling
resource
timing
data,
I
think,
with
layout
shifts,
maybe
as
another
use
case.
That
would
be
even
a
little
clearer
about
why
we
may
want
it.
So
I
just
kind
of
wanted
to
see
if
there
are
any
other
thoughts
on
what
we
might
be
able
to
do
here
and
or
if
it'd
be
worthwhile,
to
continue
the
discussion
on
those
two
other
proposals
to
help
make
this
potentially
better.
H
H
Port
of
the
iframe
in
its
spanned
frame
right.
How
is
the
portion
calif
by
area
by.
B
There,
I'm
not
an
expert
in
the
layout
shift
stuff,
so
maybe
nicholas
would
want
to
correct
me,
but
it's
there's
like
a
subweight
weighting
factor
is
the
definition
and
I
think
it's
basically,
you
know
pixel
weight
of
the
iframe
versus
pixel
weight
of
the
viewport.
H
Because
the
the
problem
is
that
the
iframe
might
be
partially
hidden
and
the
layout
shift
by
itself
might
change
the
weight
of
the
iframe
while
it's
doing
the
layout,
so
would
that
affect
the
weight
or
you
see
what
I
mean,
because
it's
possible
that
the
iphone
would
be
mostly
hidden.
I
guess
and
show
maybe
maybe
just
a
few
pixels
on
on
on.
H
B
In
this
case,
the
layout
shift
itself
would
be
happening
within
the
iframe
and
I
don't
think
it
would
be
affecting
the
where
the
iframe
is
in
the
parents
context.
So
I'm
saying
like
any
iframe
within
sorry,
any
shift
within
the
iframe
itself
probably
wouldn't
be
affecting
its
overall
position
within
the
parent
document.
H
But
it
would
affect
what
the
user
perceives
right.
The
user
perceives
the
layout
a
layout
shift.
Only
if
you
can
see
the
layout
shift
right
and
if
it's
not
visible
or
partially
visible,
then
it
should
not
contribute
to
a
layout
shift
at
all.
So
essentially,
what
I'm
saying
is
that
the
iframe
weight
should
be
what
the
portion
of
the
iframe
is
visible
to
the
user,
not
necessarily
based
on
the
iframe
size
right.
So.
H
H
F
H
F
B
Yeah
so
I
mean,
I
guess,
like
a
proposal
might
be.
If
we
had
access
to
a
bubbling
thing,
you
could
just
register
the
top
level
performance
observer
and
all
iframes
would
surface
up
their
layout
shifts,
and
maybe
ideally,
in
this
case,
the
top
level
or
the
iframe
would
say
what
portion
of
the
viewport
it
currently
held
for
that
frame.
B
But
at
the
end
of
the
way,
at
the
end
of
the
day,
getting
data
from
iframes
is
in
a
for
a
lot
of
these
performance
entries
performance
observer
type.
Things
is
a
challenge.
It
would
be
nice
to
have
it
be
a
little
bit
easier.
D
C
Nick
is
there
a
problem
with
iframes
within
iframes
and
bubbling
and
the
like
the
the
waiting
factor
per
frame?
So
I
wonder
like
if
it's
a
child
within
a
child,
is
it
a
factor
of
its
parent
or
of
the
ancestor
right
and
and
and
ultimately
perhaps
you
could
slice
up
the
viewport
into
the
frame
that
occupied
the
pixels
and
then
just
give
each
a
a
global
waiting.
I
I'm
not
sure,
though,
something
like
that
yeah.
D
F
In
there,
so
for
the
for
the
buffering,
I
guess
from
the
implementation
standpoint,
you
could
just
pass
the
existing
entries
from
the
other
frame
and
basically
format
them
into
whatever
api
shape
is
supposed
to
be
the
one
we
agree
on
for
the
bubbling.
So
so
I
don't
think
it
would
add,
increase
in
the
things
you
need
to
store.
A
F
Yes,
so
so
I
guess
the
if
the
developer
does
use
them,
then
they
would
incur
the
cost
of
basically
having
those
in
memory.
I
was.
B
Yeah-
and
I
would
like
to
be
clear,
there's
two
proposals
here:
one
is
for
bubbling,
which
would
only
be
for
same
origin
and
then
separately
to
find
a
way
for
to
allow
cross-origins
to
opt-in
as
well.
But
I
would
like,
like
those
are
two
separate
things
that
would
be
useful
to
have,
and
we
are
out
of
time
as
well
for
today.
F
It
would
be
great
if
other
folks
have
opinions
on
this.
They
can
chime
in
in
the
issue.
If
you
have
either
use
cases
or
user
agents
have
other
concerns
or
ideas
on
how
this
could
be
useful
or
ideas
and
how
it
could
be
implemented
in
a
reasonable
way.
B
Okay,
thanks
for
the
discussion
today,
everybody
appreciate
it.
Two
weeks
from
now
is
tpack.
Looking
forward
to
spending
time
with
you
all.
There.