►
From YouTube: SES Meeting - Module Blocks and Default Realm Globals
Description
Daniel Ehrenberg joins the SES community to discuss Surma’s TC39 proposal for JavaScript module blocks and how they relate to the SES Compartments proposal.
A
Well,
good
enough,
for
now
I
guess
all
right.
Thank
you.
Welcome
to
the
pre-thanksgiving
cess
meeting.
Our
topics
today
are
module
blocks
and
and
the
scope
of
the
default
realm.
So,
let's
start
with
you,
daniel.
C
Okay,
so
I
imagine
people
here
have
seen
the
the
multiple
blocks
proposal
that
was
presented
last
year.
Nine
meeting
there
are
two
big
and
if
you
haven't
you
can
find
it
at
github.com
gc39,
slash
js
proposal
dash
js
dash
module-blocks.
So
the
two
big
questions
we
have
are
about
the
object
model
and
about
caching.
C
So
let
me
introduce
the
caching
question
first,
because
maybe
it's
simpler
and
the
caching
question
is,
you
know
the
idea
of
module
blocks?
Is
they
are
an
expression
that
returns
a
module
specifier
of
some
form,
some
kind
of
object
form,
probably
that
we'll
discuss
what
that
object
is
later
and
there's
a
question
of
when
you
evaluate
a
module
block
expression
multiple
times
will.
C
So
will
that
multiple
block
specifier,
you
know
how
will
these
act
in
the
module
cache?
So
obviously,
if
you,
if
you
evaluate
a
multiple
block
once
and
you
import
it
two
times,
you
should
get
the
same.
Module
namespace
object
back
both
times.
You'll
get
like
a
fresh
promise
that
resolves
the
same
module,
namespace
object.
C
But
what
happens
if
you,
for
example,
have
a
function
that
you
call
twice
that
returns
a
module
block
which
is
textually
the
same,
but
actually
you
know
it's
executed
different
times
or
what,
if
you
have
two
different
pieces
of
code
that
have
textually
the
same
model
block
but
they're
in
different
parse
notes,
so
the
solution
that
we're
leaning
towards
based
on
an
agreement
between
v8
and
spider
monkey
was
it
would
be
a
bad
idea
to
go
with
either
of
the
template
tag.
C
C
It
just
isn't
that
much
of
a
use
case,
for
you
know,
rationale
for
repeated
execution
of
a
module
block
and
then
importing
it
repeated
times.
The
way
there
is
for
template
strings.
So
I
want
to
propose
that
it's
uncached
that
each
time
you
evaluate
a
module
block,
you
get
a
distinct
module,
specifier
and.
C
A
I
agree:
people.
A
C
C
C
Inside
of
an
eval,
so
basically
this
is
the
simplest
possible
form
for
thinking
through
what
happens
inside
of
an
eval,
because
it's
just
the
same
as
outside
of
an
email.
The
complicated
thing
would
be.
If
we
did
want
caching,
and
if
it
was
inside
of
an
eval,
then
we
would
have
to
think
through
what
it
means
to
share
a
barce
note,
which
is
the
current
state
that
we're
in
for
for
tag
templates.
A
C
C
Then
the
next
question
is
exactly
what
you
and
mark
were
saying:
should
we
use
the
should
this
be
a
static
module?
I
can't
remember
what
the
name
of
the
class
was
my
impression.
B
A
So
from
a
specification
needs
neither
of
them
need
to,
but
the
the
compartment's
proposal
is
not
dependent
upon.
So
from
the
perspective
of
the
module
of
the
compartment
proposal
as
a
module
loader,
a
module
static
record,
which
is
the
name,
is
unimportant
for
the
purpose
of
the
conversation
too.
Its
interface
is
an
opaque.
A
As
far
as
the
compartment
is
concerned,
it's
an
opaque
reference
and
it
can
carry
all
of
its
introspection
details
in
internal
slots.
As
far
as
the
compartment
proposal
is
concerned,
however,
we
decided
to
well
there's
provisionally
in
the
proposal
as
written
today,
a
static
imports
method
which
is
neither
necessary
nor
sufficient,
the,
but
it's
not
necessary
for
the
compartment
to
be
able
to
use
the
object
and
it
isn't
sufficient
to
expose
all
of
the
information
that
needs
to
be.
A
A
D
B
Hold
on,
let
me
clarify
something
chris,
that's
what
you
just
said
is
only
the
case
when
you
want
to
support
line
bindings,
correct.
A
B
So
the
absence
of
live
bindings,
the
api
that
we
propose
is
actually
sufficient,
which
is
why
we
can
have
foreign
module
types
as
long
as
they
implement
the
api
and.
A
So
there
are,
there
are
separate
layers
of
the
specification,
the
the
the
the
innermost
layer,
the
innermost
layer
of
the
compartment's
proposal,
as
envisioned
not
as
written
is
is
concerned
with,
is
with
concern
concerned
only
with
linking
ecmascript
modules
to
other
ecmascript
modules,
as
would
be
the
case
for
the
static
module
block
right
module.
B
A
The
the
the
layer
there's
a
layer
beyond
that
that
concerns
third-party
module
types
and
does
not
concern
live
bindings,
and
in
that
the
static
in
that,
in
that,
in
that
proposal
it
extends.
It
extends
the
compartment
proposal
such
that
it
accepts
in
the
place
of
a
static
module
record
or
a
module
block.
Instead,
it
would
allow
for
there
to
be
an
a
an
interface
that
any
object
could
implement.
A
That
provides
all
of
the
information
that
would
be
in
internal
slots,
of
a
static
module
record
publicly
and
then
uses
that
in
order
to
do
the
same
thing,.
C
That's
really
interesting
what
it
makes
me
think
about
webassembly
modules,
where
you
know
the
webassembly.js
api
has
webassembly.module
as
well
as
webassembly.instance.
Mod
webassembly
modules
correspond.
I
think,
to
these
module
blocks,
slash
mod
static
module
records
and
then
the
instances
correspond
to
kind
of
module,
namespace
objects
right.
C
With
exports,
so
it
does,
it
seems
like
we're
we're
all
getting
at
these
same
concepts
from
different
angles.
I
have
heard
criticism
of
the
module
blocks.
Name
I
haven't
heard
people
suggest
what
it
should
be
called.
I
kind
of
feel
like
if
we
call
this
the
static
module
record
proposal
that
won't
lead
to
very
much
intuition
about
what
we're
talking
about,
but
it
seems
it
seems
really
clear
to
me
that
we're
talking
about
the
same
concept.
A
B
Yeah
the
way
the
I
think
that
there's
two
things
that
need
to
be
named
here,
that
for
which
module
blocks
and
static
module
records
are
defined
of
terms
which
is
in
the
same
way
that
we
have
a
distinction
between
a
lambda
expression
and
enclosure.
The
module
block
is
the
you
know.
To
my
mind,
the
inline
syntax
and
the
static
module
record
is
the
thing
it
evaluates
to.
B
One
is,
as
we
discussed,
adding
api
defining
an
api
for
static
module
record
such
that
things
can
serve
as
static
module
record
in
the
roles,
imports
and
such
that
are
not
defined
by
that
are
not
created
by
evaluating
static
module
record
such
as
wasm
modules
and
the
other
one
is
that
even
for
for
regular
javascript
modules
that
are
not
in
line
that
are
just
on
the
file
system
is
a
dot
js
file
that
there
be
some
kind
of
analog
of
import
for
obtaining,
not
a
module,
namespace
object
or
the
promised
module.
B
C
So
that
the
split
makes
a
lot
of
sense
to
me,
I
think,
if
we're
thinking
about
this
politically,
we
know
that
browsers
are
scared
by
you
know
imperative
hooks.
So
if
we
can
decouple
the
you
know,
if
we're
thinking
about
this
as
like
chipping
away
at
the
edifice
of
strings
for
the
only
module,
specifier
module
blocks
where
the
semantics
are
based
on
an
internal
slot
could
be
like
a
first
step
and
then
the
method
protocol
method
based
protocol
could
be
like.
The
second
step
is
that
that
makes
sense
for
how
we
go
about
this.
A
That
aligns
with
our
intentions
for
the
compartment
api
yeah,
also
on
about
the
intuition
of
the
name
mark-
and
I
do
not-
I
believe,
do
not
agree
about
this,
but
my
preference
part,
not
my
preference.
I
would
not
be
offended
if
static
module
record
were
renamed
module
in
order
to
hint
at
its
correspondence
to
module
blocks.
The
like
the
the
hermetic
eval
proposal
that
we
made
a
long
time
ago
was
was
actually
a
module
constructor
function.
A
That
would
be
very
similar
in
spirit
to
the
static
module
record
constructor
and
also
correspond
closely
to
the
evaluation
value
of
a
of
a
module
block.
It
was
spiritually
inspired
by
the
function
constructor
and
we
will
need.
We
will
eventually
pour
the
compartment
api.
We
we
will
need
not
just
a
con,
not
just
a
prototype
for
a
module
record,
but
also
a
constructor
from
text.
A
So
a
text
and
location
that
is
the
the
compartment
proposal
will,
when,
when
ready,
have
a
static
module,
record,
constructor
function
that
accepts
text
and
location
and
returns
a
static
module
record
object.
C
I
see
okay,
so
this
all
makes
a
lot
of
sense
and
seems
like
it
fits
together.
Well
then,
multiple
blocks
having
a
syntactic
thing,
definitely
makes
sense
to
be
the
first
thing
that
you
add
before
adding
the
string
constructor,
and
so
this
will
be
kind
of
paving
the
way
for
the
for
the
data
model.
For
these
later
proposals
right
honestly,.
C
A
A
B
So
the
the
I
don't
have
a
strong
opinion
on
that,
but
I
do
have
a
strong
opinion
about.
Is
that
the
name
for
the
syntactic
construct
and
the
name
for
the
constructor
are
different
things
in
the
same
way
that
land
expression
closure
different
things?
It's
it's,
but
but
yeah.
I
don't
have
strong
opinions
about
what
the
actual
name
should
be.
B
I
want
another
thing:
I
do
have
there's
a
a
nice
in
crime
to
specify
the
module
block
proposal
under
whatever
names
in
ecmascript
spec
language,
one
of
the
things
that
I
think
will
need
to
be
cleaned
up
and,
and
I'm
very
much
looking
forward
to
seeing
it
cleaned
up
is
right.
Now
the
spec
is
phrased
in
terms
of
these.
This
awful
thing
called
the
module
record.
Not
awful.
C
The
yeah,
I
think
I
I
definitely
agree
with
mark
about
the
horribleness
of
some
of
the
the
way
mutation
is
used
in
in
es6
things,
so
I
I
agree
that
yeah.
If
we
call
this
module,
it's
going
to
be
confusing
because
then
we'll
need
to
articulate
a
different
instance
concept
editorially
in
the
specification.
This
is
what
you're
getting
at.
B
B
It
can
mean
that
you
know
the
the
internal
spec
names
are
not
exposed
in
api,
so
that's
actually
the
things
that
are
least
costly
to
change
of
names
that
are
already
out
in
the
world,
and
if
we're
going
to
do
a
major
refactoring
of
the
spec
anyway,
then
having
the
rationalizing
the
names
in
the
specs
so
that
it
works
with
where
you
want
to
go,
I
think
is:
is
a
nice
thing
to
do,
and
the
refactoring
by
itself
to
set
us
up
for
this
could
be
something
that
itself
has
no
observable.
B
C
Sorry
about
the
module
name,
I'm
a
little
bit
concerned
that
it
could
be
confusing,
because
I
don't
know
if
people
have
a
good
way
of
thinking
through
the
gap
between
a
module.
C
A
Also
wouldn't
be
offended
if,
if
static
module
record
got
picked
up,
so
would
be
fine
either
way.
B
A
E
Okay,
so
daniel
has
some
ideas
around
around
these.
In
the
past
we
just
to
give
a
quick
history
around
it
in
the
past.
We
consider
that
it
is
in
the
control
of
the
author
or
the
creator
of
the
realm
to
decide
what
goes
there
and
the
realms
were
created
empty
with
the
global
global
object
being
empty
and
a
set
of
the
scriptures
were
given
to
you
and
you
decide
from
those
descriptors
which
one
do
you
want
to
install
as
a
global
reference.
E
We
dropped
that
a
while
ago
and
we
went
with
whatever
is
specified
in
262,
plus
the
warning
around.
What
can
what
what
can
they
host
to
in
case?
E
They
want
to
add
more
things
to
it,
and
I
feel
that
the
there
is
also
now
the
pushback
for
an
implementer
saying
that
well,
there
are
fundamental
things
from
the
browsers
that
we
would
like
to
see
there,
and
I
think
the
sentiment
is
more
like
well
there's
a
clear
distinction
now
between
the
web
and
the
language,
and
they
don't
like
that
idea,
and
I
I
I'm
sympathetic
with
that.
E
The
question
is:
where
do
we
draw
the
line
about
what
goes
there?
What
what
doesn't
and
and
daniel's
ideas
of
trying
to
organize
this
group
of
apis
that
are
more
common
seems
like
a
good
idea.
There
is
a
precedent
here
with
the
workloads
and
workers
and
such
so
what
what
should
go
there?
We
don't
know
yet.
C
So
I
I
want
to
give
some
more
kind
of
political
context
to
this
in
the
discussion
about
built-in
modules.
The
big
objection
that
we
heard
from
browsers
about
the
split
name
spaces
was
that
it
would
require
developers
to
know
about
the
layering
of
different
apis
in
web
versus
javascript
specifications.
C
C
C
C
I
mean
he
proposed
a
few
different
lines,
but
one
line
was
basically
things
with
text.
Processing
are
in
maybe
simple
things
to
work
with.
This
is
function.
Q,
micro
task,
which
is
basically
like
promise,
make
a
new
promise
and
then
then,
and
just
very
basic
things
that
could
have
been
specified
in
javascript
or
in
but
things
about
events
or
especially
input
and
output,
or
things
of
high
complexity
would
generally
be
removed.
So
we
would
be.
C
B
Let
me
ask
some
questions:
would
all
of
the
things
on
the
table
here
be
something
that
who's
whose
meaning
is
not
tied
to
being
on
a
browser?
That
would
actually
be
something
that
would
be
useful
to
appear
on
other
hosts.
B
B
Okay
and
then
the
other
one
is,
are
all
of
these
things,
powerless
in
the
sense
that
if
you
transitively
froze
the
the
primordial
form
that
there
would
be
no
loss
of
intended
utility
and
that
they
don't
provide
any
hidden
mutability
or
I
o
access
to
the
outside
world.
B
E
It
will
not
be
in
a
realm
if,
if
we
follow
this
principle
and
but
for
you
to
to
add
it
to
the
that,
that
was
one
of
the
things
that
annette
also
mentioned
like
what
about
fetch
and
io,
and
I
think
for
us
it's
it's
easy
to
just
make.
That
distinction
that
I
o
and
things
that
might
cause
some
side
effect
would
not
should
not
be
there
by
default.
E
But
I
don't
know
if
that
would
be
sufficient
for
them.
So
I
wanted
to
also
brainstorm
a
little
bit
on
what
what
kind
of
compromise
can
we
have?
That
could
unblock
this,
whether
that's
multiple
constructors
or
something
like
that
or
or
configurations
or
options,
and
we
should
look
at
this
from
the
perspective
of
okay.
Well,
the
the
end
user.
What
what
will
the
end
user
do
with
this
api.
C
Wait
before
we
game
out
further
ways
that
we
could
allow
more
things.
Can
we
establish
a
baseline
of
if
something
meets,
those
requirements
that
mark
mentioned
of
it?
Doesn't
it's
it's
powerless
and
it's
meaningful
and
useful
across
environments,
then
that
then
that
would
be
a
meaningful
thing
that
that
would
be
a
reasonable
baseline.
B
So
so
so
before
I
say
yes,
let
me
elaborate
what
what
I
I
mean
by
baseline
here
or
I
would
like
us
to
mean
by
baseline,
which
is
that
the
tc39
realm
spec
mandates
that
those
things
be
included
for
realms
across
all
huts.
That's
part
of
the
language
to
include
them,
and
that
doesn't
mean
that
tc39
has
to
you
know,
engage
in
a
in
a
jurisdictional
turf
war
uber
who
standardizes
text
encoder
tc
the
tc39
spec
does
delegate
to
other
specs,
for
example,
with
unicode.
B
We
could
likewise
say
that
text
encoder
is
part
of
the
standard
shared
globals
according
to
the
language
but
the,
but
the
spec
that
we're
referring
to
for
what
the
text
encoder
is.
We
could
still
cite
the
w3c
spec
on
the
definition
of
text
encoder,
but
I
think
that
all
the
things
that
end
up
in
this
list
should
be
a
list.
That's
standardized
by
pc39
as
part
of
the
javascript
language.
D
D
We
have
so
some
some
implicit
agreement
at
tc39
and
at
this
group
bear
with
me
that
what
we
want
is
just
the
primordials
like
from
macmascrip.
D
We
are
trying
to
accommodate
and
make
room
for
what
we
want
in
the
integration
of
html,
which
current
problem
is
a
challenge
like
getting
html
to
accept
integrating
with
realms
and
we
are
trying
to
make
room,
and
I
think
we
are-
we
are
in
our
most
in
our
best
faith,
trying
to
be
considerate.
Like
of
what
should
be
going
or
not.
I
think
we
should
be
clear
at
one
point
at
tc39.
This
proposal
is
like
implicitly
good
for
us.
D
I
think
there
is
another
problem
if
we
try
to
make
a
list
of
things
outside
of
tc39,
that
should
be
in
the
realms
proposal.
This
will
create
a
room
for
dominic
and
and
other
people
to
say,
like
hope.
This
e39
should
not
be
discussing
about
this,
and
this
should
be
extending
the
challenge
for
much
longer.
I
think,
like
our
understanding
with
with
realms
is
like
we
can,
we
should,
and
for
29
for
realms
at
tc
39.
D
We
should
be
deciding
if
we
should
create
this
room
for
extension
or
not,
and
we
should
be
creating
a
decision
with
the
html
integration
saying
what
should
be
included
or
not
like
going
specific,
but
like
for
c39,
you
should
just
be
deciding.
Should
we
allow
realms
to
to
have
more
global
properties.
D
I
think
this
is
much
simpler
of
a
problem
and
helps
them
blocking
the
proposal
easier.
I
also
like
it
allow
us
to
investigate
how
the
the
api
is
good
enough
without
many
things,
rather
than
as
like,
I've
been
collecting
some
internal
feedback
since
the
meeting
and
yeah,
as
one
colleague
has
mentioned,
like
it's
better.
If
we
go
through
evolution
rather
than
revolution,
I
think
starting
small
is
good.
It's
starting
like
what
we
have
today
is
good.
We
should
be
considering
like
what
to
be
added
in
the
html
integration,
so.
C
So
I
I
agree
with
leo's
political
sense.
I
believe
that
people
in
chrome,
in
a
in
a
set
of
people
in
chrome-
that's
broader
than
just
dominic
even-
would
would
take
mark's
proposal
as
exactly
that
exactly
as
a
turf
war
and
oppose
it
on
those
on
those
grounds.
C
If
we
wanted
to
enumerate
a
list
of
things,
I
wonder
if
we
could
do
an
intermediate
thing
of
writing
in
the
javascript
spec
the
requirement
for
our
expectations
for
the
kinds
of
things
that
will
go
on
a
realm
and
also
ensure
that
we
have
clear
documentation
somewhere
for
what
we
expect
to
be
on
it,
but
maybe
not
like
literally
specified
in
the
specification,
because
I
think
it
would
be
very
it's
very
difficult
to
traverse
all
of
the
different
web
specs
and
figure
out
what
should
be
on
the
global
object.
So
I
think
yeah.
B
E
E
Defining
the
criteria
for
the
things
that
should
go,
there
is
a
far
better
approach
than
defining
the
list
of
things
that
we
believe
should
be
there
and
the
the
criteria.
I
think
what
marx
says-
and
we
have
been
talking
about
this
for
a
while-
seems
to
be
a
good
ground
work
to
start
defining
or
consolidating
that
criteria.
E
B
B
When
I
say
new
realm
and
I'm
on
a
browser,
I
get
things
that
were
not
browser-specific
that
were
safe
to
include
on
non-browsers
and
therefore
would
not
have
harmed
me
if
they
appeared
when
I
said
new
realm
on
non-browsers,
but
we're
not
making
them
part
of
the
realm
standard
that
they
be
included.
So
if
I'm
on
a
non-browser
these
things
that
are
equally
useful
and
equally
non-browser-specific,
when
I'm
on
a
noun
browser-
and
I
say
new
realm-
I
don't
get
them
that
doesn't
seem
coherent
to
me.
E
Joe,
I
think
we
talked
about
mark.
We
talked
about
this
in
the
past.
Specifically,
I
was
trying
to
make
clear
that
the
wrong
proposal
is
not
going
to
give
you
a
a
full
standardization
or
a
full
virtualization
infrastructure,
not
necessarily
that's
the
wrong
terminology.
Here,
it's
not
going
to
give
you
a
platform
for
standardizing
the
code
across
different
environments,
because
there
always
be
difference
between
those
environments.
E
Even
the
language
itself,
like
you
might
be
that
they
know
we
don't
have
certain
features
that
are
already
implemented
in
browsers
because
they
were
implemented
in
browser
first
and
therefore
you
don't.
You
still
have
to
do
feature
detection.
What
kind
of
capabilities
are
available
to
you
when
you
create
a
new
route
now
that
rom
gets
defined,
and
this
is
the
api
that
you
get
and
you
can
trust
that
api?
You
can
add
things
to
it.
You
never
get
something
new.
E
You
will
get
difference
between
environment
all
the
time
and
having
extra
apis
provided
by
a
particular
environment
is
just
they
add
up
on
to
that.
Where
you
might
get
things
that
you
know,
environments,
you
don't
get
and
you
have
to
polyfill,
you
need
them
or
you
have
to
figure
ways
to
not
use
them
because
they
might
not
be
available
in
order
environment
for
you.
So
I
think
that's
the
reality
that
we
live
today
and
it's
just
the
same
thing
that
we
have
today.
E
C
Give
an
example,
so
I
mean
aside
from
versioning:
there
are
things
like
with
import
assertions.
B
All
these
are
all
by
virtue
of
host
hooks
that
we
expect
to
be
virtualizing
eventually,
post
post.
You
know,
after
the
around
the
realm
proposal
itself,
the,
and
in
any
case,
these
these
examples
were
are
for
proposals
that
are
in
process.
So
the
degree
of
divergence
between
environments
is
not
yet
settled
and
it's
still
opportunity
to
reduce
unnecessary
divergence.
Can
we
give
an
example
of
the
existing
language.
C
I
mean
one
example:
is
intel
or
non-intel
environments.
You
know,
intel
is,
is
optional
and
if
you
get
into
a
new
realm,
okay
yeah
now
are
you
just
convinced
now
or
what.
B
I
think
it's
an
interesting
example.
It
certainly
stretches
my
understanding,
so
the
thing
that's
interesting
about
intel
is
that
it's
there
as
a
all-or-nothing
bag
that
can
be
feature
detected
and
it's
there
as
a
potential
thing
to
to
see
across
all
environments.
C
Yeah
so
overall,
I
I'm
pretty
sympathetic
to
mark's
concerns
about
not
adding
io
things.
Besides,
multiple
loading,
I'm
wondering
if
our
next
step
could
be
articulating
this
in
a
pr
to
the
realms
proposal
and
also
in
a
change
to
the
html
integration,
pr
to
say
these
requirements
on
what
gets
added
and
on
html.
E
D
Let
me
just
roll
back
quick
to
just
a
little
political
point.
I
think
this
plan
is
great,
and
one
of
the
things
that
is
missing
here
is
actually
engagement
from
the
html
maintainers.
D
D
D
My
first
point
of
view
is
that
anna
just
like
wanted
to
cut
any
requirements,
but
actually
like
cut
down
like
in
not
being
able
to
add
anything
while
dominic
was
basically
saying
the
opposite.
Dominic
was
concerned
with
the
separation
of
what
is
like
that
we
are
now
showing
to
the
web
developers.
What
are
the
ecmascript
promotions,
differentiating
them
from
web?
D
The
web
api,
so
they're
kind
of
like
we're
going
on
the
opposite
directions,
and
I
hope,
when
you
present
your
requirements
for
them
to
engage
in
a
solid
position
where
they
are
at,
and
I
hope
they
get
like
some
concise
and
unified
position
on
that
for
integration,
because
what
we
want
is
for
them
to
show
us
some
direction
as
well
to
find
consensual
progress.
E
We
go
there
and
say:
what
do
you
think
about
this
model?
Do
you
like
this
model?
Do
you
agree
with
this
model
and
then
we
go
into?
Do
you
agree
with
the
criteria?
Is
it
the
criteria
too
narrow?
Do
we
do
you
want
to
expand
this
criteria
and
we
can
engage
into
the
conversation
as
as
well
as
looking
at
other
apis
that
might
fit
into
that
criteria
that
you
want
to
bring
it
in
in
the
html
spec.
D
C
Okay
sounds
like
we
have
a
really
solid
plan
here.
Should
we
assign
action
items
for
like
there?
There
are
sort
of
three
parts
to
this.
One
part
is
writing
the
the
spec
on
the
realms
side
to
permit
the
addition
of
globals,
but
with
these
requirements
one
is
to
do
the
survey
on
the
html
side
to
figure
out
which
apis
would
actually
be
exposed,
and
the
third
one
is
to
do
the
editorial
work
on
the
html
side
to
make
sure
that
web
ideal
works
with
realms
and
and
that
kind
of
thing.
E
Yeah
I
can
take
the
the
I
can
work
with
mark
on
the
criteria
we
have
that
somewhere.
I
believe
so
we
can
dig
it
out
and
try
to
formalize
that
and
get
marks
buying
to
it
and
and
then
we
can
try
to
update
the
spec
to
highlight
that.
I
don't
know
what
kind
of
artifact
do
we
want
to
to
add
to
the
spec.
E
Where
are
we
going
to
add
this
warning
saying
that
you
are
allowed
to
do
this?
I
think
that
going
to
be
in
this
synthetic
hook.
E
Yeah,
after
finishing
all
the
operations,
they're
saying
and
they
host
a
normative
note
or
or
something
that
can
define
the
criteria.
Okay,.
A
C
C
C
E
B
More
coordination
on
what
the
list
ends
up
as
of
the
things
that
are
included,
that
that
do
meet
these
criteria,
but
what
the
what
the
actual
list
of
those
names
are
and
what
specs
they
cite.
I
would
like
to
minimize.
B
I
would
like
to
get
good
coordination
somehow
about
that
across
hosts,
so
that
we
don't
get
unnecessary
developer
pain
where
you
know
I'm
on
node
or
I'm
on
xs,
and
I
say
new
realm
and
then
realm.global.text
encoder
and
there's
no
text
encoder.
The
text
encoder
was
powerless
and
host
independent.
Why
is
there
no
text
text
encoder
here
that
seems
like
just
you
know,
unnecessary
developer
pain,
that
our
criteria
already
enables
us
to
avoid
yeah.
C
You
know
I
I
agree,
we
need
more
coordination.
I
started
a
repository
a
couple
of
years
ago
at
this
point
to
try
to
promote
this
coordination.
Unfortunately,
I
got
it
mixed
up
in
this
built-in
modules
debate,
which
became
very
ugly,
but
I
think
I
think
politically
people
would
not.
People
would
be
happy
for
us
to
make
that,
but
we
have
to
say
that
we
have
to
be
not
asking
anybody
for
permission
to
make
that
list.
C
We
can
make
the
list.
We
can
talk
with
the
people
to
coordinate
it,
make
sure
everyone's
on
the
same
page
and
have
documentation
for
developers
and
every
implementers
and
everybody,
but
we
don't
have
standing
to
say
this
is
a
standard
right
out
of
the
gate.
Maybe
we'll
be
able
to
build
that
standing
over
time,
but
people
are
skeptical,
so
we
just
have
to
start
by
saying
it's
documentation.
B
That
seems
excellent.
That
seems
that
really
addresses
my
issue.
My
issue
was
really
not
that
I
wanted
to
really
stand
on
the
distinction
between
the
jury
and
this
active.
My
issue
is
really
that
I
just
wanted
there
to
be
a
standard
set
of
safe,
harmless
host,
neutral
globals.
B
C
C
A
It
looks
like
we're
pretty
we're
that
we're
over
time.
The
is
there
anything
we
wish
to
discuss
before
we
close
the
meeting,
I'm
going
to
stop.