►
From YouTube: WebPerfWG May 16th 2019
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
B
A
B
A
A
A
If
you
folks
can
be
there
or
can't,
like
generally
I,
send
out
the
registration
form,
it's
also
linked
from
the
agenda.
If
you
can
make
it
or
can't
make
it
please,
let
me
know:
I
will
I
wanted
to
set
up
an
agenda
table
before
this
call.
I
will
set
up
an
agenda
talk
and
then
it
would
be
great
to
start
collecting
ideas
regarding
various
proposals
or
various
web
performance
related.
A
So
I'll
set
up
a
document
link
it's
from
here
and
then
I'd
love
to
have
some
some
ideas
from
you
up.
There
I
think
that
the
the
call
can
generally
focus
more
on
new
proposals
and
higher-level
themes,
rather
than
just
issue
try
ash
because
going
over
the
issues
today,
it
seems
like
that
on
the
issue
front,
what
we
need
is
more
work.
E
A
Hope
so
yeah
the
forum
also
includes,
like
an
option
of
I,
can
participate,
participate
remotely
I
will
figure
out
what
the
logistics
folks,
if
remote
participation
will
be
I'm
guessing
we
can
enable
it
any
way
with
using
laptops
but
I'm,
hoping
that
the
room
will
facilitate
something
better
than
that,
but
I'll
figure
it
out.
Thank.
G
B
I
suggest
an
end
to
it
go
for
saying
we
also
have
a
number
of
people
on
the
call
from
industry
representing
various
large
properties.
But
if
you
know
any
others
that
have
that
might
be
good
to
hear
from
in
terms
of
what
the
needs
are
in
terms
of
work
performance,
what
the
gaps
are
we'd
love
to
get
them
to,
even
if
they
can't
dial
in
and
just
present
and
talk
about
what
the
group
should
be
thinking
about.
B
I'd
love
to
use
this
face-to-face
as
more
of
a
future
looking
as
opposed
to
down
in
the
weeds
and
debating
things
that
we've
already
been
debating.
So
if
you
have
any
leads
for
who
those
people
could
be
or
should
be,
either
maybe
send
them
a
link
to
this
or
ping
us
and
maybe
we'll
reach
out
to
them
and
see
if
they'd
be
willing
to
present.
G
G
A
G
G
A
G
Let
me
try
to
make
it
I
start
at
and
you
guys
feel
free
to
shoot
me
down
quickly,
so
I
mean
we
all
know
that
the
state
of
privacy
underwear
been
an
ongoing
concern
and
he's
been
growing
more
and
more
lately
so
high-resolution
time
with
his
low
resolution,
timer
allows
for
more
fingerprinting
substantially
right
now.
The
specs
is
vague
about
that.
Well,
this
is
a
reverse
resolution
that
you
must
provide.
G
Basically,
you
should
not
have
a
low
resolution
and
use
a
resolution
of
the
data
at
the
data
object
in
JavaScript
or
whether
you
should
put
the
whole
things
between
the
feet
behind
the
ctrio
policy
and
whether
or
a
punishing
API
and
and
and
and
whether
you
know,
and
if
you're
going
to
do
that.
This
is
how
you
should
do
it
so
I
know
that
most
of
the
implementers
around
this
table
are
not
really
interested
in
doing
that.
A
A
Genuine
concern,
I
think
that
the
general
concern
with
the
with
high
resolution
timers
is
not
really
around
fingerprinting,
but
around
data
linkage,
which
is
yes,
something
that
we
have
addressed.
I've
also
recently
following
Mozilla's
comments
added
a
list
of
potential
mitigations
by
implementations,
so
not
just
coursing
but
also
jitter,
as
well
as
at
least
one
more
thing
that
I
will
remember
in
a
minute,
but
basically.
A
A
I
also,
don't
think
that
that
proposal
is
particularly
web
compatible
at
the
same
time.
Browsers
that
are
privacy
focused,
can
corson
that
API
to
whatever
level
the
day,
see
fit
or
jitter
it
or
like
they
are.
If
they
are
willing
to
take
the
compatibility
hit,
they
are
free
to
put
it
behind
a
permission,
flag
or
somehow
otherwise
limit
it
in
third-party
context,
even
though
I
would
claim
that
it
doesn't
really
make
sense,
because
it's
irrelevant
to
the
threat
model,
but
they
could
nothing
is
preventing
implementers
who
wish
to
do
all
those
things
to
do
them.
A
G
You
were
doing
great
until
you
said.
If
then,
we
need
to
take
the
compatibility
hit
so
you're
right.
The
added
jitter
is
in
the
spec.
Already
we
have
a
clock
resolution
resolution
section
in
the
spec
and
that's
fine.
The
content
I
think
is
kind
of
like
well.
So
if
you,
if
you
don't
want
to
give
any
any
data,
what
should
you?
What
should
you
do?
G
Should
you
basically
only
support
the
old
API
and
not
report
any
timing
entry
at
all,
and
would
that
be
considered
to
be
again
the
specification
to
not
report
a
navigation
timing,
entry
in
the
performance
timeline
or
is
it
something
else
so
the
question
is:
can
I
fly
that
so
well?
Here
is
a
question
for
you.
So
so
is
it
okay
to
not
report
a
dedication?
Timing,
entry
in
the
performance
timeline.
G
B
Sure,
but
once
the
implementation
can
choose
to
apply
any
of
the
methods
that
you
of
mentions
to
like
Corson,
the
granularity
in
jitter
do
whatever
they
want
to
do
so.
As
a
concrete
example,
Safari
chooses
to
throttle
or
clamp
I
guess
not
wattle
the
resolution
to
one
second,
which
is
equivalent
of
what
you
get
from
dates
today.
G
A
B
A
That's
not
really
like
it.
How
you
get
to
that
information
is
not
really
relevant.
If
you
don't
want
to
expose
that
information,
you
can
say
I
don't
expose
anything
that
real
not
like.
If
you
want
to
say
my
browser,
doesn't
support
HR
time
rather
than
just
clamp
it
to
the
same
value
as
date.
Knob
now
I
am
not
supporting
it
at
all.
Then
you
can
not
support
like
all
of
the
api's
that
rely
on
that,
claiming
that
you
support
them
and
then
provide
zero
entries
for
everything.
I,
don't
see
why
you
would
do
that.
G
A
A
A
G
A
G
B
D
G
Actually,
you
should
give
up
Schaffer
says
to
a
fully
synchronous
decision.
We
should
given
10
working
days
after
the
publication
of
the
resolution,
so
you
should
recall
the
resolution
in
the
minutes
and
send
it
to
the
public
list,
and
people
will
have
10
days
to
object
to
that
resolution,
because
I
want
to
okay.
A
There
are
a
lot
of
them.
Some
some
specs
are
really
close
to
being
like
in
a
almost
good
shape.
With
a
you
know,
a
small
number
of
open
issues,
others
have
a
larger
number
of
open
issues.
I
and
I've
been
personally
driving
down
the
open
issues
on
some
of
those
specs,
but
I
would
love
to
have
more
folks
involved
in
general,
like
for
the
spec
that
have
like,
let's
say
over
10
open
issues.
A
lot
of
them
are
things
that
can
be
easily
like.
B
A
B
A
A
E
A
B
B
A
Sure
so,
basically
preload
then
resource
hints
are
on
me.
If
we
look
just
look
at
the
list
of
repos
that
have
more
than
ten
open
issues,
so
preload
and
resource
hints
or
on
me
and
I
need
to
work
on
that
just
as
soon
as
I
will
get
a
performance
timeline,
resource
timing,
a
navigation
timing
out
the
door,
long
tasks,
I
believe
also.
So
we
have
long
tasks
and
paying
timing
that
I
don't
know.
If.
A
A
A
I
This
one,
partly
it's
that
I
fell
behind
over
the
last
couple
of
months,
having
shifted
from
one
company
to
another,
but
I'm
back
and
I
also
recruited
one
of
my
former
colleagues
from
Google
to
sort
of
help
out
with
triaging
and
stuff,
like
that
and
I
think
he
actually
just
joined
the
working
group
within
the
last
couple
of
days.
Yeah.
D
I
He's
planning
on
attending
the
face-to-face
in
June
as
well
so
hopefully
over
the
next
week
or
two
we
can
sort
of
go
through
this
backlog
cleared
out
a
bit.
There's
also
been
a
relative
state
of
new
open
issues,
just
in
the
last
couple
of
weeks,
because
Firefox
has
Mozilla
has
started
looking
at
this
again,
and
so
they
opened
up
some
issues
just
as
far
as
going
through
the
standards
position
process
where
yeah.
A
Okay,
awesome
so
very
happy
to
hear
that
you're
back
in
business
and
yeah
and
I
think
that
yeah.
Regarding
the
other
issues,
one
idea
that
came
up
was
to
have
some
sort
of
a
hackathon
for
interested
in
willing
folks
to
stick
around
for
a
day
after
the
face-to-face
and
drive
down
that
list
and
remove
some
of
the
low-hanging
fruits
from
it.
C
A
C
A
Yeah
but
I
think
that
yeah
we'd
have
enough
material
to
yeah
just
up
folks.
You
know
some
divide
and
conquer
the
different,
like
the
different
issue,
lists
and
trim
them
down
to
a
substantial
extent,
so
I
think
they'll
be
good
cool,
but
yeah
I'll
send
a
proposal
to
the
list
and
we'll
see
how
many
folks
sign
out.
A
H
Basically,
the
problem
is
that
there
was
some
feedback
that
it
might
make
sense
to
do
a
registration
list
instead
of
having
a
registration
hook.
So
the
difference
is
that
with
the
list,
you
have
all
the
entry
types
in
performance
timeline
and
it
would
be
up
to
the
implementer
to
actually
ensure
that
that
list
is
up
to
date
whenever
they
implement
new
entry
types.
The
idea
for
the
registration
hook
was
that,
having
that
in
the
specs
would
make
it
easier
for
implementers
to
notice
when
they
should
be
updating
supported
entry
types.
H
A
So,
for
example,
if
we
have
a
new
version
of
performance
timeline,
you
could
have
implementations
that
pass
all
the
tests
other
than
the
ones
for
the
entry
type
that
they
don't
yet
support,
which
then
we'll
have
to
manually
figure
out
instead
of
just
you
know,
having
the
failing
tests
be
failing
on
the
not
yet
implemented
spec
rather
than
on
the
performance
timeline
spec.
If
that
makes
sense,.
B
So
that's
an
important
point
from
a
strict
process
perspective,
at
least
with
respect
to
how
the
group
operates
it
a
and
really
please
jump
in
here.
I.
Don't
think
this
actually
works
in
that
we
would
never
be
able
to
ship
performance
timeline,
because
every
new
spec
that
we
add
that
require
an
updated
performance
timeline
and
we
can
effectively
could
never
ship
the
flow
inside
way
like
it
has
to
be
a
living
spec.
G
G
B
That
itself
is
an
interesting
term
stable
enough,
because
the
whole
premise
of
the
performance
timeline
is
that
different
user
agents
may
support
different
entry
types
at
different
points
in
time.
So
it
is
not
the
case
that
shipping
performance
timeline
means
shipping
in
timing
and
other
things
like
those
are
not
coupled.
G
That
seems
we
have
to
test
a
formal
timeline
in
some
way
and
for
that
we
use
100x
for
that.
But
that's
an
that's
a
test
issue.
The
question
is
kind
of
like
a
mystical
recommendation
for
performance
online,
which
is
explicit
on
which
timing
and
trees
are
being
returned.
Knowing
that
implementations
will
vary
in
which
timing
and
twist
the
return.
H
One
question
would
be
do
we
do
we
want
to
do
the
recommendation
change
with
anytime,
before
we
actually
planned
to
move
it
to
living
in
standard
and
and
I
guess?
Another
question
more
like
for
other
browsers,
though
we
have
one
other
here,
it
would
be.
What
do
they
think
is
better
from
the
spec
perspective,
having
the
list
of
all
the
elements
in
the
performance
timeline
or
having
the
hook
where
other
specs
would
add,
the
entry
types
when
they
actually
mentioned
well,
like
every
spec
with
a
new
inch
type,
would
have
to
have
the
additional
I.
A
B
To
work
with
us
there
is,
there
isn't
a
right
answer.
It's
just
a
set
of
set
of
trade-offs
and
I
would
claim
that,
even
if
we
handle
living
standard,
it
is
still
not
a
an
ideal
outcome
for
performance
sunlights
to
enumerate
all
the
entries
that
some
browsers
may
not
support,
because
it's
unclear
like
as
a
developer
reading
that
specs
spec
I
would
expect
that
of
supported
entry
lists
like
15
different
things.
Then
then
every
browser
should
support
15
different
things,
but
that's
not
actually
the
case.
No.
G
A
G
G
G
B
G
Basically,
freeze
we,
we
freeze
it
by
the
time
as
we
move
to
proposal
commendation,
but
it's
not
like
we
had
in
either
performance
actuary,
Nancy,
either
I
mean
the
other
solution.
The
other
hand
ITV's
to
move
those
entry
into
a
separate
working
would
note
that
quit
when
we
can,
we
can
update
that
well
and
instead
we
just
give
a
link
to
see
the
list
of
possible
entries
users
to
get
the
working
good
note.
In
the
class
we
used
to
have
a
weekly
page.
We
were
looking
into
a
wiki
page.
G
Some
reason
you
guys
decided
not
to
do
that.
That
only
remember
exactly
why
another
alternative
is
to
publish
your
working
good
note
that
we
can
update
whatever
we
want
to
to
say
is
always
on
the
list
of
performance
entries.
We
have
it's
an
indirection,
it's
one
way
to
avoid
adding
to
reprovision
recommendation
and
every
single
time
we
add
a
new
entry.
Okay.
B
Too
easy
I'm
not
sure
what
the
right
interaction
mechanism
is,
but
that
seems
like
a
plausible
approach
to
solve
this.
To
me,
I
would
personally
prefer
to
avoid
having
a
numerate
that
listen
and
restarting
the
process,
because
that
aspect
will
be
frozen.
People
will
be
looking
at
updated
versions
of
it
in
the
w3c
tree
in.
G
J
J
H
H
I
A
J
E
A
I,
don't
think
that,
like
we
want
those
two
things
or
more
things,
if
we'll
have
more,
you
know
options
per
spec
to
go
like
to
have
a
set
like
one
single
mechanism
that
applies
both
so
I'm.
Guessing
we'll
need
that
registry
to
also
say
if
each
spec
is
or
is
not
available
from
like
from
the
performance
timeline.
H
D
G
A
H
G
B
D
H
Sorry
I
think
the
answer
is
the
spec
and
most
has
a
non
normative.
Now
it's
telling
you
remember
to
include
this
in
super
adventure.
Types
I
think
we
can
have
more
non
normative
notes.
You
know
in
the
new
spec
so
that
it,
the
implementer,
is
reminded
that
they
should
update
that,
because
the
normative
text
will
be
in
performance,
timeline.
I.