►
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
It
so
when
we
explored
you
know
what
were
implementation
lessons
with
cls.
This
topic
came
up
as
something
that
kind
of
surprised
us.
It
took
us
by
surprise,
and
so
we
figured-
I
don't
recall
discussing
it,
so
I
figured
we
just
attach
it
alongside.
So,
hopefully
we
can
go
through
it
quick,
and
that
is
specifically,
you
know,
cls
layout
instability
has
this
input
exclusion
concept
and
it's
a
little
bit
tricky
to
get
right
necessarily.
A
Hopefully
it
should
be
pretty
easy,
so
as
background
the
layout
instability,
api
actually
reports,
every
single
layout
shift
for
every
single
animation
frame,
but
there
is
signal
about
had
recent
input
and
the
timestamp
of
the
most
recent
input,
alongside
those
events
and
cls
is
defined
to
filter
out
shifts
which
have
had
which
happen
immediately
after
an
input
event.
A
Okay,
so
in
the
spec
there's
mention
of
this
thing
and
so
sort
of
for
anybody,
who's
not
super
familiar,
I'm
sure
many
of
us
are,
you
know
the
the.
Why
of
it
is,
you
know,
cls
is
meant
to
measure
the
overall
amount
of
unexpected
layout
shift
and
shifts
which
come
immediately
before
user
input,
I
think
is
are
especially
concerning.
You
know
you
reach,
for
that
add
to
cart
button
and
it
gets
replaced
with
the
buy
now
button.
A
That's
a
bad
experience,
on
the
other
hand,
shifts
which
come
immediately
after
a
user
interaction
might
actually
be
fully
expected.
You
know
if
you
do
hit
that
add
to
cart
button
and
you
get
a
little
bit
of
dom
relay
out
because
there's
some
response
to
your
user
action,
that's
entirely
expected
makes
sense,
you
know.
So
what
counts
you
know
mouse
down
key
down
pointer
down
change,
but
not
gestures
that
initiate
scroll,
so
pointer
down,
followed
by
drag,
will
not
become
an
input.
Exclusion
flicks
that
sort
of
thing.
A
So
that's
what
counts,
sort
of
district,
discrete
events
and-
and
I
know
very
early
on-
we
included
another
consideration
which
is
resizing
the
viewport
right.
It
makes
sense
that
when
the
user
resizes
their
window
open
something
like
devtools,
this
would
cause
an
expected
relay
out
and
move
things
around.
A
So
this
is
not
an
interaction,
but
it's
still
the
shifts
that
happen
in
response
to
a
layout
change
report
as
though
they
had
a
recent
input.
That
is
how
it's
implemented,
and
so
we
learned
over
time
that
there's
actually
lots
of
these
other
types
of
interactions
where
they're
not
really
interactions
with
the
renderer.
It's
not
the
user,
interacting
with
the
page
content,
but
it's
the
same
spirit
of
the
thing.
So
one
feature
that
the
browser
has
is
zoom.
A
You
know
you
could
zoom
in
the
the
contents
of
the
page
in
chrome
and
I'm
sure
other
browsers,
there's
actually
multiple
ways
of
doing
it.
You
could
sort
of
pinch
zoom
where
you
have
like
a
drag
draggable
thing.
It
doesn't
cause
a
relay
out,
but
you
could
also
change
the
device
pixel
ratio
where
things
relay
out
to
be
larger
and
that
is
an
intended
layout
shift
that
the
user
introduces
there's
a
translate
feature.
A
So
if
you
go
to
a
non-native
language
site,
you
might
be
prompted
by
the
browser
to
translate
and
it
actually
does
like
text
replacement
and
that
will
cause
things
to
resize
and
then
therefore
shift
around
and
it
happens
after
the
user
asks
for
this,
and
so
it
is
an
expected
set
of
layouts
just
clicking
back
forward
buttons
in
browser
ui.
The
page
can
handle
that
with
history,
api
and
then
cause
an
expected.
A
You
know
layout
ui
change
if
you
click
a
blue
link
within
the
the
tab
cont
like
within
the
web
contents,
or
if
you
hit
a
back
button
that
calls
history.back
that
will
naturally
get
excluded,
because
there
will
be
an
interaction,
but
if
you
interrupt
the
browser
that
wouldn't
normally
get
caught,
so
we
have
to
sort
of
plumb
that
through
this,
isn't,
I
think,
implemented
in
chrome
yet,
but
we
at
least
thought
of
this.
But
you
know
system
notifications.
A
If
you
use
push
messaging
and
then
native
notifications-
and
you
have
a
net
native
notification
fire,
the
user
clicks
the
notification,
the
website
gets
that
event.
There
therefore
causes
some
sort
of
ui
change
in
response.
You
know
it's
a
very
roundabout
path,
but
it's
a
direct
layout
that
was
induced
by
the
user
action.
A
There
are
also
features
like
find
in
page,
so
find
in
page
typically
will
only
scroll
the
contents,
which
isn't
typically
an
exclusion
event
but
find
and
page
can
actually
match
hidden
text
content
and
expand,
collapsed
elements,
and
so
there
could
be
shifting
going
on
that
happened
because
the
user
was
doing
this
thing.
A
You
know
sort
of
niche
sort
of
rarely
found,
but
it
does
pop
up
and
the
other
two
that
came
up
often
for
us
was
you
know:
visibility,
changes
and
b
of
cache
at
various
historical
points
in
the
chrome
implementation,
the
very
first
frame
after
a
tab
becomes
visible,
might
be
visually
different
than
the
last
time
it
became
backgrounded
or
not
visible
or
out
of
b
of
cache,
and
so
we
don't
have
a
500
millisecond
exclusion
window,
but
that
very
first
frame
should
be
ignored
for
cls
purposes.
A
You
know
you
can
imagine
in
the
background
constant
updates.
I
I
put
in
an
example
like
a
calendar
or
a
weather
app
or
something
like
that.
A
It's
not
even
visible
too,
because
if
there's
an
arbitrary
amount
of
time
with
the
contents
not
being
visible,
and
then
it
becomes
visible,
it's
not
going
to
cause
a
visible
shift
and
I
believe
that's
it
so
yeah.
We
think
all
of
those
are
in
the
same
spirit
of
the
original
intention
behind
exclusion
windows.
A
And
there
probably
are
more
that
we
haven't
found
yet
so
we'll
keep
reporting
them.
There's
an
issue
filed
that
this
hasn't
been
added
to
spec,
or
at
least
not
all
of
these
have
and
so
issue
110
tracks,
a
bunch
of
these
that
I
mentioned
today
and
we
can
keep
adding
them.
Maybe
folks
have
other
ideas
or
immediately
some
use
cases
pop
to
mind.
So
let
us
know-
and
I
think
that's
it.