►
From YouTube: WebPerfWG call - March 26th 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
A
Do
we
have
a
volunteer
for
scribing
I,
already
started
a
bit
so
Oh,
awesome
and
I?
Don't
know
if
you
all
saw
the
email,
but
Nick
is
stepping
up
to
serve
as
a
co-chair
for
the
working
group,
so
congrats
Nick
and
looking
forward
to
continuing
to
work
together
like
awesome
times
ahead.
Yeah.
Thank
you.
I
am
here
to
serve.
A
A
A
A
C
A
A
C
A
A
B
Well,
so
I
started
pointing
out
the
issue
that
what
happens,
if
the
page,
just
at
a
by
frame
and
then
that
malting
to
discussion
about
cross,
lodging
iframes
the
problem
is
I
think
maybe
we
should
retitle
that.
But
the
problem
is
that
the
no
evocate,
the
painting
initial
painting
times
gated
by
main
frames
content.
So
if
the
iframe
can
figure
out
well,
the
initial
painting
time
is,
and
they
can
basically
it
leaks.
The
information
about
main
frames
content
is
what
it
is.
A
E
E
A
B
E
C
Yeah
I
suggested
a
model
where
you
could
query
for
the
current
document
or
window,
whether
first
content,
full
paint
would
be
available
for
that
window
and
then
for
my
and
I
think
it's
okay,
if
different,
browsers,
decide
on
different
security
parameters
for
what,
for
which
window
is
allowed
to
send
first
to
mark
first
contention
flying
paint.
So.
E
B
C
I
would
say
that
we
should
mention
that
the
supported
entry
types
is
a
is
valid
for
the
current
browsing
context
and
and
that
a
it
doesn't
guarantee
that
it
will
be
supported
for
other
browsing
context.
We
can
discuss
like
the
the
exact
wordings
and
pull
request
if
we
agree
on
the
general
direction.
E
C
E
B
A
A
A
B
B
The
first
content
full
paint
because,
like
it's
not
great,
if
website
made
the
first
thing
fast
at
the
cost
of
making
the
first
content
for
paint,
so
so
I
think
that's
an
ad
argument,
which
is
that
it
will
be
more
clear
to
just
deport
the
OP
matrix
that
people
should
be
optimizing
for,
but
additionally,
in
case
of
WebKit
like
they
should
really
be
same.
If
their
different
kind
of
that's,
we'll,
probably
consider
as
a
bug.
E
Both
of
them
make
sense,
I
do
understand
the
concerns
from
work
it,
but
I
do
think.
First
paint
has
some
value.
No,
almost
no
very
of
you
already
use
first
content
for
paint
other
like
the
time.
Basically,
when
it's
similar
to
the
time
when
you
have
finished
parsing
the
document
and
like
F,
your
first
rendering
legs
I
call
ready,
I.
E
B
C
C
A
A
Mean
well,
it
seems
cleaner
to
split
them.
The
main
question
would
be
from
compatibility
it
from
a
what
compat
perspective.
What
will
we
like?
We
can
support
paint,
I
guess
like
continue
to
support,
paint
and
then
deprecated
it
as
the
entry
type
on
which
people
register
and
just
translate
it
to
you
know
two
registrations.
E
Worried
like
would
we
ever
be
able
to
deprecated
paint.
It
is
very
widely
used,
and
so
I
worry
that
it
would
like
I
agree
that
from
like
the
perspective
of
looking
at
it
from
as
if
it's
like
a
new
API
yeah
I
mean
I,
think
it
makes
sense
to
have
the
two
entry
types.
But
if
chrome
were
to
implement
this,
then
we
would
definitely
need
to
support
both
ways.
And
it's
not
clear
to
me
if
we
would
be
able
to
deprecated
the
other
way.
So
it
feels
comes
here.
I
I
just
wanted
to
ask
what
need
there
is
to
do
feature
detection
so
from
our
developer
perspective
on
Wikipedia,
for
example,
we
asked
for
the
paint
timing
and
we
know
that
the
array
might
or
might
not
contain.
First
contentful
paint
like
it
contains
zero
or
more
entries
as
far
as
I
know,
some
of
which
will
have
a
name
of
first
thing,
some
of
which
will
have
a
name
of
first
contents
of
things.
Older
chrome
didn't
have
content
for
paint
either,
so
we
know
that
both
of
those
are
optional,
at
least
for
me,
as
a
developer.
I
I
didn't
think
that
aspects
that
they
were
both
mandatory
I
only
realized
that
relatively
recently,
what
kind
of
breakage
do
we
expect
if
first
paint
were
to
be
missing
from
that
array
like
the
way
the
API
works
is
like
it's
just
a
flat
array:
there's
not
like
a
key
value
pair
where
someone
you
could
accidentally
expect
the
key
to
exist.
So
I'm
kind
of
curious,
like
what
kind
of
code
do
we
foresee
where
like
it,
could
actually
break
I.
E
I
And
to
say
that
the
API
is
quite
nicely
designed
in
that
that
you
start
listening
for
something
and
you
get
an
array
of
any
entries.
There
could
be
entries
here
that
you
don't
recognize
and
it
could
be
so
many
is
not
in
there.
It
does
make
it
a
little
bit
harder
to
use
and
I
know
then
compared
to
the
old
maps
on
the
interface.
We
just
have
nice
key
value
pairs,
that's
very
simplistic,
but
it
also
requires
everything
to
exist.
Upfront
and
I.
I
B
A
With
my
chromium
head
on
I,
don't
think
that
we're
saying
that
this
is
impossible
to
change,
because
it's
currently
shipped
and
we
can
definitely
figure
out
a
way
to
migrate
from
the
current
API
to
a
more
desirable
future
API.
But
at
the
same
time
there
is
a
cost
and
from
what
I'm
hearing
across
the
like
the
room,
the
virtual
room
is
that
the
youth
like
there
is
no
clear
use
case
for
a
feature,
detection
that
this
breaking
change
will
enable
and.
E
I
want
to
add
to
that
that
I
don't
think
it's
fair
to
say
that
we're
posting
changes,
because
we've
made
a
bunch
of
spec
changes
that
we
are
not
compliant
with
regarding
the
definition
of
content.
For
so
we
will
need
to
change
our
implementation
for
that,
but
this
is
a
much
more
breaking
change
and
I
don't
see
the
value
being
like
much
higher
than
the
actual
cost.
So
that's
that's
what
I'm
concerned
with
in.
D
C
What
to
expect
like
you
got
your
you
know
not
to
expect
first
paint,
for
example,
if
you
know
it's
not
coming
like
I
I
can
imagine
code.
That
would
expect
first
paint
and
then
first
contentful
paint
like
yeah.
You
would
want
a
way
to
know
not
to
not
expect
that,
but
to
expect
something
different.
However,
I
don't
find
it
crucial.
B
See
that
that's
the
part
I
would
objective
I.
Think
if
you're
saying
that,
like
we
don't
want
to
change
the
type
because
there's
some
compact
concern
for
one
browser
that
just
shipped
this
API
and
that
in
the
future
we
can
add
a
separate
mechanism.
I
would
object
to
that
like
I,
don't
think
we
should
do
it
if
it's
the
case
that
there
is
any
case
or
any
breakage
where
websites
need
to
be
able
to
detect
those
two
cases,
we
should
be
changin
type,
not
adding
round
or
new
way
to
feature
detect.
Okay,.
A
Yeah
for
what
it's
worth
I
agree
that
if
we
would
want
to
feature
the
takt,
it's
better
to
go
ahead
when
the
current
feature
detection
mechanism
and
figure
out
a
plan
to
do
whatever
it
takes
to
make
sure
that
it
won't
become
a
compatibility
concern.
But
at
the
same
time
I
don't
really
see
a
need
for
a
user
detection
and
I.
Think
that
we
have
a
clear
signals
from
folks
in
the
room
that
actually
use
the
API,
that
it's
not
something
that
they
ever
thought
was
needed.
Is
that
a
correct
yeah.
B
F
Other
types
like,
for
instance,
I
I,
was
talking
about
this
in
Bugzilla
entry,
but
I,
but
we
have
a.
We
have
two
metrics.
We
have
a
first
paint
and
we
have
a
full
paint
and
we're
thinking
of
adding
the
first
contentful
paint.
So
with
that,
allow
us
to
add
first
paint
and
full
paint
as
optional
here
I.
C
Think
I
I
think
I
was
I.
Wasn't
the
thought
that
everybody
should
have
their
own
paint
timing
names,
but
I
think
it's
if
you
want
to
add
full
paint
that
it's
defined
in
the
spec,
what
it
means
it's
same
way.
We
did
for
first
contentful
paint
that
now
it
first
content
full
paint
is,
is
defined
rigorously
like
this
is
what
it
means.
Then
we
can.
We
can
agree
on
it
and
it
can
be
an
interoperable,
a
definition
rather
than
a.
A
Yeah,
but
so
I
agree
that,
if
yeah,
if
most
lot
wants
to
add
a
third
paint
metric
to
this,
it
would
make
sense
to
like
specify
the
same
way
that
we
now
did
for
first
contentful
paint,
but
from
an
API
shape
perspective.
It
seems
like
something
that
can
be
just
exposed.
Similarly
to
the
other
two
yep
I'm
Peter
yeah.
H
Also
just
to
be
seen
from
the
development
perspective
we
expected
in
any
case,
as
some
of
the
other
people
here
in
the
room
have
said
we
expected
that.
Certainly
some
versions
might
have
first
paint
some
others
might
not
so
I
just
want
to
say
that
I
also
agree
with.
We
can
continue
on
with
what
we
have
and
yeah
we'll
see
what
the
compatibility
types
later
on.
A
Okay,
so
do
we
have
agreement
to
make
first
thing
optional
in
the
spec
and
can
we
move
on
to
the
next
issue.
F
A
B
Well
sure
yeah!
Well,
it's
breached
by
four,
which
is
that
thing
whether
well
first
of
its,
we
have
to
first
figure
out
what
the
viewport
means
right.
There
are
many
different
kinds
of
pupils
we're
talking
here
like
I,
have
you
bought
visual
people
and
so
on
and
so
forth,
and
a
second
of
detecting,
whether
something's
in
a
beep
or
not,
is
not
easy.
It's
actually
pretty
tricky
to
do.
Although
the
intersection
observer
defines
some
agency
to
decide
what
happens
there,.
B
So
I
think
the
question
is
I.
Think
the
there
was
discussion
about
will
consider
things
that's
outside
of
viewport
as
a
portal
for
spent
anyway.
But
then
there
are
cases
where
webpage
you
have
a
content
for
accessibility
purposes.
For
example,
it
was
very
common
technique
to
have
the
text
of
the
name
with
the
negative
I,
don't
know
negative
thousand
Peaks
text,
indent
or
whatever,
to
have
a
text
and
then
pulling
the
background
image
so
pulling
the
hero
image
the
background
image.
So
in
those
cases,
if
the
text
is
drawn
there
like
you,
don't
you
see?
B
E
C
I
C
A
E
We
want
to
do
I,
think
that,
like
since
you
are
opposed
to
using
an
undefined
viewport,
we
shouldn't
talk
about
the
viewport
at
all,
because
we're
not
going
to
define
it
here
right
so,
like
I,
think
the
clipping
with
the
scrolling
area
is
sufficient.
Clarification
that
things
that
are
not
within
the
documents
for
scrolling
area
will
not
count,
whereas
anything
that
does
clip
with
scrolling
area
counts,
Kendrick
and
potentially
counters
counted
as
content
for
and
there's
no
need
to.
Like
reference,
the
nuclear
at
all
I
mean.
B
I
I
agree.
The
current
score
over
here
is
a
precise
definition,
but
I
don't
think
it
necessarily
means
that
we
don't
have
to
consider
a
viewport
I
mean
I,
think
we
got
to
collectively
decided
vport
right
irrelevant,
but
I
don't
think
it's
anyway,
inherently
clear
that
we
don't
want
to
consider
a
viewport
right
like
if,
if
the
pain
happens
and
the
user
don't
see
anything
because
things
like
I
painted
it
was
completely
outside
pupil.
Is
that
really
still
useful
to
count
as
a
first
paint
and
first
content
for
paint
Oh
to
be
fair?
B
There
there's
a
one
argument
to
be
made
for
ignoring
people,
which
is
that
the,
if
you
consider
viewport,
then,
depending
on
the
size
of
the
users
window
and
which
part
user
is
scrolled
to
the
matrix
of
first
and
first
matrix
of
first
pane
of
first
content
pane
will
be
affected
right
because,
if
the
user
happens
to
know
include
the
content
that
gets
painted
very
you
know
at
the
very
beginning.
It
will
report
that,
like
later
when
we
some
other
content,
gets
Benedict.
H
B
If
you
did
only
consider
the
global
routes
global
area,
then
things
in
a
root
box,
that's
rural
area,
then
it
will
be
more
consistent,
different
window,
size
and
so
forth.
So
that's
I
think
one
benefit
of
going
with
the
scrub
area.
I
think
they
yeah
I
mean
I.
Think
maybe
the
the
people
who
are
using
this
metric
can
comment.
You
know
give
us
some
feedback
about
that.
I
Suppose
I
could
say
something
yeah
I
think
interesting
consideration
like,
for
example,
do
we
want
to
punish
websites
if
I
open
them
on
a
very
small
screen?
If
we
include
the
viewport,
that
means
kind
of
a
paint
might
never
happen,
because
the
content
is
outside
what
I
can
see
so
I?
Guess
it's
a
distinction
between.
Do
you
wanna
say
it's
when
the
first
content
is
available
to
the
user
or
is
actually
visual
to
the
user?
I
Yeah
there's
are
two
very
different
directions:
I
guess
it
is
intuitive
for
the
user
to
see
it,
that's
kind
of
what
you
would
first
expect,
but
it
also
means
that
it
would
be
okay.
I
would
like
to
hear
from
the
browser
vendors
on
this.
Like
is
it?
Would
it
be
very
expensive
to
have
to
compute
whether
something
is
individual
viewport
that
presumably
would
potentially
have
non-trivial
cost
right?
Look
that
might
be
a
deal-breaker
either.
It's.
C
Already
computed
for
intersection,
observer
and
and
a
the
way
to
specify
that
I
can
imagine
would
be
to
say
a
first
continent.
Full
paint
would
be
a
at
the
time
where
a
contentful
element
intersects
with
the
viewport
in
the
same
way
as
intersection
observer.
The
intersection
observer
would
work
right.
D
I
think
it
starts
being
being
really
weird
when
you
think
about
what
happens
after,
like
if
something
pates
outside
of
you
port
and
that's
the
only
thing
then
does
that
mean
that
we
have
a
first
intent,
full
paint
when
the
person
Scrolls
to
it,
and
then
that
becomes
like
a
metric,
that's
dependent
on
user
action
which
really
sucks
when
you're
trying
to
compare
sessions
between
users.
Sometimes
it's
something
that
was
an
event
of
their
action.
It
happens
to
be
inside
of
you
port,
and
sometimes
they
had
to
wait
until
the
scroll
to
it.
D
A
B
A
C
B
B
G
A
C
C
I
Yeah
I
just
wanted
I
do
think
it's
it's
true.
That
website
should
be
punished
if
they're,
showing
stuff
out
of
the
viewport,
and
that's
the
only
thing
they'd
ever
see.
That's
probably
something
we're
optimizing
for
and
highlighting
in
some
way
to
developers,
but
maybe
not
as
part
of
this
API
I
think
that
would
complete
different
purposes
too
much.
D
D
Knowing
which
element
got
painted
with
the
first
potential
paint,
that's
like
an
old
idea
like.
Maybe
you
would
like
to
do
that
at
some
point.
But
if
you
had
the
attribution,
then
you
could
look
up
where
the
element
is
compared
to
viewport
effective
as
a
developer,
you're
interested
in
knowing
was
that
actually
interview
or
not.
D
E
Okay,
the
issue
I
was
I,
noticed
there.
So
I
also
a
note
that
says:
I
quote
as
a
general
rule.
An
element
is
paintable.
If
it
is
within
the
viewport,
it
can
potentially
be
in
the
viewport
as
a
result
of
scrolling
and
or
zooming.
Although
it's
a
non-normative
note
so
I
guess.
My
question
is
what
else
is
missing
to
close
this
issue?
I,
don't
want
to
close
in
myself.
Obviously,
but
I.
B
E
I,
don't
think
there's
up
here,
I
I
think
the
the
note
that
I
read
like
is
kind
of
useful,
but
if
we're
really
opposed
to
having
a
mute
boarding
and
non
normative
notes,
then
we
can
close
it
because
I
guess
and-
and
there
is
one
mention
outside
of
non
normative
notes.
So
we
should
definitely
remove
that
one
as
well.
E
A
B
E
A
B
A
C
C
E
Was
actually
suggested
by
Marcus
from
Mozilla,
so
I
wonder
if
mostly
like
and
comment
on
whether
they
would
be
fine,
including
that,
because,
right
now,
from
the
code
that
Marcus
sent,
the
texts
that
is
transparent
is
excluded
from
the
list
of
painted
elements
or
something
like
that.
So
I
don't
know
if
it's
feasible
to
just
include
them
like,
and
then
that
way
Mozilla
would
be
able
to
implement
the
first
content
for
paint,
including
those
as
well.
C
E
A
It's
very
hard,
but
that,
like
it's
potentially
hard
for
users
to
distinguish
between
text
that
is
completely
opaque
to
text
that
is,
you
know,
has
a
opacity
value
of
zero
zero.
One
or
text
that
is,
you
know,
has
very
low
contrast
compared
to
its
background,
so
it
might
be
easier
to
skip
all
that
and
I
think
Rios
Keys
comment
about
the
text.
Selection
actually
makes
a
very
good
point,
because
this
text
is
eventually
visible
to
the
user
or
you
know:
potential
use,
they're,
visible.
B
I
What
a
sort
that
can
also
imagine
certain
games
using
invisible
text,
maybe
something
that
only
because
of
all
the
speech,
readers
and
things
like
that.
Yeah
accessibility
is
also
important
in
that
regard.
So
I
can
see
the
argument
for
things
that
are
nearly
invisible
like.
Why
would
be
treat
those
differently?
It's
the
same
to
the
user,
who
can
see.
B
Yeah
but
I
think
in
a
case
people
put
the
textbook
sweetie.
They
usually
put
it
off
screen
right
so
that
that
yeah
I
think
that
might
be
a
side
different
case,
but
yeah
I
to
be
here
I,
don't
necessarily
feel
strongly
either
way.
I
I
have
to
talk
to
my
colleagues
and
see
if
any
of
them
that
was
some
strong
opinions,
but
I
think
this.
This
is
sort
of
like
interesting
edge
case
to
consider.