►
From YouTube: yui open roundtable jan 10 2013
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).
C
So
make
sure
screen
is.
C
C
Which
version
is
this?
Is
this
the
widget
one
I?
Guess
it
doesn't
really
matter
so
the
the
module
that
I've
created
her
a
couple
of
different
modules
for
data
binding
there's,
one
for
progressive
enhancement
from
HTML
a
base
level,
one
which
is
actually
data
bind
dash
base,
which
just
has
one
way
out
going
push
based
interface
and
then
databind
form,
which
adds
bi-directional
binding
from
inputs
from
dom
inputs
back
into
attributes.
So
the
the
big
story
is
that
this
is
binding
and
attribute
to
something
in
the
Dom.
C
C
So
then,
in
the
sink
you
I
this
other
method
here
which
comes
in
with
that
class
extension
is
synced
to
you
is
there's
sink
to
you.
I
and
they're
synced
to
model
and
sing
to
you,
I
says,
take
what's
in
the
model
currently
and
push
it
out
to
the
DOM
and
sync
to
model
takes
what's
in
the
DOM
and
I,
pushes
it
back
into
the
attributes
doors.
So
you
can.
D
C
C
C
There's
one
there's
a
div
X
and
then
there's
a
div
why
the
div
X
doesn't
have
anything
in
it
into
which
it
renders
into
this
one
and
then
there's
a
div.
Why?
And
it
progressively
enhances
this
one,
so
its
data
binding
to
attribute
name
greeting
data
binding
to
attribute
name
and
then
in
this
case,
because
it
started
actually
as
a
bi-directional
form
binding.
It
is
mostly
form
inputs,
but
this
section
here
is
for
the
unidirectional
to
push
to
the
dom
stuff.
C
So
in
the
code
I'm
going
to
be
creating
two
instances
bound
and
bound
to
that
are
both
bound
widgets
and
the
second
one
I'm
going
to
be
specifying
the
source
node
to
show
the
progressive
enhancement
and,
in
all
cases
of
any
change
to
those
attributes
and
spitting
out
into
the
spinning
out
into
the
console.
So
these
widgets
are
actually
made
global
so
that
I
can
muck
around
with
them
on
the
console.
So
if
I
say
bound
set
and
named.
C
C
D
Yeah,
who
else
did
I
suggest
I
forget
no?
It's
lost.
A
C
The
the
basis
of
this
is
that
you
can
define
the
I/o
to
and
from
an
attribute
in
a
couple,
different
ways
which
is
there's
a
getter
and
setter,
which
is
the
process
for
pushing
to
or
retrieving
from
the
dong,
and
then
there
is
a
formatter
and
a
parser.
So
if
you
don't
need
to
do
any
special
mechanism
for
retrieving
it
from
the
Dom
or
pushing
to
the
Dom
such
as
working
with
the
form
field,
then
you
can
rely
on
the
mechanisms
that
are
in
place.
C
But
if
you
want
to
format
something
as
a
dollar
output
or
parse
it
out
of
a
dollar
string
format
when
storing
it
in
the
attribute
is
a
pure
value,
then
that
those
mechanisms
are
in
place.
It
tries
to
be
as
do
as
little
as
possible
sort
of
code,
and
it's
anyway,
since
it's
built
as
a
class
extension,
it's
not
extending
base
or
anything
like
that,
and
it's
a
fairly
low-level
code.
So
there's
there's
the
opportunity
to
build
sugar
on
top
of
this
for
for
doing
data
bindings
from
templates
and
things
like
that.
But
that's
a.
C
A
C
Right
and
that's
so
that's
the
sugar
that
I'm
talking
about
so
under
the
sugar
there
has
to
be
some
code,
that's
actually
doing
the
binding,
and
so
this
code
is
to
get
that
mechanism
in
place
and
then
how
we
want
to
do
the
enhancing
from
template.
That
sort
of
thing
is
sits
on
top
of
that
promote
supposedly,
but
we'll
we'll
talk
about
this
proposal
in
the
in
the
meeting
and
we'll
go
from
there.
B
E
F
B
G
A
F
So
recently,
with
a
skinner
demo,
I
pretty
laid
it
out
in
a
horizontal
apt
to
match
more
closely
grip
builder
and
also
made
all
the
widgets
that
are
represented
there
BTW
in
line
blocks.
You
can
get
more
of
them
on
a
page
and
see
them,
but
an
interesting
thing
beyond
what
before,
where
you
could
just
change
the
color
and
have
your
scheme
change,
you
can
go
to
schemes
and
you
can
pick
another
scheme,
and
this
autumn
scaping
you're
right
now
says,
create
custom
color
scheme.
F
You
can
sort
of
use
any
of
the
existing
color
schemes
as
a
jumping-off
point
by
selecting,
create
custom,
color
scheme
and
then
coming
back
to
the
pellet
tab,
and
now
you've
got
these
other
things
that
you
can
change
your
actually
change
the
relationships
between
those
major
blocks.
So,
as
you
can
see,
this
one
is
a
key.
Color
blue
and
the
rest
of
them
are
complements
to
that.
F
So
you
have
that
kind
of
relationship
for
this
custom
color
scheme
and
then,
when
you
changed
the
main
key
color
to
something
like
red,
you
can
see
if
we
didn't
keep
that
same
color
in
the
second
position,
but
we
now
have
something
that's
relative
to
keep.
So
that's
the
custom
color
scheme.
That's
it
awesome
very.
A
J
H
Have
a
customer
item
customer
who
cared
what,
when
each
API
has
been
introduced
because
he's
a
very
specific,
proper
compatibility
support
requirements,
so
he
supports
right
now.
Why
do
I
version
3
dot,
1
and
he
wants
to
move
to
YY
version
3
not
for
us
as
minimum,
but
he
needs
to
know
what
what
what
api's
are
available
starting
from
them.
So
we
do
have
an
accent
tag
available
to
us,
but
it
doesn't
feel
like
we
use
it
systematically
today.
H
H
I
C
D
K
Exactly
so
prior
to
do
me
to
build,
we
have
a
checklist
of
all
the
things
or
probably
doing
everything.
So
you
have
a
checklist
of
all
these
things
that
you
should
do
it.
One
of
those
would
be
going
through
replacing
all
the
placeholders
with
the
value
of
the
version
that
we're
building
for
and
then
push
that
push
those
updates
back
in
and
then
everybody
would
pull
the
yeah
we'd.
C
C
I
H
G
H
H
A
A
A
K
E
E
D
D
D
H
C
So
the
challenge
here
is
that
we
want
to
automate
it
right,
because
if
it
was
a
manual
process,
you
create
a
script
that
that
overrides
all
at
census
or
overrides,
even
all
at
versions
that
are
in
the
source
files.
And
then
it
wants
to
create
a
commit
based
on
that.
But
automating.
That
becomes
a
little
scary
and
we
would
get
more
comfort
having
actual
eyeballs
on
it.
That
are
looking
at
the
actual,
commit
diff
and
say
this
one's
okay
green
light
and
it
gets
checked
back
into
source
right.
H
I
C
A
D
C
A
G
C
I
A
C
H
H
H
H
C
I
C
H
E
A
E
D
D
C
Well,
we
had
this
discussion
many
months
ago
where
we
decided
that
an
Adsense
at
the
top
of
the
module
was
when
that
module
was
created
and
and
it
there
is
no
at
since
noted
on
a
particular
method.
It
is
assumed
that
it
was
created
when
the
module
was
created.
New
methods
that
are
added
on
to
module
from
that
point
should
be
documented,
with
an
Adsense
at
the
method
level.
Okay,.
D
C
D
I
I
A
H
I
H
I
D
I
D
H
If
you
have
a
good
checklist
of
things,
you
know
her
beliefs
running
this
round
and
running
a
blog
post,
I
think
to
just
do
like
that.
Refresh
of
getting
back
over
the
spread,
making
sure
there's
any
new
API
is
added,
but
if
there
are
I
think
that
they
would
be
highlighted
in
the
blog
post
right
so.
H
C
Thanks
I
appreciate
that
I've
I
do
have
to
leave
in
a
couple
minutes
I'm
going
to
make
this
awfully
quick
I've
been
talking
about
promises
for
several
months.
It
seems
at
this
point,
but
the
A+
promises,
a
plus
spec
was
resolved
in
terms
of
the
promised
implementation,
API
and
juan
who
was
with
us
today
and
can
actually
continue
in
my
stead.
If
I
drop
off
sooner,
he
took
my
implementation.
That
was
on
my
pull
request.
I
think
it
through
71.
I
forget
the
specific
number
I
think
his
through
everyone
anyway,
but.
C
That
one
and
it's
linked
from
the
talking
points
for
the
for
the
meeting
anyway
and
he
changed
it
over
to
an
implementation
that
does
meet
the
promises,
a
plus
spec
and
also
made
a
nice
change
to
how
promises
are
created.
And
so
my
question
at
this
point
is:
I
feel
that
in
its
current
state
on
Juan's
fork,
it's
at
a
place-
that's
probably
good
enough
to
to
bring
into
the
core
so
it's
pending,
because
it
has
a
different
design.
C
It's
probably
pending
a
bit
of
design,
review
and
it'll
need
the
api,
docs
and
some
examples
and
all
the
the
full
fledge
admiss
for
going
into
the
core.
But
I
wanted
to
get
a
sense
of
get
a
sense
of
the
room
in
terms
of
if
anyone
had
any
additional
or
alternate
questions
or
concerns
about
it
before
trying
to
move
forward.
In
that
way,.
J
J
C
So
the
API
is
pretty
solid
in
terms
of
the
consumption
of
promises,
the
implementation
of
promises
in
terms
of
the
generation,
the
initial
generation
of
promises,
the
steps,
zero
promise
itself,
that
is
implementation-specific,
there's
some
discussion
about
specifying
a
definition
of
resolvers
or
the
creation
of
promises
themselves.
But
earlier
on
it
was.
It
was
agreed
between
the
people
that
were
discussing
promises
in
terms
of
specifying
the
the
promises,
a
plus
back,
that
how
they're
created
isn't
nearly
as
important
as
how
they're
consumed
in
order
to
make
them
interoperable,
which
is
the
primary
value
there.
C
D
So,
in
terms
of
the
name
spacing
stuff
is,
is
batch
and
additional
utility.
C
Yeah,
that
is,
and
we
can
certainly
get
into
naming
discussions
about
the
individual
method.
Names
beyond
the
creation
of
promises,
but
batch
would
be
an
additional
module
for
the
inclusions
sort
of
like
array
extras
things
like
additional
features
that
draw
on
top
of
the
core
promise
functionality
and.
D
Then
the
let's
see
so
is
resolver
useful
for
anything,
but
the
mic
on
its
own
without
their
being
used
through
what
I
promise
no.