►
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
A
A
So
I,
just
I
just
ran
with
it
a
little
bit
so
I'd
love
to
get
some
early
feedback
on
this
concept
of
forward
referenced
data
Uris
it's
basically
the
technique
is
a
way
to
declaratively
reference,
a
data
URI
payload
that
will
appear
later
on
in
the
document.
A
So
right
now,
you
kind
of
you
have
to
declare
the
data
URI
exactly
where
it's
used,
but
there
might
be
some
benefits
to
being
able
to
reference
data
Uris
that
live
in
other
places
in
in
this
same
document,
and
if
this
doesn't
really
make
sense,
I'll
go
through
some
examples
that
hopefully
make
that
a
little
bit
clearer.
A
So
one
one
common
use
case
is
imagine
you
have
a
page
with
highly
highly
Dynamic
content
so
and
so
like
there's,
not
just
a
finite
set
of
images.
You
just
have
a
very,
very
large
potential
number
of
images
that
that
may
or
may
not
be
displayed
on
that
page
and
the
the
images
are
relatively
small,
so
they're
sort
of
thumbnails,
so
they're
lightweight
and
you
have
a
desire
to
load
them
in
line
in
the
HTML
using
data
Uris.
A
Just
for
efficiency
of
delivery,
like
that
just
makes
sense,
like
users
aren't
going
to
be
seeing
those
same
images
over
and
over
again,
most
likely,
so
caching
is
not
very
beneficial,
so
you'd,
rather
just
inline
those
and
send
them
down
as
part
of
the
the
initial
document.
Just
just
you
know,
minimize
the
number
of
network
requests
that
go
out
and
you
know
given
that
you
have
a
very,
very
large
catalog
of
images.
A
It's
not
practical
to
pre-compute
all
the
base64
encodings
for
every
possible
image,
and-
and
it's
not
just
a
number
of
images
it's
that
each
image
could
be
rendered
in
multiple
sizes
and
dimensions
based
on
the
viewport
based
on
the
device,
pixel
ratio
and
they're
different
sort
of
places
that
surface
images
and
different
sizes.
So
just
the
combinations
are
just
very,
very
large,
so
the
pre-computing-
it's
it's
not
like,
say
you're
like
say
a
static
blog
engine
or
something
like
that.
A
Where
you
add
a
blog
post
and
you
know
before
you
hit,
publish
it'll
go
in
and
you
know,
convert
whatever
images
you
have
in
your
latest
blog
post
into
Basics
D4
and
just
inline
them
on
the
page.
This
is
much
more
Dynamic.
Just
the
number
of
images
is
too
large
for
that
to
be
practical
and-
and
the
final
piece
is
that
the
HTML,
we
assume
that
it's
delivered
using
streaming
chunking,
you
know
trunk
transfer
encoding
whatever
you
want
to
call
it.
So
the
page
is
following
that
architecture.
A
So
one
one
clear
example
of
a
page
that
sort
of
fills
this
criteria
is
a
search
engine
results
page,
but
there
might
be
other
pages
that
also
sort
of
fall
into
this
category.
A
Now,
if
imagine
just
you
know
if,
if
we,
we
had
a
naive
approach
and
I'll
I'll
show
you
an
example
page
what
this
looks
like
and
you
know
just
just
imagine
a
really
really
simple
page
here:
we
have
sort
of
an
H1
three
paragraphs
and
some
images
that
are,
you
know
interspersed
between
those
those
paragraphs.
So
what
is
what
does
the
source?
Look
like?
A
It's,
you
know
pretty
simple
We've
we've
got
the
H1,
we've
got
the
paragraph
and
then
we've
got
the
the
image
with
the
data
URI,
so
Basics
D4,
encoded
versions
of
each
of
those
three
images
here
so
they're
interspersed
with
each
other.
A
Now,
if,
if
you're
a
web
server-
and
you
know
you
have
sort
of
a
dynamic
service-
that's
generating
these-
these
image
thumbnails
right-
remember:
they're,
not
sort
of
pre-computed,
so
on
on
the
server
side,
you'll
you'll
generate
a
bit
of
HTML,
then
you
realize
oh
I
need
to
insert
this
image
right
and
since
you're,
going
in
linear
order,
you're
outputting
that
markup
and
streaming
it
out
to
the
user.
You
need
to
you
need
to
block,
and
then
you
know,
you're
waiting
for
that
Basics
D4.
A
For
that
first
image
to
be
loaded,
and
then
you
proceed
with
the
HTML,
then
you're
blocked
again
you
proceed
with
the
HTML
again
you're
blocked
again
and
then
finally,
you
output
sort
of
the
closing
tag
of
the
page.
So
you
end
up
with
this
sort
of
inefficient
waterfall
approach
on
the
server
side.
If
you
know,
if
you
followed
a
naive
approach,
so
you
know
to
work
around
that,
what
you
might
do
is
you
sort
of
pipeline
instead?
A
So
so
you
might,
you
might
generate
a
page
where
you
you
know,
since
you,
you
probably
have
some
kind
of
separate
back-end
service,
that's
generating
those
base64
URLs.
You
might
fire
off
sort
of
a
parallel
background,
call
to
to
generate
that
and
then
keep
moving
on
with
your
HTML,
and
you
put
the
the
basics
D4
markup
at
the
bottom
of
your
page.
A
So
now
here
we
have
the
same
page
where
it's
been
modified,
so
in
the
in
the
image
tags
we
put
in
like
a
one
by
one
Jif,
you
know
they're
various
sort
of
small,
minimal
versions
of
this
available
all
across
the
internet,
so
this
is
sort
of
one
of
something
that's
like
41,
bytes
or
so
so
you
put
in
these
placeholders
and
then
you
have
code
at
the
end
of
the
page.
A
So,
basically
that
you
know
the
service
that's
generating,
the
markup
is,
is
chunking
it
out
and-
and
you
just
inject
it
at
the
bottom
of
the
page.
So
it's
not
blocking
this
markup.
This
markup
can
continue
and
you
have
a
little
JavaScript
function
that
basically
takes
takes
an
ID
and
a
base64
encoding
and
and
updates
the
source
for
each
of
these.
So
basically
hoists
these.
A
You
know
these
base64
payloads
into
the
appropriate
image
tag
and
you
end
up
with
with
the
page.
So
this
is
sort
of
what
what
a
current
approach
might
look
like,
so
it's
you're
not
no
longer
blocked
on
on
the
base64
encoding
being
generated,
and
you
know
this.
This
is
okay,
but
you
know
it.
It
adds.
You
know
you
need
this
inline.js
on
the
page
that
you
know
you
don't
want
to
load
this
JS
as
part
of
an
external
bundle.
A
You
want
this
to
run
as
quickly
as
possible
and
you
might
have
a
bit
of
a
race
condition
where
the
page
might
paint
without
those
images
being
present,
and
then
you
have
the
JavaScript
runs
after
that
paint
and
and
those
get
injected
in
so
the
images
don't
load
quite
as
fast
as
they
would
in
the
in
the
prior
case
in
depending
on
timing.
A
So
you
know
what,
if
we
could
in
HTML
we
could
natively
declare
sort
of
a
reference
to
a
data
URI
payload
that
arrives
later
on
in
the
document
and
yeah.
This
is
just
sort
of
an
example.
The
markup
don't
treat
the
markup
as
as
final
I
haven't,
given
a
whole
lot
of
thought
into
this.
But
what
if
we
had
a
way
where
we
could
generate
those
base64,
payloads
asynchronously
on
the
server
side,
pass
them
in
and
we
had
some
sort
of
a
forward
reference
to
an
ID
right.
A
A
Yeah,
so
so
over
here,
so
we
we
have
the
we
have
the
image
tags
and
in
the
source
we
we
sort
of
have
a
new
variant
of
a
data
URI
attribute
where
you
know
I'm,
calling
it
a
forward
reference.
This
is
not
final.
Markup
I
haven't,
given
this
a
whole
lot
of
thought,
but
but
it's
basically
referencing
some
kind
of
an
ID
right.
So
this
is
this
is
referencing
the
Red
Square,
so
it
basically
tells
the
browser
that
hey
at
some
point
in
time
in
the
future.
A
In
this
document
there
will
be
a
data
URI
that
has
this
ID
to
it.
So
when,
when
that
appears,
you
know
you
can
sort
of
natively
hoist
that
into
this
into
this
image
tag.
And
then
you
know
the
same
thing
follows
so
so
these
payloads
are
sort
of
generated
asynchronously
on
the
server.
A
The
HTML
can
continue
to
be
generated
without
blocking
and
be
streamed
down
to
the
user,
and
then
once
this
stuff
has
arrived,
the
browser
sort
of
natively
hoists
it
into
the
the
right
place,
and
this
this
has
a
few.
You
know
a
few
benefits
to
this
approach.
So
so
one
is,
you
know,
like
I
mentioned
the
inline.js,
it
sort
of
eliminates
the
need
for
pages
to
implement
this
kind
of
JS,
and
it's
it's
pretty
widespread
across
the
internet.
A
You
know
techniques
like
this.
Another
Advantage
is
just
the
repetitive
nature
of
data
URI,
so
so
a
lot
of
websites.
You
know
they'll
put
in
these
one
by
one
placeholder
gifs
in
there
in
their
Source
attribute,
because
the
source
attribute
cannot
be
empty.
A
You
need
to
put
something
in
there
and,
but
since
you
can't,
you
can't
sort
of
share
a
reference
to
the
same
data
URI
at
multiple
points
in
the
page,
you
you
end
up
duplicating
that
markup
right
so
like
that
41
byte
example,
that
I
said
you
might
have
that
might
be
present
in
hundreds
of
places
on
the
same
page
and
the
browser
has
to
spend
time
decoding
that
those
individually,
the
the
that
decoding
cost
doesn't
get
shared.
A
So
you
know
you
what,
if
you
could
reference
a
single
instance
of
a
data
URI
in
multiple
places
on
the
page?
That
would
also
help
reduce
that
overhead
on
on
markup.
So
you
know
I'm
still
thinking
this
through.
This
is
still
pretty
early
stage
idea,
but
I
figured
it'd
be
a
good
time
to
get
feedback
from
from
folks
in
the
audience,
and
you
know
if
there
are
other
Concepts
that
that
exist.
A
I
I
started
looking
through
the
data
URI
spec,
it's
it's
pretty
old,
like
it
it's,
but
it's
it's
pretty
short,
pretty
concise,
I
I
think
it
hasn't
really
been
updated
since
1998.
But
you
know
if,
if
there
are
some
some
similar
Concepts,
similar
ideas
that
have
been
discussed,
you
know
love
to
hear
more
about
that
from
from
folks
in
the
audience.